Subject: Re: dns & confidentiality?

From: Paul Vixie <[email-masked]>
Date: Sun, 06 Jun 2004 17:08:23 +0000

> ...
> > but it probably would mean "if you're not the initiator but you happen to
> > be able to monitor the transaction in flight, you should not learn any
> > names or data".  this is the second tricky part after non-enumerability,
> > and seems to imply a full DH preauth between each initiator/responder
> > pair.  yow!
> 
> What this does is add privacy to the DNS transaction, as opposed to add
> confidentiality to the zone. (by which I mean here preventing nameservers
> themselves from publishing the zone in its entirety, which is what we want
> to achieve); this seems to me an orthogonal requirement (and not a
> requirement of ours, though I can see it might be something others might
> wish for).

i understood that this is not one of nominet's concerns.  however, if we're
going to reconsider the basic design and threat model of dnssec for -TER,
then it's going to be necessary to survey the community to find out what else
really matters and to whom.

> Why is it orthogonal? ...

i agree that transaction secrecy is orthogonal to zone confidentiality, but
both are part of the general field of "things dnssec doesn't do" and i expect
that a proper field survey will turn up *both* as requirements for -TER.

> So I'm not sure the two should be linked; neither am I sure that
> transaction privacy isn't better addressed through (for instance) DNS
> over TLS (or for that matter IPSEC), which, as far as I can tell,
> would fully deal with this issue at the cost of a couple of sentences
> in a standard, but not touch on enumerability.

if privacy can be handled with tls or ipsec then so be it -- but for now, my
goal is to "get everybody's concerns out onto the table."  for -TER, "opt-in"
might come back for another round of debate.

those of you arguing for NSEC2 might by now be realizing that you should "be
careful what you wish for."  a reconsideration of the design goals and threat
model of dnssec could draw in features beyond non-enumerability of zone data.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Thu, 10 Jun 2004 21:53:21 +0000

> ...  For completeness, one thing in the latter category that is not
> found in the draft but can be done by such operators is "stick with
> non-sec DNS", and I suspect, where synthesis is not practical, this
> may be the workaround of choice until -ter is available; the
> advantages/disadvantages etc. sections should be obvious.

for operators of enterprise zones this is a practical alternative.  for
operators of delegation-only or delegation-mostly zones where the subzones
are held by "registrants", this alternative is only practical if most of
those registrants are happy to be disconnected from dnssec in this way.

that's one of the driving forces behind the several known variants of
"islands of security", including the ihren-manning-kolkman "perl goo"
and also including conrad-vixie-kosters-weiler "dlv" (which is present,
though in an incomplete and as-yet-undocumented form, in 9.3.0-betaNN).

it's necessary, before an operator selects the "just don't bother with
dnssec until -ter comes out" alternative, to find out what impact that
will have (if any) on subdomain holders might care more about dnssec
than their superzone operator does.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 11 Jun 2004 17:53:58 +0000

> > who only want to know if they can forward the dnssec-bis docset to
> > the IESG.
> 
> did they not ask for comments on -trans?

yes.  but -trans is just a straw poll on forwarding dnssec-bis to iesg,
so even though it has a different name, it's the same conversation.

> I am assuming here that it is relevant point to make, that although
> the consensus on the WG is not to fix NSEC in -bis, this will likely
> cause certain operators not to deploy until -ter; isn't that what
> transition is all about?

yes.  but saying "deploying -bis with nsec synthesis would cause me to
buy more hardware than i want given my anycast configuration" is not,
in and of itself, an argument not to forward -bis.  it is in fact a
tacit approval since it makes the case that under known and reachable,
though undesirable, circumstances, someone could deploy -bis without
waiting for -ter.  that's even better than "i can't deploy until -ter
but i agree that there's a reasonable way of getting to -ter from -bis"
which is mostly what the -trans (and -ter) authors are hoping for.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 14 Jun 2004 13:58:27 +0000

> > In short: with that solution, one could spoof responses to "deny
> > everything" under co.uk., AUTHENTICATED existing names, signed and
> > existing names, etc.
> 
> & how is that worse than the likely alternative of "do nothing"?

if you do nothing, then paranoid clients will continue to have very
little confidence in spoofed data.  if you use a zone-covering NSEC
for all responses, then paranoid clients will have high confidence
in spoofed data.

not that i know of any paranoid clients, but we're all implicitly
assuming that there will be some, or else we wouldn't be doing dnssec.

i do not think that "a zone-covering NSEC" should be listed in -trans
as one of the alternatives.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 14 Jun 2004 20:57:56 +0000

> Which is one reason why it would be good if there was some signaling
> that denials should not be treated as authenticated: ...

if you want non-authenticated denial, maybe you should just leave out
the NSEC altogether.  putting your signature on one that covers names
which actually exist, and then leaking that signed "lie" to the universe,
where others could replay or misinterpret it out of context, seems like
a huge mistake to me.