Subject: Re: dns & confidentiality?

From: [email-masked] (Ted Lindgreen)
Date: Sun, 6 Jun 2004 10:13:13 +0200

[Quoting Danny Mayer, on Jun  6,  3:06, in "Re: dns & confidenti ..."]
...
> What needs to be kept confidential? Is it:
...
> b) He doesn't want people to know about the domain since you can
> find out all sorts of information via whois, in which case the problem
> lies with whois and not DNS.

For NL it was b) and only b), and it was also recognised that,
indeed, it is a whois and not a DNS problem.

-- ted

--
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: Sun, 06 Jun 2004 08:34:08 +0000

> indeed, it is a whois and not a DNS problem.

(where "b)" was non-enumeration.)

non-enumeration as a baseline for what confidentiality means is instructive.
the folks i've spoken to who care about this characterize it as "if you know
the domain name exists you should be able to retrieve data about it, else not."
and when faced with the "rrtype" question, they universally amend it to say
"and if you know what rrtypes exist you should be able to ask for rdata, else
not."

so, confidentiality doesn't have to mean "if you know something that only a
friend or customer or supplier would normally know then you can retrieve
data about this domain, else not".

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!

---

From: Alex Bligh <[email-masked]>
Date: Sun, 06 Jun 2004 12:22:29 +0100

> (where "b)" was non-enumeration.)

I think actually (c) was non-enumeration, but...

> non-enumeration as a baseline for what confidentiality means is
> instructive. the folks i've spoken to who care about this characterize it
> as "if you know the domain name exists you should be able to retrieve
> data about it, else not." and when faced with the "rrtype" question, they
> universally amend it to say "and if you know what rrtypes exist you
> should be able to ask for rdata, else not."

..and that is Nominet's concern; I don't think the rest is.

> so, confidentiality doesn't have to mean "if you know something that only
> a friend or customer or supplier would normally know then you can retrieve

agreed

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

Why is it orthogonal? Firstly, for the practical reason that at least some
of those worried about enumerability are concerned about (a) the zone as a
whole (and not 'inferences' as to contents of the zone), and (b) making
DNSSEC "no worse" than life with current DNS implementations. With regard
to both of these points, current DNS can be snooped in flight, as can the
transactions likely to follow immediately (HTTP, SMTP etc.); so it's not
immediately obvious transaction privacy either fixes anything that
DNSSECbis "broke", or that in practice it would actually add any privacy.
Secondly, in a technical sense, it's possible to have transaction privacy
without enumeration and vice-versa - i.e. there is no algorithmic linkage I
can seem. Thirdly, qualitatively they just seem different to me. Fourthly,
from a practical point of view, privacy is going to require a pre-auth
of some sort, which is then going to bring up the question "what if
I want to authorize some people and not others", and this is additional
layers of protocol development well beyond NSEC2/NO/whatever.

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.

Alex

---

From: Ben Laurie <[email-masked]>
Date: Sun, 06 Jun 2004 16:07:14 +0100

> imply a full DH preauth between each initiator/responder pair.  yow!

Hmmm, not necessarily DH. And, indeed, DH would not prevent active attacks.

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

---

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

> requirement of ours, though I can see it might be something others might

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.

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

---

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

---

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.

---

From: Damien Miller <[email-masked]>
Date: Mon, 07 Jun 2004 10:12:28 +1000

> Hmmm, not necessarily DH. And, indeed, DH would not prevent active attacks.

It wouldn't help against traffic analysis either. Much may be
inferred by simply observing the lengths and timings of packets, let
alone their destinations.

-d