Subject: Re: Proposal to fix NSEC

From: Ben Laurie <[email-masked]>
Date: Wed, 19 May 2004 20:45:16 +0100

Peter Koch wrote:
> Jim reid wrote:
>>If the rewards for a successful attack are high enough, this isn't an
>>acceptable risk. How much would it cost to implement SHA-1 in
>>hardware, assuming there aren't chips that can do this already?
> 
> 
> There are other alternatives, including online signing, maybe with a
> different key. The zones in question have some special properties (almost
> "NS only"), which may also be exploited to find a solution.

I have hesitated to suggest alternatives that include online signing, 
because of the principle that private keys should not be exposed by 
putting them on connected machines. However, it is definitely worth 
saying that online signing would completely eliminate traversal.

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

--
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]
Date: Wed, 19 May 2004 21:58:00 +0200 (CEST)

On Wed, 19 May 2004, Ben Laurie wrote:

> putting them on connected machines.

A ssh/tls/ipsec capable machines have a private key on connected
machines.

> However, it is definitely worth saying that online signing would
> completely eliminate traversal.

Definitly.

Roy

---

From: Bob Halley <[email-masked]>
Date: 19 May 2004 15:44:26 -0700

> saying that online signing would completely eliminate traversal.

The problems with online signing are:

        It's a CPU burden for the authoritative nameserver.

        You must trust your slaves enough to give them the right
        to make signatures.  In the standard DNSSEC model, a
        rogue slave can deny service, but it cannot generate
        authenticated zone content.

        You have to have some kind of security relationship with
        all of your slaves, either to give them the online signing
        private key or to otherwise authenticate the key they are
        using for online signatures.

---

From: Robert Elz <[email-masked]>
Date: Thu, 20 May 2004 06:32:44 +0700

Date:        Wed, 19 May 2004 20:28:00 +0200
    From:        Peter Koch <[email-masked]>
    Message-ID:  <[email-masked]>

  | But as always, some animals are more equal than others and in this case
  | they have a point. Being able to list all registered/delegated names is
  | different from serving a name upon request. And while we seem to agree that
  | the data is public, the compilation may not.

Both are public data.

Remember the history of the DNS please.   The DNS is just a more
scalable and manageable (and flexible) replacement for the HOSTS.TXT file,
a single file, listing everything, available to everyone.

If the data aren't meant to be public, they simply should not be in the DNS.
[I truly hate that "data" is plural.]

Playing around with the protocols to attempt to make it harder to
find this public data is just plain crazy.

If there is data in whois that shouldn't be public, it ought be removed
from whois - or whois ought to be secured.   Neither the DNS, nor DNSSEC is
in any way related to that.

kre

ps: the section in question in the security considerations shouldn't be
there at all - not just the final sentence of it, the whole thing.   There
is no security implication in being able to find out the names in a DNS
zone file.   That's the point of the DNS.

---

From: George Michaelson <[email-masked]>
Date: Thu, 20 May 2004 09:58:19 +1000

>in any way related to that.

Both ARIN and APNIC have recently passed policy changes to support higher
levels of data 'hiding' in whois, because of various national privacy laws. In
APNIC, we intend implementing this via our portal services, with minimal
schema changes to WHOIS: data will just stop appearing under the resource holders
control (the one who gets it from us, that is: downstreams may not have direct
control over this)

There is a dynamic tension between an ISP/LIR's desire to expose their
downstream allocations (eg to direct abuse complaints to the nearest responsible
party) and to meet some classes of users legitimate request not to have their
personal contact details published.

Its likely that CRISP is going to provide similar features, to selectively
mask or opaque parts of the dataset which currently comes from WHOIS or like
services.

cheers

-George

-- 
George Michaelson       |  APNIC
Email: [email-masked]    |  PO Box 2131 Milton QLD 4064
Phone: +61 7 3858 3150  |  Australia
  Fax: +61 7 3858 3199  |  http://www.apnic.net

---

From: Ben Laurie <[email-masked]>
Date: Thu, 20 May 2004 09:14:41 +0100

> A ssh/tls/ipsec capable machines have a private key on connected

I didn't intend to suggest it was a general principle, more that it was 
a DNSSEC principle. It seems to me that DNSSEC is fortunate in that it 
is possible to do its job without online keys, and it makes sense to try 
to preserve that good fortune.

Cheers,

Ben.

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Thu, 20 May 2004 10:43:58 +0200

> | the data is public, the compilation may not.

Again, the compilation may not be public. That is an *actual fact* in the 
case of many TLDs. Could we stop declaring this as a non-problem? We'd 
have two ways to go:
a) We face it's a problem, live with it and *say so* in the actual drafts.
b) We invest our discussing energy in the NSEC2 proposal (or NO, or any 
other) to fix whatever is broken.

> in any way related to that.

Simon just said it: fixing whois will remove whois from the examples, but 
won't remove the traversal problem.

Regards,
Marcos

---

From: Jim Reid <[email-masked]>
Date: Thu, 20 May 2004 10:41:30 +0100

>>>>> "Marcos" == Marcos Sanz/Denic <[email-masked]> writes:

    Marcos> a) We face it's a problem, live with it and *say so* in
    Marcos> the actual drafts.  b) We invest our discussing energy in
    Marcos> the NSEC2 proposal (or NO, or any other) to fix whatever
    Marcos> is broken.

There's also (c) provide a clear definition of the "problem" and get
consensus that it really is a problem. Once that's been done, we can
have a discussion about (a) or (b).

As far as I can see, the case that there are technical problems with
zone traversal has still to be made. All we've had so far are fluffy
layer 9 things about compilation copyright or indexes into whois that
might cause disclosure of personal data in the whois database. These
are nothing to do with the DNS protocol and can't be solved there IMO.
So could somebody please tell us -- or me at any rate -- what are the
technical DNS protocol problems with zone traversal? I'd really like
to know what problem we're being asked to solve. It would be good to
get this established before there is any analysis of the possible
solutions.

---

From: Roy Badami <[email-masked]>
Date: Thu, 20 May 2004 11:27:03 +0100

>>>>> "Jim" == Jim Reid <[email-masked]> writes:

    Jim> There's also (c) provide a clear definition of the "problem"

I thought this had already been stated in this thread.  Currently, the
DNS allows the operator of an authoritative nameserver to permit
unauthenticated queries, but to deny enumeration of the zone to
unauthenticated parties.

With DNSSEC, this is not possible.  If you allow queries then you
allow enumeration.

This is a technical change: specifically, the authentication model is
now less fine-grained than it used to be.

Whether this technical change constitutes a problem would seem to
depend on the legal and policy framework in which the nameserver is
operating, but it would appear that at least some ccTLDs in EU states
are concerned that this technical change _might_ raise legal or policy
issues that _might_ be a barrier to deployment...

    -roy

---

From: Jim Reid <[email-masked]>
Date: Thu, 20 May 2004 12:07:00 +0100

>>>>> "Roy" == Roy Badami <[email-masked]> writes:

    Roy> I thought this had already been stated in this thread.

Well I think it hasn't. :-)

    Roy> Currently, the DNS allows the operator of an authoritative
    Roy> nameserver to permit unauthenticated queries, but to deny
    Roy> enumeration of the zone to unauthenticated parties.

    Roy> With DNSSEC, this is not possible.  If you allow queries then
    Roy> you allow enumeration.

This is already known. Now why do some people believe that this
enumeration is a *technical* problem? What, specifically, are the
technical protocol problems that arise from this?

If there's a layer-9 problem about compilation copyright or whatever,
that needs to be solved at layer-9, not here. In fact it can't be
solved here.

BTW, enumeration of an unsigned zone by unauthorised parties is
theoretically possible. DNSSEC just makes this theoretical concern
a practical possibility.

---

From: Jim Reid <[email-masked]>
Date: Thu, 20 May 2004 12:20:33 +0100

>>>>> "Roy" == Roy Badami <[email-masked]> writes:

    Roy> Whether this technical change constitutes a problem would
    Roy> seem to depend on the legal and policy framework in which the
    Roy> nameserver is operating, but it would appear that at least
    Roy> some ccTLDs in EU states are concerned that this technical
    Roy> change _might_ raise legal or policy issues that _might_ be a
    Roy> barrier to deployment...

I must have taken extra stupid pills this morning. I don't understand
this. Data in the DNS is public. That's why it's there. So if some
jurisdiction says public data shouldn't be disclosed, then that data
shouldn't be in the DNS. End of story.

I'm confused. Earlier on this thread, somebody said NSEC records could
be used as an index into a TLD's whois database. Fine. But how could
the legal and policy framework where a name server operates have
anything to do with that?

Concerns about hypothetical legal and policy issues that might be a
barrier to deployment are far beyond the scope of this list.

---

From: Roy Badami <[email-masked]>
Date: Thu, 20 May 2004 12:45:39 +0100

>>>>> "Jim" == Jim Reid <[email-masked]> writes:

    Jim> This is already known. Now why do some people believe that
    Jim> this enumeration is a *technical* problem? 

Well, DNSSEC removes a piece of functionality from the DNS, namely the
ability to apply different access control to enumeration from that
this is applied to queries.  Since DNSSEC never had a functional spec,
it is of course rather difficult to claim that this is a technical
problem.

Since this is a piece of functionality that some people find useful
and others don't, it is hardly surprising that whether its absence
from the spec constitutes a problem is the subject of debate.

    Jim> specifically, are the technical protocol problems that arise
    Jim> from this?

Specifically, I suspect that the technical problem some people see is
that the DNSSEC protocol doesn't meet the functional spec that they
have in their minds.  It does meet the functional spec that other
people have in their minds.  Since to my knowledge there has never
been a formal functional spec for DNSSEC, both sides are in some sense
correct.

    Jim> If there's a layer-9 problem about compilation copyright or
    Jim> whatever, that needs to be solved at layer-9, not here. In
    Jim> fact it can't be solved here.

I suspect that most of the concerns relate to the EU Data Protection
Directive (and the transposed legislation of the member states),
rather than anything to do with copyright.

It's not at all clear to me that zone file enumeration does in itself
create data protection issues, but this is by no means a simple area
of legislation.  But if there _is_ an issue, then suggesting that EU
law should be changed in order to fit in with the decisions of the
IETF is not likely to be a productive approach...

    Jim> BTW, enumeration of an unsigned zone by unauthorised parties
    Jim> is theoretically possible. DNSSEC just makes this theoretical
    Jim> concern a practical possibility.

Yes, and the law is very good at coping with distinctions like
that... :-)

Essentially the question is, do the benefits of DNSSEC outweigh the
costs of no longer being able to prohibit enumeration?

If some domains have a serious issue with this, is it worth delaying
DNSSEC in order to try and enhance it to include the functionality
those domains desire?

Which decision is likely to give me a signed .co.uk zone sooner?  Only
the ccTLD operators concerned can attempt to answer that question.

    -roy

---

From: Jim Reid <[email-masked]>
Date: Thu, 20 May 2004 14:04:36 +0100

Roy> Well, DNSSEC removes a piece of functionality from the DNS,
    Roy> namely the ability to apply different access control to
    Roy> enumeration from that this is applied to queries. 

Access control has never been part of the DNS protocol. So DNSSEC
can't possibly remove something that was never there. :-) Most DNS
implementations provide access controls. But you shouldn't confuse
these with the DNS protocol. Though admittedly many people mistakenly
believe that the DNS protocol is "whatever BIND does".

    Roy> Specifically, I suspect that the technical problem some
    Roy> people see is that the DNSSEC protocol doesn't meet the
    Roy> functional spec that they have in their minds. 

This isn't a DNS protocol issue.

    Roy> It's not at all clear to me that zone file enumeration does
    Roy> in itself create data protection issues, but this is by no
    Roy> means a simple area of legislation.  But if there _is_ an
    Roy> issue, then suggesting that EU law should be changed in order
    Roy> to fit in with the decisions of the IETF is not likely to be
    Roy> a productive approach...

I wasn't suggesting that. And to turn it around, expecting the IETF to
solve abstract, hypothetical issues about an EU directive by
redesigning a DNS protocol isn't going to be productive either. The
DNSSEC protocol is legislature-neutral. It has to be. Now how that
protocol is used may well have legal considerations. But that's an
issue for each deployer to make a judgement about.

    Roy> If some domains have a serious issue with this, is it worth
    Roy> delaying DNSSEC in order to try and enhance it to include the
    Roy> functionality those domains desire?

Not if it means another couple of years wrangling over drafts and
re-opening old wounds. Especially if there's no-one left standing
after yet another protracted holy war.

If some domains have concerns about policy issues relating to protocol
deployment, they should address those policy issues in whatever is the
appropriate policy forum: ICANN perhaps.

---

From: "Sal Mangiapane" <[email-masked]>
Date: Thu, 20 May 2004 12:08:07 -0400

> > completely eliminate traversal.

first posting to any IETF list.  Please forgive me if this has been discussed.  I would appreciate references that I may read.

How will signing completely eliminate traversal?

Has anyone suggested a parallel internet standard similar to DNS that would be used for authorizing digital signatures?  Then, DNS
(and E-mail, VoIP, etc) could each define their specific required information for using digital signatures.  DNS would not be
burdened with implementing (and supporting) it's own PKI infrastructure.

Best Regards,

Sal

Salvatore Mangiapane

---

From: Paul Vixie <[email-masked]>
Date: Thu, 20 May 2004 18:31:35 +0000

> ... Currently, the DNS allows the operator of an authoritative
> nameserver to permit unauthenticated queries, but to deny enumeration
> of the zone to unauthenticated parties.

actually, it doesn't.  no rfc specifies this behaviour.  it's a BINDism
that other implementors have added because users think it's a useful
feature.  RFC 1034 and RFC 1035 say how to answer AXFR, but no RFC says
how to block it.

> With DNSSEC, this is not possible.  If you allow queries then you

if you want the ability to block enumeration to be part of the standard,
then you should try to write it up and get it done.  i suspect that IETF
will not agree that this is a necessary or "pure enough" feature.  but if
you can get it done, then you might be able to get IETF to think that
DNSSEC should preserve this functionality.

---

From: Andras Salamon <[email-masked]>
Date: Thu, 20 May 2004 20:51:58 +0200

On Thu, May 20, 2004 at 11:27:03AM +0100, Roy Badami wrote:
> Currently, the

As Jim stated, some _implementations_ of DNS servers allow this kind
of control.

> now less fine-grained than it used to be.

More accurately, a previously possible hack would no longer be possible.

> operating,

As stated by Jim, if a DNS operator is concerned about publishing
sensitive data, they should remove that data from the set of DNS records
accessible over a public network, by any means, including enumeration.

If, to comply with data protection legislation, an operator is relying
on enumeration of records not being possible, then that operator is
asking for trouble and is possibly already in breach (depending on the
jurisdiction).

First, don't put private data in a public database.  Second, the DNS
servers accessible over the Internet constitute a public database.
Conclusion: don't put private data onto DNS servers accessible over
the Internet.

How many times does this need to be repeated?

-- Andras Salamon                   [email-masked]

---

From: Roy Badami <[email-masked]>
Date: Thu, 20 May 2004 20:26:24 +0100

>>>>> "Paul" == Paul Vixie <[email-masked]> writes:

    Paul> if you want the ability to block enumeration to be part of
    Paul> the standard, then you should try to write it up and get it
    Paul> done.  i suspect that IETF will not agree that this is a
    Paul> necessary or "pure enough" feature.  but if you can get it
    Paul> done, then you might be able to get IETF to think that
    Paul> DNSSEC should preserve this functionality.

I have neither the motivation nor the inspiration to do that.  I'm
happy to leave that to those who feel a desperate need to use this
feature... :-)

I was just trying to counter what I perceived to be a possible sense
of "there's no possible reason why this issue should botther you" in
some of the comments in this thread.

There is a clear real-world difference between allowing queries and
allowing a wholesale download of the zone file.  There is most
definitely a difference in the real world between a theortical attack
and a practical attack.

These differences may well affect what a registry feels comfortable
doing in terms of European data protection legislation.

If ccTLD operators suggest that this might be an issue for them, then
it is IMHO unreasonable for anyone (other than a lawyer versed in this
area) to tell them they are wrong.

I realize that Ben Laurie has made it clear that he doesn't speak for
Nominet in terms of policy, and has not explicitly stated Nominet's
concerns, but it's clear from the URL below that the Nominet PAB does
have concerns (although not exacly what they are).

http://www.nominet.org.uk/Pab/PabMeetingPapers/ZoneFileEnumerationInDnssec.html

I'm assuming that the DNSSECbis document set is not going to be
derailed at this late stage -- it's hardly as if the NXT record is
some new idea which has been pushed through with little discussion,
and the world has been waiting long enough for deployable DNSSEC.

But if at a later date a significant number of ccTLD registries decide
that the issue is a showstopper for them, then I would hope that the
IETF will provide a suitable forum for these issues to be explored
further.

     -roy

---

From: Paul Vixie <[email-masked]>
Date: Thu, 20 May 2004 21:45:00 +0000

> some of the comments in this thread.

there's no possible reason why this issue should bother you.

if someone wants to enumerate the secondlevel names in a tld, they will
do it using well understood data mining techniques including watching
log files from busy mail and web and proxy servers, surfing the PTR's,
spidering the web itself, or buying the ISC Domain Survey four times a
year, or perhaps all of the above.

a tld operator's lack of desire for such enumeration cannot prevent it.
and dnssec's lack of compatibility with the well known BINDist hack of
turning off AXFR access or limiting it to well known addresses or TSIGs,
does not mean that dnssec has something wrong with it.

> definitely a difference in the real world between a theortical attack

but there is no real-world difference in enumerability between a tld
that allows open AXFR, a tld that does not allow AXFR, a tld that uses
dnssec (with NSEC chains), or a tld that does not use dnssec (or uses
it without NSEC chains, as in the NSEC2 proposal).

if you don't believe this, then tell me a tld and i'll enumerate it for
you, without using NSEC chains or AXFR.  it could take me a few months
depending on how many sites therein are linked from other sites, and how
many PTRs have target names under that tld, but sooner or later i'll get
it, either all of it, or enough to cover the part of your "whois" data
that you think preventing AXFR (and not using NSEC) is keeping others
from having an index to.

> doing in terms of European data protection legislation.

if you'll give me the phone numbers of the legislators in question, i'll
be happy to call them and tell them that because the names are exposed
in other contexts, that the internet is already in violation of their
data protection standards.  perhaps they'll decide to disconnect europe
from the internet in order to keep this data safe.

> IETF will provide a suitable forum for these issues to be explored

that's a reasonable middle ground, in my opinion.

---

From: Robert Elz <[email-masked]>
Date: Fri, 21 May 2004 04:50:02 +0700

Date:        Thu, 20 May 2004 12:45:39 +0100
    From:        Roy Badami <[email-masked]>
    Message-ID:  <[email-masked]>

  | I suspect that most of the concerns relate to the EU Data Protection
  | Directive (and the transposed legislation of the member states),
  | rather than anything to do with copyright.

No, that's clearly not the case.   There's nothing at all in the DNS
which can in any way violate any data protection acts - nor would it
make sense for anyone to attempt to legislate in that direction (and
even if you're one who assumes that legislatures have no sense at all,
this would be even further away than that).   What's in the DNS is
exactly what the owners of the data desire to advertise - it's put there
at their request.    This is just like a business directory, or the
phone book - except the DNS contains (unless someone of their own volition
adds the little used LOC, RP, etc records) even less personal type data
than those other directories do.   There doesn't need to be any way at
all to go from anything in the DNS to any kind of data that identifies
in any way the owner of the domain, or provides any information about
that entity (whether there should be a way to do that is a different
issue - the DNS itself mandates nothing like that - of course, organisations
are free to ad that kind of info if they desire, either directly in
RP, LOT, TXT etc, or indirectly, via www.domain web pages).

This isn't a case of someone collecting various personal data, and then
making it all available to anyone who asks (whois might be, but that's
not the issue here, not in any way at all - and irrespective of whether
or not whois is being "fixed").

The issue here is that some domains, typically domains which sell sub-domains,
like to believe that the data they have - ie: the list of names registered,
is their personal property, and no-one else should be able to get near it.

That's nonsense, and we shouldn't be doing anything to pander to that
opinion - if anything, being very explicit that there is no desire at all
to attempt to enforce any such notions is exactly what should be being
said.

kre

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 20 May 2004 23:21:14 +0000 (UTC)

> zone file.   That's the point of the DNS.

There can be security implications in finding out names of hosts in a domain,
without knowing the names in advance.  See for instance:

  Steven M. Bellovin, "Using the Domain Name System for System Break-Ins", in
  Proceedings of the Fifth Usenix UNIX Security Symposium, Salt Lake City, UT,
  June, 1995. http://www.research.att.com/~smb/papers/dnshack.pdf

Yes, the attack requires weaknesses in other applications, but the point is that
access to the information about names in a domain, acquired via zone transfers,
helped an attacker.  This still holds, for new not yet public weaknesses in
various applications.

Perhaps core of the problem is to realize that public data, handled in some
ways, can become a privacy or security issue, however paradoxical it may sound
at first.  A nice write-up that expand on this theme is:

  http://www.cs.uwyo.edu/~rex/privacy.html

Regards,
Simon

---

From: Jim Reid <[email-masked]>
Date: Mon, 24 May 2004 16:11:26 +0100

>> Base64 encoding is not possible for a label due to
    >> canonicalizing. The best one can do is base32 encoding (62.5%).

    Marcos> SHA-256 still works, though. Do we need something bigger?

Yes. Perhaps not today, but one day we might. It would be prudent to
plan for that now. Or else we'll have a flag day at some point in the
future when a longer hash string becomes essential. Remember it wasn't
long ago that MD5 was the flavour-of-the-month hash function. Who's to
say if SHA-N won't suffer the same fate in a couple of years?

---

From: [email-masked]
Date: Thu, 20 May 2004 14:20:55 +0000

> a) We face it's a problem, live with it and *say so* in the actual drafts.

	it seems that the origin of this "problem" is a contractual
	obligation TLDs assume when they sign the ICANN agreement.
	if this is the case, then it really is a non-problem from
	a protocol perspective.

> other) to fix whatever is broken.

	not worth the effort.
	
> won't remove the traversal problem.

	traversing data that by its nature is public seems a reasonable
	thing to want to do.  why is this a problem?

---

From: Jim Reid <[email-masked]>
Date: Tue, 25 May 2004 11:52:13 +0100

>>>>> "Marcos" == Marcos Sanz/Denic <[email-masked]> writes:

    Marcos> I don't know who are you labeling as a "newcomer", exactly
    Marcos> what part of the whole is "mumbo jumbo" and whether saying
    Marcos> "only 25 countries" isn't an oxymoron itself. 

Olafur's reference to "legal mumbo jumbo" is well made IMO. The lawyers
for Nominet and SIDN appear to be giving conflicting advice about the
imapct of an EU directive on NSEC. We're not lawyers, let alone
lawyers who understand this field. So unless the legal issues can be
explained to namedroppers by an expert, what we have is to all intents
and purposes legal mumbo-jumbo.

---

From: Jim Reid <[email-masked]>
Date: Wed, 26 May 2004 01:20:22 +0100

>>>>> "Roy" == Roy Badami <[email-masked]> writes:

    Roy> So a simplified NSEC2 that prohibited wild cards in the zone
    Roy> might well satisfy the concerns of the vast majority of TLD
    Roy> operators, and perhaps others, too.

This is not an option, even though I'd *love* to exterminate wildcards
from the DNS protocol. Suppose some form of NSEC2-style DNSSEC was
deployed by a TLD. It later decides it must have a wildcard in the
zone. So it has to drop this suggested NSEC2 flavour DNSSEC and either
becomes insecure or else presumably adopts NSEC flavour DNSSEC and
lives with enumeration and so forth. Icky.

It would be even worse for implementers and security-aware resolvers
as they'd need to keep track of which zone used which flavour of
DNSSEC. That could be very, very unpleasant. So if there's going to be
a Secure DNS protocol, it must be something that can work for every
and any zone.

Oh, and did I hear anyone say "Sitefinder"? :-)

BTW, remarkably few TLD operators have said anything here about the
concerns that have motivated this NSEC2 draft. Where's this "vast
majority"?

---

From: Jim Reid <[email-masked]>
Date: Wed, 26 May 2004 11:40:22 +0100

>>>>> "Marcos" == Marcos Sanz/Denic <[email-masked]> writes:

    Marcos> Perhaps this link might illustrate the magnitude of the
    Marcos> issue within CENTR area:
    Marcos> http://www.centr.org/technical/zone-access.html

This doesn't really help. It just shows that a bunch of TLDs restrict
AXFR to their slave servers and sometimes to trusted third parties. It
doesn't say why they do this. For instance, I can understand why DeNIC
wouldn't want random users to be able to slurp the 1GB or so of the
.de zone, guzzling bandwidth and needlessly loading the TLD's name
servers.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 26 May 2004 14:34:17 +0000

> > As far as I can tell there is only one requirement on the table:
> > NO ZONE walking of TLD's via negative answer records.
> 
> It's actually not a requirement only applying to TLDs.

in my day job, i'm in touch with a lot of enterprise dns users, and they
universally tell me that the data and/or names they consider sensitive
enough to worry about axfr or zonewalking, would also be dangerous for
queries, and so they run "split dns" so that only internal hosts can see
the data.  they've turned off external axfr because it's unnecessary, not
because it would expose data they care deeply about keeping private.  the
data they care deeply about keeping private is only available "internally."

i guess we'll need some kind of formal survey of the user base to get a
handle on exactly who cares about what.  i'm willing to retune the survey
software i wrote for "sitefinder" last year, or we can ask ben edelman if
he'd be interested.  things i'd like to know are:

1. are you concerned about external axfr? for privacy reasons, or resources?
2. are you concerned about zone walking? for privacy reasons, or resources?
3. do you use split-dns to keep sensitive data from being accessed by query?
4. are your axfr/zonewalk concerns based on carefully researched law opinions?
5. are your axfr/zonewalk concerns based on competitive/marketing worries?
6. are you only planning dnssec so your childzones can secure themselves?
7. how many tld's, sld's, 3ld's do these concerns pertain to?

there may be more.  but we can't do engineering without knowing the customer's
requirements, and we can't sit here and make up those requirements, or guess
them, or listen to the subset of customers who subscribe to this mailing list.
if we really want to say that we care about these concerns, we have to find
out what they are, exhaustively and objectively, and then publish the results.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 26 May 2004 22:07:57 +0000

> > AXFR to their slave servers and sometimes to trusted third parties.
> 
> Point taken. However, I think these TLDs aren't placing the zipped
> zone at everyone's disposal via anonymous FTP either.

