<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 22, 2013, at 6:25 PM, Paul Vixie <<a href="mailto:paul@redbarn.org">paul@redbarn.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000"><br>
<br>
Paul Hoffman wrote:
<blockquote cite="mid:3A4FF9BD-D9E7-4735-8810-6B5C56E84057@vpnc.org" type="cite">
<pre wrap="">On Aug 22, 2013, at 2:47 PM, David Conrad <a class="moz-txt-link-rfc2396E" href="mailto:drc@virtualized.org"><drc@virtualized.org></a> wrote:
</pre>
<blockquote type="cite"><pre wrap="">A resolver operator deploying an NTA is making an assertion that data behind a name is safe despite protocol indications that is may not be.
</pre></blockquote>
<pre wrap=""><!---->
Where is that stated? I ask, because it would seem that a better description would be that they are asserting that the data behind a name is unprotected by DNSSSEC.</pre>
</blockquote>
<br>
agreed, and that's why, over and above the absurd engineering economics
behind it, i don't like NTA. if my signatures don't work because i've
been attacked (for example, one of my name servers has been
compromised), the last thing i'd want is comcast telling their customers
that the data they're getting from my compromised name server is ok to
consume because it's unsigned.<br></div></blockquote><div><br></div>I don't like it either, but it limits the damage done by a DNSSEC failure to status quo ante rather than something worse. After all, "ok to consume because (even though) it's unsigned" is where we were all the time pre-DNSSEC, and where we are today where it's undeployed….and for some operators, better than having a validation failure cause a resolution failure. </div><div><br></div><div>Probably more importantly, it limits the cost-shifting associated with errors in DNSSEC deployment.</div><div><br></div><div>I have a lot of sympathy for operators who look at DNSSEC without NTA and say "Wait, you mean if someone else signs their zones and I turn on validation, *my* failure mode if *they* screw up is more costly than my failure mode if they screw up and I haven't turned on validation in the first place? Um, no."</div><div><br></div><div>If you're OK with validation failures leading to resolution failures, don't deploy NTA. If you (or your People in Charge of Making Things Work and Money Flow) aren't, I see why you might think it's a good option to have.</div><div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
madness test: would we have bothered with DNSSEC at all, back in the
day, if NTA had been known as a definite requirement?<br></div></blockquote><br></div><div>I realize this is something of a rhetorical question, but I'll bite: if it were framed as a way of promoting incremental, fault-tolerant deployment and mitigating the cost shifting of "I screw up and your phone rings," some of us might well have been happy to include it. </div><div><br></div><div>I recall a lot of talk during the DNSSEC specification and implementation process about the primacy of local policy. It's not a major reach for me to regard NTA as a perfectly reasonable knob for setting local policy.</div><div><br></div><div><br></div><div>Suzanne</div><div>Director, Strategic Partnerships</div><div>ISC/DNSCo</div><div><br></div></body></html>