dns & confidentiality?

6 views
Skip to first unread message

bman...@vacation.karoshi.com

unread,
Jun 4, 2004, 1:49:22 PM6/4/04
to

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 namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

Paul Vixie

unread,
Jun 4, 2004, 2:08:45 PM6/4/04
to
> should the DNS and the data it holds be considered confidential?

i don't know. doing so could demand a DH exchange on every query, depending
on the threat model. and would demand at least some kind of work-preload for
every initiator, like an expensive hash of <time,qname,qtype,qclass> to
discourage zone walking. it's a much harder problem than NSEC2 addresses.

Eric A. Hall

unread,
Jun 4, 2004, 2:18:58 PM6/4/04
to

On 6/4/2004 12:49 PM, bman...@vacation.karoshi.com wrote:

> should the DNS and the data it holds be considered confidential?

Information in DNS is only as secure as all of the points where it is
cached. Seems to me that it's impossible to consider any such system as
anything other than incidentally confidential.

--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/

bman...@vacation.karoshi.com

unread,
Jun 4, 2004, 2:21:54 PM6/4/04
to
On Fri, Jun 04, 2004 at 06:08:45PM +0000, Paul Vixie wrote:
> > should the DNS and the data it holds be considered confidential?
>
> i don't know. doing so could demand a DH exchange on every query, depending
> on the threat model. and would demand at least some kind of work-preload for
> every initiator, like an expensive hash of <time,qname,qtype,qclass> to
> discourage zone walking. it's a much harder problem than NSEC2 addresses.
>

yes it is. and i suspect that -IF- the current user
base expects confidentiality, that the DNS as we know
it is -DOA- and we should start on the new thing -now-.
Much harder than NSEC2, which is a pretty much a translucent
veil over the naked DNS. Still, its worth asking the question.


--bill

Rob Austein

unread,
Jun 4, 2004, 2:51:37 PM6/4/04
to
At Fri, 4 Jun 2004 17:49:22 +0000, Bill Manning wrote:
>
> Now that the DNSSECbis docs are locked, loaded, and the tubes flooded,

Only almost, and it might be nice to let the WG list quiet down a bit
so that folks could concentrate on the boring job of proofreading the
flipping -bis docs rather than jumping right into yet another high
volume debate, but I know that Bill is easily bored. :)

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

I suspect that the trust model would prove sufficiently complex that
it would render the result, if usable at all, sufficiently different
from DNS as we know it that it would be easier just to start over.

I'm tempted to say, along with Rocket J. Squirrel, that "that trick
never works", but I could of course be wrong.

Scott Rose

unread,
Jun 4, 2004, 2:52:43 PM6/4/04
to
I wonder how many of those that _do_ expect confidentiality actually need
it. Or if anyone really MUST have confidentiality for IP address lookup. I
guess there could be some scenarios where it is desired, but that also
depends on what a user wants to keep confidential.

I agree that DNS itself doesn't have the necessary features to have that
now, and neither does DNSSEC/bis/ter. Something else would be needed:
either hop-hop or end-end?

Scott

> -----Original Message-----
> From: owner-nam...@ops.ietf.org
>

> yes it is. and i suspect that -IF- the current user
> base expects confidentiality, that the DNS as we know
> it is -DOA- and we should start on the new thing -now-.
> Much harder than NSEC2, which is a pretty much a translucent
> veil over the naked DNS. Still, its worth asking the question.
>
>
> --bill
>

Geoffrey Sisson

unread,
Jun 4, 2004, 3:21:22 PM6/4/04
to
bman...@vacation.karoshi.com writes:

> should the DNS and the data it holds be considered confidential?

Based on our legal advice:

http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00687.html

. . . we're obligated to make a best-effort attempt to keep the data
in the DNS confidential. Which for us, practically, at the moment,
means: "it's worse to expose data in the DNS via DNSSEC than to not
deploy DNSSEC".

