<html><head>
<meta content="text/html; charset=windows-1252" 
http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000"><br>
<br>
Suzanne Woolf wrote:
<blockquote style="word-wrap: break-word;" 
cite="mid:EA64FF9F-2A43-48BB-AE4C-767F0B39A278@isc.org" type="cite">
  <meta http-equiv="Content-Type" content="text/html; 
charset=windows-1252">
  <br>
  <div><div>On Aug 22, 2013, at 6:25 PM, Paul Vixie <<a 
moz-do-not-send="true" href="mailto:paul@redbarn.org">paul@redbarn.org</a>>
 wrote:</div><br>
<blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
... 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. <br>
  </div>
</blockquote>
<br>
i see that. i just find it indescribable that a content owner who signs 
their zone as a means to protect themselves against corruption in their 
secondary servers, can have that tool taken out of their hands by a 
distant resolver operator who uses NTA to keep their own phone from 
ringing.<br>
<br>
<blockquote style="word-wrap: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space; " 
cite="mid:EA64FF9F-2A43-48BB-AE4C-767F0B39A278@isc.org" type="cite">
  <div><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>
</blockquote>
<br>
as someone who depended on the local policy exemption to make dlv work, i
 follow this line of reasoning. what i would like in local policies like
 nta or dlv which seek to be distributed and scalable is, whenever it's 
used, it makes something more secure. nta fails that test, unless we're 
also going to add signaling similar to DS (so, comes from the delegator)
 that would let a content owner say, if DNSSEC validation fails, i want 
failure propagated to the end user. but i'd want that to be the default.
 which is where we'd be back in absurdity land.<br>
<br>
i totally understand that we have all got comcast to thank for the fact 
that DNSSEC matters at all at this point, and that without an NTA knob 
in their local policy framework, they could not have come this far. 
where i'm drawing the line is NTA as a standard or even a BCP.<br>
<br>
vixie<br>
</body></html>