Subject: Re: dns & confidentiality?

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

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

>> For NL it was b) and only b), and it was also recognised that,
>> indeed, it is a whois and not a DNS problem.
>
> (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
> data about this domain, else not".

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

--
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 16:07:14 +0100

Paul Vixie wrote:

> red wrote:
> 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
> 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!

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