Subject: Re: dns & confidentiality?

From: Alex Bligh <[email-masked]>
Date: Sun, 06 Jun 2004 18:52:13 +0100

--On 06 June 2004 17:08 +0000 Paul Vixie <[email-masked]> wrote:

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

I agree we should do a proper survey etc., and I am not suggesting
your question was not worth asking. We should indeed get everyone's
concerns on the table.

However, I think we should draw a distinction between "requirements"
in the general sense, and "requirements for -ter", for at least 2
reasons:

1. Some requirements can be, should be, and/or are already addressed
   by things other than -ter. For instance TLS. The wonders of layered
   protocols mean we don't have to reinvent the wheel.

2. Even were that not the case for all such requirements, not every
   problem has to be solved in -ter, for precisely the same reasons
   you forcefully argued that not every problem has to be solved in
   -bis. You have argued, for instance, that NSEC2 is a significant
   change. However, it is nothing like as significant a change as a
   change to DNS (*) addressing requirement for privacy requiring
   pre-auth (for instance).

   (*) = I am distinguishing this from mere use of another layer.

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

Those of us (well, at least one of us) arguing for NSEC2 (or more
accurately arguing for non-enumerability) would in an ideal world have
liked it addressed in -bis. "in an ideal world" can be taken to mean "had
the issue - i.e. the threat model - been raised with sufficient volume
sufficiently early". That does not necessarily mean that those same people
would necessarily support extending the threat model in any (let alone
every) other way. Indeed one of the benefits of reevaluating the threat
model (as I think you are proposing) would be to formally discount certain
extensions and document why such extensions to the design criteria should
be discounted; and/or to decide and document which modifications go in
which incremental stages at the start of the design process rather than
midway through or at the end. So I for one am not (yet) regretting what I
wish(ed) for.

One as-yet-unmentioned advantage to sending DNSSECbis to the IESG as-is
(over trying to fix enumerability now), is that it can only help lead to
early exposure of code and thus can only increase the exposure to the
protocol to peer review. And if that brings out protocol (as opposed to
code) nits, and -ter is designed to be a small incremental change, then
-ter can be used to fix these too. This is going to be lost if -ter turns
out to be a proposal for a major rewrite.

Alex

--
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: Ben Laurie <[email-masked]>
Date: Sun, 06 Jun 2004 21:17:22 +0100

>   protocols mean we don't have to reinvent the wheel.

It isn't quite that easy - TLS is a TCP protocol, so moving to it would 
prohibit the use of UDP in DNS. There isn't (yet) a UDP equivalent.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff