<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>On Aug 22, 2013, at 7:05 PM, Suzanne Woolf <<a href="mailto:woolf@isc.org">woolf@isc.org</a>> wrote:</div><div><br></div><blockquote type="cite"><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.<div style="display: none; "><br></div></div></blockquote><div></div></blockquote><br><div>To elaborate on Paul's comment: </div><div><br></div><div>We really do not need to create another clever attack vector. We have sufficient already.</div></body></html>