:-(

Regards

Geoff

Danny Mayer

unread,
Jun 4, 2004, 8:32:49 PM6/4/04
to
At 02:52 PM 6/4/2004, Scott Rose wrote:
>I wonder how many of those that _do_ expect confidentiality actually need
>it. Or if anyone really MUST have confidentiality for IP address lookup. I
>guess there could be some scenarios where it is desired, but that also
>depends on what a user wants to keep confidential.

The people who want confidentiality need to define EXACTLY what they mean
by that, otherwise the working group will end up working towards yet another
goal that doesn't satisfy their perceived needs.

Danny

bman...@vacation.karoshi.com

unread,
Jun 5, 2004, 9:13:41 AM6/5/04
to
> Indeed. Confidentiality is a nebulous word. That might include anything
> up to an including:
> * Ensuring noone with access to the wire between server and resolver
> can infer anything about either the names resolved, or the results of
> that resolution
> * Ditto with respect to those with the ability to snoop caching
> nameservers
> * Requirements for clients themselves to authenticate before being
> given confidential data

yup...

> I think Paul dropped the confidentiality suggestion in as a possibility.
> I don't think anyone has yet argued for it, and if they do, I think
> it's a mostly orthogonal requirement to the enumerability problem
> (certainly the above type of requirements are not something Nominet is
> looking for to my knowledge).

may or may not have been Paul (which one?) but it
is certainly called out in the DNS threat model RFC.
And Geoff did indicate that Nominet has received legal
advice that confidentiality is required. Rock/hardPlace.


> Alex

--bill

Danny Mayer

unread,
Jun 5, 2004, 8:57:11 PM6/5/04
to
At 11:28 AM 6/5/2004, Alex Bligh wrote:


>--On 05 June 2004 13:13 +0000 bman...@vacation.karoshi.com wrote:
>
>>And Geoff did indicate that Nominet has received legal
>> advice that confidentiality is required.
>

>I think (as per the referenced in Geoff's message to which you refer) it's
>specific confidentiality that's required on that front (i.e. of the
>database rather than of its components), rather than "everything must be
>held confidential".
>
>But away from the legal point, there's the "what do we want this protocol
>to do" question. Again, from Nominet's view, whilst I can see the three
>things I posted might be desirable features to some, they aren't something
>Nominet's looking for.
>
>The point of my message was to indicate what advice we had not received,
>and what functionality we were not seeking :-) - given "confidentiality"
>can mean anything to anyone.
>
>Alex

I raised the issue of defining "confidentiality" since it's not clear at all
what that means. For example: alex registers a domain alex.co.uk
with Nominet (and I'm not really picking on Alex or Nominet here).
What needs to be kept confidential? Is it:

a) the domain name alex.co.uk itself, in which case I would argue that
by registering the domain and making it available through the parent
domain, the name has been published and is available for everyone
to use. Otherwise why register it in the DNS?

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.

c) Doesn't want someone else walking the co.uk and getting a complete
list of all domains. This could affect performance of the DNS servers
due to the advent of kiddiescripts being created to do this.

d) something else.

Again I'm not picking on Alex or Nominet. I just want to understand
exactly what they want to protect.

Danny

Alex Bligh

unread,
Jun 5, 2004, 11:28:36 AM6/5/04
to

--On 05 June 2004 13:13 +0000 bman...@vacation.karoshi.com wrote:

> And Geoff did indicate that Nominet has received legal
> advice that confidentiality is required.

I think (as per the referenced in Geoff's message to which you refer) it's
specific confidentiality that's required on that front (i.e. of the
database rather than of its components), rather than "everything must be
held confidential".

But away from the legal point, there's the "what do we want this protocol
to do" question. Again, from Nominet's view, whilst I can see the three
things I posted might be desirable features to some, they aren't something
Nominet's looking for.

