<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>