Subject: dns & confidentiality?

From: [email-masked]
Date: Fri, 4 Jun 2004 17:49:22 +0000

Now that the DNSSECbis docs are locked, loaded, and the tubes flooded,
perhaps its time to review one of the basic presumptions that drove the
-bis set and seemed to cause any amount of angst in some operators.

should the DNS and the data it holds be considered confidential?
additionally, it would seem prudent to ask...
should the tools/applications used to access the DNS support confidentiality?

if so, this might be worth paying attention to:

http://crypto.stanford.edu/portia/workshops/2004_7.html

--bill

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

---

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: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 6 Jun 2004 20:35:15 -0700

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

TransportLayer Security in a datagram protocol...

It would not take much to add TLS like functionality though, just add a key
exchange to the protocol, then use TSIG for authentication. If you need
confidentiality add an AES encryption envelope, just make sure you leave
enough useful information on the envelope.

It could be run over UDP without problems. The main challenge would be
avoiding DoS attack - although that can be mitigated by simply allowing use
of stale key material if the key server is unavailable.

	Phill