well, they ought to.

but i guess every generation wants to learn that security through obscurity
is an illusion, the hard way.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 27 May 2004 14:17:52 +0000

> In virtue of what?

having NS RRs in the root zone which give rise to a top level domain is
a public benefit activity.  not just the subset of the public who wants
to register SLDs there, but the entire public -- everybody everywhere.
all of the people who decide to respect the trust deed.  everyone who
recognizes the property lines.

and these people have a right to know what you're doing with the property
that is only under your control because of their good will.  maybe they
want to count the names, maybe they want to run a web crawler over them,
maybe they want to be able to complain if their trademarks are being used
by other people.  specific motives don't matter.

anyone who wants secrecy for thirdlevel names can have it.  and anyone
whose business requirements include name secrecy can use a thirdlevel name.

but asking for SLD naming secrecy (by preventing TLD enumeration) is like
saying "i want you to give my container ship safe passage through international
waters, but it may or may not be loaded with drugs, plutonium, or whatever."
you can have one, or you can have the other, but the public should not have
to grant -- and historically, will not grant -- both.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 27 May 2004 16:49:58 +0200

> by other people.  specific motives don't matter.

Well spoken, I couldn't agree more.  I find it puzzling that some
TLDs, even those stating they have no problem with NXT/NSEC walking,
have been restricting zone access.

Perhaps this WG should simply acknowledge that organizations running
TLDs will never agree on policy issues.

Regards,
Simon

---

From: Edward Lewis <[email-masked]>
Date: Thu, 27 May 2004 11:54:41 -0400

>TLDs will never agree on policy issues.

This WG is supposed to be focusing on the protocol issues of the DNS 
and not on operational policy choices.  The goal is inter-operable 
specifications.

For the sake of the protocol and the applications relying on it we 
need to have just one approach to authenticated denial of existence. 
(The approach may be "not at all", NXT, NSEC, NSEC2, signing the 
responses.)  Allowing for alternate approaches means that 
applications will have to bear the burden of understanding how the 
DNS went about it's business.

The IETF way has been to engineer without regard to legal 
restrictions - that was the mantra in the says when cryptography was 
a large concern.  We do want the specs to be as widely usable as 
possible, but technical soundness is more important to compliance 
with legal opinions.

The last sounds absurd - but what good is a legally compliant 
specification that does not work?

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Even the voices inside my head are refusing to talk to me anymore.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 27 May 2004 18:19:20 +0000

> ...  I am assuming that DNSSECbis is modified so NSEC RRs
> contain a version field, which is set to 1 (say).

please don't do this.  find a signalling method, such as a dnskey
algorythm id or some existing MBZ field, that will allow new negative
signatures in the future (such as the one we're calling NSEC2) but
that will not require the dnssec-bis docset to be recut yet again.

changes to the dnssec-bis docset at this stage should be because of
document or protocol quality issues, not because of design changes
in the protocol itself.

---

From: Roy Badami <[email-masked]>
Date: Thu, 27 May 2004 19:59:03 +0100

>> contain a version field, which is set to 1 (say).

    Paul> please don't do this.

Sorry, perhaps I should have said:

    "I am assuming, for sake of discussion of the proposal, that the
    NSEC record is versioned, as proposed in this thread"

I didn't mean to imply anything in a wider context.

  -roy

---

From: Edward Lewis <[email-masked]>
Date: Thu, 27 May 2004 16:09:42 -0400

>I didn't mean to imply anything in a wider context.

I have my doubts that versioning NSEC is possible.

Let's say that we put in the current documents:

"When descending from a parent to a child, assume a verifier sees 
neither a DS RR nor a NSEC(v1) RR denying a DS RR and instead sees an 
NSEC(v2) in the authority section.  In this case the verifier is to 
assume that a new style of authenticated denial is in use and 
therefore assume the child is unsigned."

Assuming that the NSEC(v2) passes signature validation, how does the 
NSEC(v1)-era validator confirm that the right NSEC(v2) is there?  How 
do you detect an insertion error - that an eavesdropper didn't replay 
a non-material NSEC(v2) to deny secure access to that zone?

Assume a signed child, with such a clause I can reply with an 
alternate set of name servers and a non-material (but still signed) 
NSEC(v2) record.  I can make it look like the child is unsigned while 
still passing all of the security checks.

It seems to me that you'd have to turn off DNSSEC processing and 
restart for the next version once everyone has cleared out the old 
verifiers.

---

From: Roy Badami <[email-masked]>
Date: Thu, 27 May 2004 22:54:18 +0100

>>>>> "Edward" == Edward Lewis <[email-masked]> writes:

    Edward> Assume a signed child, with such a clause I can reply with
    Edward> an alternate set of name servers and a non-material (but
    Edward> still signed) NSEC(v2) record.  I can make it look like
    Edward> the child is unsigned while still passing all of the
    Edward> security checks.

I'm not sure you can reply with an alternate set of name servers,
since the NS RRset still won't have the right signature.  But you can
certainly respond without a DS record, and with an irrelevent NSEC(v2)
record, and fool an NSEC(v1) resolver into believing the child zone is
unsigned.

I did propose a solution to that; namely a null DS record.  I'm not
sure a versioned NSEC record is much use without a solution to this
problem.

      -roy

---

From: Edward Lewis <[email-masked]>
Date: Thu, 27 May 2004 21:49:29 -0400

>record, and fool an NSEC(v1) resolver into believing the child zone is

NS sets are not signed in referrals.  They are signed in the 
authoritative zone, which you may not reach if you have only the 
substituted servers.

>sure a versioned NSEC record is much use without a solution to this

See RFC 3658, section 1, in particular the 4th paragraph which states 
why the NULL KEY RR was dropped.  Part of that argument transfers to 
the idea of a null DS RRset.

With authenticated denials, you should not have to hold negative 
statements.  If the positive statement isn't there, you assume the 
negative statement.  This will hold for applications, it should hold 
for DNS if just to be consistent.

If adopted, another change for DNSSECbis, another incompatibility for 
NSEC(v1)-era validators or a guaranteed delay.

---

From: [email-masked]
Date: Fri, 28 May 2004 10:47:51 +0200 (CEST)

Ed, Paul,

This 'downgrade attack' is FUD (technically its there, but its a
non-issue). How would we EVER use a new signing algorithm, currently not
in use, if the downgrade attack would be a problem ?

Unless folk upgrade V1 (nsec) resolvers to V2 (nsec2), they see V2 zones
as unsigned.

My point is:

V2 zones do not yet exist. Would-be V2 zones are unsigned now. When V2
zones exist, they will still be unsigned to V1 resolvers. Eventually V1
resolvers will upgrade to V2 resolvers.

Part of the upgrade curve.

What exactly is the problem ?

As an analogy.

DNSSEC zones do not yet exist. Would-be DNSSEC zones are unsigned now.
When DNSSEC zones exist, they will still be unsigned to LEGACY resolvers.
Eventually LEGACY resolvers will upgrade to DNSSEC resolvers.

Part of the upgrade curve.

Roy

---

From: Edward Lewis <[email-masked]>
Date: Fri, 28 May 2004 10:06:25 -0400

>resolvers will upgrade to V2 resolvers.

Why would they appear unsigned to v1 resolvers?

>What exactly is the problem ?

Whether meeting the *perceived* new requirement is worth the cost of 
what is likely to be an architectural hack (in design) and 
potentially a great processing cost (in operations).

It's not clear to me that the premise of this debate is valid - that 
DNSSEC needs to answer to privacy concerns.  There is in evidence a a 
strong vocal component, but from just one effort.  There is also a 
counter argument being offered, that this is a non-issue. 
Additionally, there seems to be a lot of folks sitting on the side 
lines on the issue.

If we do move ahead and try to solve the problem, we have to figure 
out how.  Using an alternate key algorithm to signal what version of 
authenticated denial is in use?  Sounds hacky to me - what does the 
cryptographic algorithm have to do with the version of authenticated 
denial?  If it's not clear to a teenager, it's a hack.

Null DS or defining melt-down scenarios mean more protocol design 
work.  Quick hits like these can't be taken lightly, lest we engender 
corner cases later on.  There is the perceived need to get DNSSEC 
specs out now, and reasons for delay had better be well founded. 
(And we are still at "perceived new requirement.")

In operations, the cost of accomplishing obfuscation in authenticate 
denial will be greater than what we see planned now.  When I walked 
through an example I mentioned a performance vulnerability.  The best 
analogy to it is - there was once a TV game show called "Password" in 
which one person had a word in front of them and tried to get their 
partner to guess the word.  The one with the word couldn't use it and 
could only say one word at a time to guide the partner.  Often times 
it would take a number of other words to guide the partner into the 
needed word - if at all.

I think that is the problem.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Paul Vixie <[email-masked]>
Date: Fri, 28 May 2004 14:14:15 +0000

> in use, if the downgrade attack would be a problem ?

by adding new ones without removing old ones, and signing with both
during an extended overlap period.  (did you think dnssec could be at
its third unreleased version after a ten year period without solving
something so simple?)

> What exactly is the problem ?

the people who proposed to use bis2 with NSEC2-like functionality will
not also be using NSEC, they propose to do an upgrade without an overlap
period.  if they instead follow a timeline where the new NSEC2-like
functionality is introduced, and existing NSEC users do the "use both"
trick for an extended period while the validator population churns over,
and when these existing users stop using pre-NSEC2 data because it's not
needed, then and only then can new users (of NSEC2-only) deploy, then
all will be well.

paul, of "ed, paul".

---

From: [email-masked]
Date: Fri, 28 May 2004 16:37:45 +0200 (CEST)

> Why would they appear unsigned to v1 resolvers?

The authenticated denial V2 can not be used by V1 resolvers. Therefor
secure delegations in V2 zones, in worst case, are seen as unsigned since
the existence of a DS record can't be proven.

> potentially a great processing cost (in operations).

I really don't care about NSEC2, I care about being able to extend the
spec later on, giving those who do care an opporunity to do so.

I leave the politic bs of this specific alternative of NSEC to those who
care.

> denial?  If it's not clear to a teenager, it's a hack.

I agree. The alternate key alg is hacky. That would be a desperate thing
to do. It works ofcourse, especially when there is no alternative offered.

> (And we are still at "perceived new requirement.")

Bringing back NULL DS is a showstopper, I agree.

> I think that is the problem.

So how about those mets.

Roy

---

From: Edward Lewis <[email-masked]>
Date: Fri, 28 May 2004 10:47:20 -0400

>the existence of a DS record can't be proven.

I'm assuming failure to prove or disprove something is a service 
failure (SERVFAIL).  So, instead of being unsigned, they look broken 
- far worse.

>spec later on, giving those who do care an opporunity to do so.

I said the same thing about "sane NXTs" in the wake of the opt-in 
discussion.  To do that, you need to define the failure semantics 
(see above).  Because I was called away from the group, I don't know 
what happened to the thoughts about defining error reactions to 
"insane NXTs."  (I.e., an NXT that claims that it doesn't exist.)

>So how about those mets.

Back to .500!  I'll see 'em Monday. ;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Roy Badami <[email-masked]>
Date: Fri, 28 May 2004 15:48:58 +0100

>>>>> "roy" == roy  <[email-masked]> writes:

    roy> Ed, Paul, This 'downgrade attack' is FUD (technically its
    roy> there, but its a non-issue). How would we EVER use a new
    roy> signing algorithm, currently not in use, if the downgrade
    roy> attack would be a problem ?

    roy> Unless folk upgrade V1 (nsec) resolvers to V2 (nsec2), they
    roy> see V2 zones as unsigned.

That I'm happy with.  Changing the algorithm id would achieve this.

What makes me nervous is a scenario where a V1 resolver can check
signatures on V2 records, and in particular can follow secure
delegations from a V2 zone, but can't do so in a secure manner.

If people aren't getting the security they believe they're getting,
then that is dangerous.

Note that I'm not arguing that DNSSEC needs to be modified (either now
or later) to prevent enumeration.

Nor am I arguing that ccTLDs need to change their policies to allow
enumeration.

However this impasse does need to be resolved one way or another
otherwise I (as a user) won't get to see the benefits of DNSSEC.

	  -roy

---

From: [email-masked]
Date: Fri, 28 May 2004 17:03:02 +0200 (CEST)

> failure (SERVFAIL).  So, instead of being unsigned, they look broken

I understand. But I assumed versioning, where, if you can't cope with the
version, you fall back to default (dns).

> "insane NXTs."  (I.e., an NXT that claims that it doesn't exist.)

Ask chair, dunno, wasn't me, but you know that.

> Back to .500!  I'll see 'em Monday. ;)

Have fun :)