The point of my message was to indicate what advice we had not received,
and what functionality we were not seeking :-) - given "confidentiality"
can mean anything to anyone.

Alex

--

Alex Bligh

unread,
Jun 5, 2004, 8:37:45 AM6/5/04
to

--On 04 June 2004 20:32 -0400 Danny Mayer <ma...@gis.net> wrote:

>> I wonder how many of those that _do_ expect confidentiality actually need
>> it. Or if anyone really MUST have confidentiality for IP address
>> lookup. I guess there could be some scenarios where it is desired, but
>> that also depends on what a user wants to keep confidential.
>
> The people who want confidentiality need to define EXACTLY what they mean
> by that, otherwise the working group will end up working towards yet
> another
> goal that doesn't satisfy their perceived needs.

Indeed. Confidentiality is a nebulous word. That might include anything


up to an including:
* Ensuring noone with access to the wire between server and resolver
can infer anything about either the names resolved, or the results of
that resolution
* Ditto with respect to those with the ability to snoop caching
nameservers
* Requirements for clients themselves to authenticate before being
given confidential data

I think Paul dropped the confidentiality suggestion in as a possibility.


I don't think anyone has yet argued for it, and if they do, I think
it's a mostly orthogonal requirement to the enumerability problem
(certainly the above type of requirements are not something Nominet is
looking for to my knowledge).

Alex

Ted Lindgreen

unread,
Jun 6, 2004, 4:13:13 AM6/6/04
to
[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

Paul Vixie

unread,
Jun 6, 2004, 4:34:08 AM6/6/04
to
red 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.)

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!

Ben Laurie

unread,
Jun 6, 2004, 11:07:14 AM6/6/04
to
Paul Vixie wrote:

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

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

Paul Vixie

unread,
Jun 6, 2004, 1:08:23 PM6/6/04
to
> ...

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

Ben Laurie

unread,
Jun 6, 2004, 4:17:22 PM6/6/04
to
Alex Bligh wrote:

>
>
> --On 06 June 2004 17:08 +0000 Paul Vixie <pa...@vix.com> 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.

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.

"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

--

Hallam-Baker, Phillip

unread,
Jun 6, 2004, 11:35:15 PM6/6/04
to

> 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

Alex Bligh

unread,
Jun 6, 2004, 7:22:29 AM6/6/04
to

--On 06 June 2004 08:34 +0000 Paul Vixie <pa...@vix.com> 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

Alex Bligh

unread,
Jun 6, 2004, 1:52:13 PM6/6/04
to

--On 06 June 2004 17:08 +0000 Paul Vixie <pa...@vix.com> 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.

Damien Miller

unread,
Jun 6, 2004, 8:12:28 PM6/6/04
to
Ben Laurie wrote:

> 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

Stephane Bortzmeyer

unread,
Jun 7, 2004, 3:51:28 AM6/7/04
to
On Fri, Jun 04, 2004 at 05:49:22PM +0000,
bman...@vacation.karoshi.com <bman...@vacation.karoshi.com> wrote
a message of 19 lines which said:

> should the DNS and the data it holds be considered confidential?

To me, no, *but* access to one record (a typical DNS query) is *not*
the same thing as bulk access to all the records (AXFR or zone
walking).

Many people seem to have trouble understanding the difference or are
concerned only with performance problems (see Paul Vixie's example of
AXFR in ".com" for a good example of why performance is not so big a
problem).

But the difference is not technical: with individual access, the
amount of damage you can do is inferior. That's all. That why several
laws (for instance, in France, the law "Informatique et Libertés" -
Data processing and Freedom) have different provisions for individual
access and bulk access.

To summary, individual access does not need confidentiality (at least
not in the current DNS framework, adding it would mean a huge change
in the DNS model) but bulk access should be restrictable (ACL in BIND,
for instance). If it is not restrictable, it means forcing a political
decision via a technical standard.

Reply all
Reply to author
Forward
0 new messages