Roy

---

From: Edward Lewis <[email-masked]>
Date: Fri, 28 May 2004 14:01:11 -0400

>delegations from a V2 zone, but can't do so in a secure manner.

Ahh, this is a problem.  In order for a v1-era verifier to validate 
that a potentially valid v2 denial exists, the v2 record has to be 
signed by at least two keys (of each crypto system) - the old and the 
new.

What happens if a v2 denial record arrives with only a v1 signature? 
The assumption is that the v2 denial and the v1 denial have the same 
RR type.  If they differ only by the substitution of the hash, then 
the v1-era verifier will treat it as v1.

Recall that the notion of an RRset (always together, verifiable) is 
broken when if comes to the RRSIG set.  It is possible that via a 
replay, I can remove the v2-indicating RRSIG without detection.

As an aside - zones signers have multiple key algorithms to use now. 
When we talk about a new algorithm, a new algotithm per crypto system 
is assumed, right?  E.g., RSA/SHA-1, v1 and RSA/SHA-1, v2; DSA v1 and 
DSA v2, etc.

(Imagine introducing elliptic curve, do we have to add 2 algorithm 
numbers for it, v1 and v2.  And what if we rev something again - v3? 
It's ugly.)

---

From: David Blacka <[email-masked]>
Date: Fri, 28 May 2004 14:41:46 -0400

> signed by at least two keys (of each crypto system) - the old and the

Y'all are confusing me.

There are two ways of introducing non-backwards changes to DNSSEC being 
discussed at once here, I think.  One way is to use "unknown" algorithm 
numbers.  The behavior for DNSSECbis resolvers in this case has already been 
defined.

If this method is being used, then, v2 using zones will appear to be unsigned 
to v2 unaware resolvers.  There would be no way for a "V1 resolver" to check 
a "V2 zone".  Signing with both known and "unknown" algorithms would cause 
the zone to just be broken.

Another way would be to do something like add a version field to the NSEC 
record.  This would require thought and DNSSECbis changes to specify what the 
DNSSECbis compliant behavior is in the face of an unknown NSEC version.  
Presumably, however, since this signalling would be done through the NSEC 
record and not RRSIG, it *would* be possible for chain of trust to be 
established by a v1 resolver through a v2 zone.

> numbers for it, v1 and v2.  And what if we rev something again - v3?

Indeed.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    VeriSign Applied Research

---

From: Roy Badami <[email-masked]>
Date: Fri, 28 May 2004 19:58:35 +0100

>>>>> "Edward" == Edward Lewis <[email-masked]> writes:

    Edward> Ahh, this is a problem.  In order for a v1-era verifier to
    Edward> validate that a potentially valid v2 denial exists, the v2
    Edward> record has to be signed by at least two keys (of each
    Edward> crypto system) - the old and the new.

I'm not sure I follow.  The v1-era verifier will presumably never be
able to tell whether the v2 denial is valid, so I'm not sure this
solves the problem.

Given a malfeasor can always fool a v1-era verifier into believing a
delegation from a v2 zone is insecure (by providing a denial of the
existence of a DS record -- that the v1-era resolver can't verify), I
think it is desirably that a v1-verifier *always* regards a delegation
from a v2-zone as insecure.  This avoids a false expectation of
security.

	    -roy

---

From: Edward Lewis <[email-masked]>
Date: Fri, 28 May 2004 15:28:41 -0400

>from a v2-zone as insecure.  This avoids a false expectation of

If when you are confused you fail "open" you are very vulnerable. 
Ever try to just confuse a security guard to gain access to a 
building?  When it works, it's usually bad for the building (owner).