Subject: WG Last Call: DNSSEC bis documents

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 18 May 2004 08:48:24 +0200

Dear Colleagues,

This message starts the WG last call for the DNSSEC-bis document set.

   draft-ietf-dnsext-dnssec-intro-10.txt 
   draft-ietf-dnsext-dnssec-proto-06.txt 
   and
   draft-ietf-dnsext-dnssec-records-08.txt

The WG last call will complete June 1 2004. silence will be interpreted
as support for forwarding this document set, explicit support of the
document set is appreciated.

Please report editorial nits directly to <[email-masked]>.

Any protocol issues, not previously addressed, should be brought to
the list. 

Issues that where previously addressed and concluded are out of scope.

If this last call does not open new protocol issues we plan to do - if
needed - a last round of pure editorial corrections and push the
document set to the IESG shortly after.

The "html-wdiff" between these and the previous versions of the
documents are available on: 
    http://www.hactrn.net/ietf/dns/dnssec-editors/

We would like to extend our gratitude to all those that contributed
and to the editors team for doing the thorough job of compiling and
introducing the WG input into the docs.

Olaf and Olafur
DNSEXT WG chairs

                ------------------------------

Differences from last version and open issues

This release covers all 'formal' questions raised on the mailing list
and a number of editorial comments that where received both on and off
list.

At the risk of not being complete we would like to draw your attention
to the most significant changes with respect to the previous versions
of the documents. The changes are paraphrased, please refer to the
text in the I-Ds for the details.

Intro:

The term 'trust-anchor' has been defined in section 2. It is used
throughout the document set, it leaves the choice of a trust anchor
being a key or the hash of the key to implementors.

A section called "Scope of the DNSSEC Document Set and Last Hop
Issues" is introduced (section 5). It explains that the current
specifications has its limits in communicating results of the
validation process, that further work needs to be done, and that that
further work is out of the scope of the document set.

Records:

The requirements for setting the bitmap for the NSEC RR above a
delegation point were not specified. This has been fixed (section
4.1.2 and in proto see above)

Proto:

The requirements for setting the bitmap for the NSEC RR above a
delegation point were not specified. This has been fixed in section
2.3 last paragraph.

It has been made explicit that there are no special requirements on
servers that receive queries for security RR types which match the
content of more than one zone that it serves (section 3)

The purpose and use of AD and CD has been clarified (CD bit is in
section 3.2.2 and AD is in 3.2.3)

It is required that security aware servers and resolvers that
implement DNSSEC also implement DNAME processing (section 3.1, 3.2.4
and 4.8).

Determining security status was updated to reflect the different
states. (section 4.4 matches section 5 of intro)

The concept of "Bad Cache" to counter DOS attacks was expanded
(section 4.7)

-------------------------- message end --------------------------

--
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: Simon Josefsson <[email-masked]>
Date: Tue, 18 May 2004 15:54:17 +0000 (UTC)

>    draft-ietf-dnsext-dnssec-intro-10.txt 

Quoting the security considerations:

   DNSSEC introduces the ability for a hostile party to enumerate all
   the names in a zone by following the NSEC chain. NSEC RRs assert
   which names do not exist in a zone by linking from existing name to
   existing name along a canonical ordering of all the names within a
   zone. Thus, an attacker can query these NSEC RRs in sequence to
   obtain all the names in a zone. While not an attack on the DNS
   itself, this could allow an attacker to map network hosts or other
   resources by enumerating the contents of a zone. There are non-DNS
   protocol means of detecting and limiting this attack beyond the scope
   of this document set.

What are those "non-DNS protocol means of detecting and limiting the attack"?

I believe there are no viable means to prevent the attack in reasonable
scenarios where DNSSEC is used on the public Internet.  If my assessment is
correct, I don't think there should be text implying the problem can be taken
care of by non-DNS means.

If the statement refer to rate limiting and/or counting the number of queries
from a certain IP, that is so trivially defeated that I doubt that anyone will
go thru the trouble of implementing those precautions for NSEC abuse alone.  It
may generate more problems than it solve: false positives in the detection logic
may disable DNSSEC functionality at end nodes.  If the text refer to those
precautions, and the text is kept, in fairness a warning that the precaution may
cause failures should be added.

I believe it would be more honest to simply state that DNSSEC introduce this
security vulnerability, full stop.  I.e., drop the last sentence.

Thanks,
Simon

---

From: Jim Reid <[email-masked]>
Date: Tue, 18 May 2004 19:07:44 +0100

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    >>    DNSSEC introduces the ability for a hostile party to
    >> enumerate all the names in a zone by following the NSEC
    >> chain. NSEC RRs assert which names do not exist in a zone
    >> by linking from existing name to existing name along a
    >> canonical ordering of all the names within a zone. Thus, an
    >> attacker can query these NSEC RRs in sequence to obtain all
    >> the names in a zone. While not an attack on the DNS itself,
    >> this could allow an attacker to map network hosts or other
    >> resources by enumerating the contents of a zone. There are
    >> non-DNS protocol means of detecting and limiting this
    >> attack beyond the scope of this document set.

    Simon> I believe there are no viable means to prevent the attack
    Simon> in reasonable scenarios where DNSSEC is used on the public
    Simon> Internet.  If my assessment is correct, I don't think there
    Simon> should be text implying the problem can be taken care of by
    Simon> non-DNS means.

The original text should stand IMO.

Rate limiting and intelligent firewall filtering can reduce the
exposure to NSEC traversal. It should be fairly straightforward to
train a name server implementation to detect these attacks too. Sure,
these defences might not be much help against a well-disguised
attack. But they do provide some level of protection. So there are
some non-DNS means of detecting and limiting NSEC traversals that are
outwith the scope of the draft.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 18 May 2004 19:38:23 +0100

> outwith the scope of the draft.

I believe experience tells us that the people interested in these 
attacks are highly capable of disguising them well.

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: Jim Reid <[email-masked]>
Date: Tue, 18 May 2004 20:08:24 +0100

>>>>> "Ben" == Ben Laurie <[email-masked]> writes:

    >> exposure to NSEC traversal. It should be fairly straightforward
    >> to train a name server implementation to detect these attacks
    >> too. Sure, these defences might not be much help against a
    >> well-disguised attack. But they do provide some level of
    >> protection. So there are some non-DNS means of detecting and
    >> limiting NSEC traversals that are outwith the scope of the
    >> draft.

    Ben> I believe experience tells us that the people interested in
    Ben> these attacks are highly capable of disguising them well.

So what? That doesn't make the original text any less valid.

It shouldn't come as a surprise to anyone that there are Bad People on
the internet and some of them are remarkably good at covering their
tracks.

---

From: "Simon Josefsson" <[email-masked]>
Date: Wed, 19 May 2004 11:50:47 +0200 (CEST)

> outwith the scope of the draft.

Then inform the reader that any precautions do not remove the need to
worry about the issue, and any such precautions introduce new
denial-of-service considerations.  Just consider sending spoofed DNS
requests from a certain IP address, to trigger the NSEC traversal
detection logic, to disable DNSSEC functionality for a specific host.  The
host could be a DNS cache for a big ISP, thereby disabling DNSSEC
functionality for many users.

The last sentence of the current paragraph imply the problem can be
sufficiently solved by non-DNS means, and I have seen no indication that
this is true in general.

Until a solution has been fleshed out, I continue to believe that removing
the last sentence, that refer to experimental and incomplete precautions,
would be preferrable.  Second to that, I'd suggest appending the following
text, to give the reader some perspective on the effectiveness of those
non-DNS means:

   Note that these non-DNS means do not remove the need to worry about
   this issue, as at least the currently proposed precautions are trivially
   defeated.  Further, they may introduce new denial of service
   considerations, where an attacker may disable DNSSEC functionality
   for a specific host, or a set of hosts behind a specific DNS cache.

Thanks,
Simon

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 May 2004 12:35:44 +0100

I understand this draft comes very late in the day, but it is also my 
understanding that it addresses a very crucial issue for registries in 
the EU and possibly other regions: their obligation to protect 
registrant data.

I am sure that this will cause discussions of both a technical and 
political nature. I would like to make it clear from the outset that my 
comments on technical matters are on behalf of Nominet, but political 
comments are my own - I am not empowered by Nominet to discuss policy 
issues on their behalf.

I know that many of you will be at the DNSSEC deployment workshop in SF 
on Sunday - both Geoffrey and I will be there and will be happy to 
discuss this draft with anyone who is interested.

http://www.links.org/dnssec/draft-laurie-dnsext-nsec2-00.txt

I will, of course, be submitting this to the I-D editor, but because of 
the nearness of Sunday I thought it best to post it now.

Cheers,

Ben.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 May 2004 13:52:40 +0100

[email-masked] wrote:

> On Wed, May 19, 2004 at 12:35:44PM +0100, Ben Laurie wrote:
> 
> 	I guess that I remain unconvinced.
> 	What -registrant- data is stored in the DNS?
> 	In most cases, -registrant- data is stored in
> 	some whois-like database.

NSEC provides an index to whois.

Cheers,

Ben.

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 19 May 2004 09:35:54 -0400

Just did a quick first read -

Is the NSECINFO RR really necessary?  It seems redundant to me and just
another RR/RRSIG combo to be placed in the additional section for a negative
response.  The hash ID could be the first field in the NSEC2 RDATA (just
like in DS, RRSIG, etc) - no need for another record to store that.  The
iterations could be stored there as well, but I don't know how useful it is
to begin with.  Why is it 3 octets long (odd number btw)?  Couldn't it
become a DoS attack vector by a malicious or silly admin setting the number
arbitrarily high?

I also fail to see the use of the salt value in the NSECINFO.  The draft
states it is there to prevent dictionary attacks.  Couldn't an attacker
could just get the salt, and then perform the attack?

I would recommend dropping the NSECINFO RR altogether and move the digest
code and the iterations (though shortening the field to 2 octets) into the
NSEC2 RDATA.  Although I wouldn't mind dropping the iterations field as
well.

Please correct me if I am misreading the NSECINFO RR spec.
Scott

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Ben Laurie
> Sent: Wednesday, May 19, 2004 7:36 AM
> To: [email-masked]
> Subject: Proposal to fix NSEC
>
>

---

From: [email-masked]
Date: Wed, 19 May 2004 15:40:01 +0200 (CEST)

<hat EDITOR=off>

You're basically bringing back the NO record, with some added jazz:
http://josefsson.org/draft-ietf-dnsext-not-existing-rr.txt

We've already done this 3 years ago and I see no reason in bringing this
back. It does not solve a problem (see below). It does not bring anything
new.

A few notes on the spec:

1) You propose an either/or architectural design. No provisioning for bw
   compatibility with nsec, nor signalling that a
   zone/server/resolver/validator/stub supports either/both. You need
   signalling since the nsec and nsec2 are mutually exclusive.
   Unless your NSEC2 proposal absoletes NSEC (bring out the flags for
   flagday), but then its not an 'alternate scheme' like the proposal
   claims. If you're thinking of signalling, there is no room for
   signals in NSEC records (been there done that).

2) The wildcard/closest encounter text is broken. The assumption is that
   even empty (but existing) nodes need a record (EXIST). Which makes them
   NOT EMPTY (since the type EXIST exists). Not to mention the extra
   records you have to put up with: every EXIST type needs a sig plus an
   nsec[2] plus a sig. This assumption is false. Handling wildcards in
   dnssec is complex.

3) The NSECINFO spec is broken. You can't proof the NSEC type exist, since
   you need the NSECINFO record to verify NSEC that proofs NSECINFO
   exist. Thats a circular dependency.

In case you're trying to solve zone walking: Zone walking is still
possible, hash by hash. An offline dictionary attack (remember that the
NSECINFO trick does not work) does the rest. To speed things up, you could
brute-force labels with length up to 5 or 6 characters.

Cheers,

Roy

---

From: Jim Reid <[email-masked]>
Date: Wed, 19 May 2004 14:50:50 +0100

>> I guess that I remain unconvinced.  What -registrant- data is
    >> stored in the DNS?  In most cases, -registrant- data is stored
    >> in some whois-like database.

    Ben> NSEC provides an index to whois.

If there's a problem with disclosure of whois data, fix whois. [There's
already a WG doing precisely that.] Redesigning the DNSSEC protocol to
fix a whois problem does not seem to be sensible.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 May 2004 14:48:36 +0100

Scott Rose wrote:
> to begin with.

Sure, the reason I stored it as a separate record was because of 
redundancy, since it has to be the same for the whole zone, but it might 
indeed make more sense to include it in NSEC2.

> Why is it 3 octets long (odd number btw)?

2 was too few, in my view.

> Couldn't it

Yes, I noted that somewhere, implementations should probably just fail 
for values locally considered to be too high.

> could just get the salt, and then perform the attack?

Its to prevent precomputed dictionary attacks (this is explained in the 
security considerations). This matters if your zone is worth rescanning 
frequently.

> NSEC2 RDATA.  Although I wouldn't mind dropping the iterations field as

I would have no strong objection to moving it. I'm not sure I believe 2 
octets is sufficient for iterations, and I don't think dropping 
iterations is a good idea, since that is how you choose the cost of 
dictionary attacks.

Cheers,

Ben.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 20 May 2004 00:15:15 +1000

This sort of thing has already been looked at and rejected.
	
	The existing NSEC names also have a useful property in that
	they provide the wildcard name that would otherwise match
	the query name.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Wed, 19 May 2004 16:20:53 +0200

Roy,

> back.

With all my respects, the reason is on the table:
the NSEC traversal problem to be fixed within DNS.

Obviously, the notes on the spec you've just submitted have to be 
addressed.

Regards,
Marcos

---

From: David Blacka <[email-masked]>
Date: Wed, 19 May 2004 10:22:55 -0400

> What are those "non-DNS protocol means of detecting and limiting the
...
> I believe it would be more honest to simply state that DNSSEC introduce
> this security vulnerability, full stop.  I.e., drop the last sentence.

I, too, would like to see this last sentence dropped, because this sentence 
provides no useful information.

There may or may not be non-DNS means of limiting NSEC walking, but simply 
stating that they exist somewhere out there in the wide, wide world without 
providing a pointer to any of them is not helpful to the reader.

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

---

From: [email-masked]
Date: Wed, 19 May 2004 16:39:18 +0200 (CEST)

> the NSEC traversal problem to be fixed within DNS.

NSEC traversal will still exist. hash by hash. Using NSEC2 the attack
vector is shifted. From an online dictionary to DNS attack, to an offline,
dictionary to NSEC2-hash attack.

An obscured circular list is still a circular list. Getting rid of the
circular list is a better solution imho, but that has other issues like on
the fly signing. private-key stored on an online-box, etc.

Roy

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 May 2004 15:40:38 +0100

> http://josefsson.org/draft-ietf-dnsext-not-existing-rr.txt

Correct, though I did reinvent it all on my own :-)

>    signals in NSEC records (been there done that).

Surely the returned RRs could simply be either NSEC or NSEC2, and the 
resolver chews whichever it gets?

>    nsec[2] plus a sig. This assumption is false. Handling wildcards in

Why is the assumption false?

>    exist. Thats a circular dependency.

I'm not sure I understand this, but in any case, it has been proposed 
that the NSECINFO record is rolled into NSEC2, which would certainly 
remove circularity, if any exists.

> brute-force labels with length up to 5 or 6 characters.

If we made hashes take, say, 10 ms to compute, then this attack would 
take nearly a year. This is the point, surely? I'd note that simply 
querying for a 6 character domain name only takes that kind of CPU time 
without any attempt to optimise it (i.e. I used dig).

Cheers,

Ben.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 May 2004 15:43:41 +0100

> fix a whois problem does not seem to be sensible.

The problem is the _combination_ of NSEC and whois.

Cheers,

Ben.

---

From: [email-masked]
Date: Wed, 19 May 2004 16:53:49 +0200 (CEST)

> resolver chews whichever it gets?

That means a requirement to implement both. If I just implement either
NSEC or NSEC2 in my resolver, one can be used to downgrade the other.

> Why is the assumption false?

That would be in the dnssec-protocol draft. Empty non-terminals are not
special in DNSSEC.

> without any attempt to optimise it (i.e. I used dig).

I would prefer an offline dictionary attack over a online querying attack
if I did not want to leave to much trails.

Roy

---

From: Jim Reid <[email-masked]>
Date: Wed, 19 May 2004 15:56:42 +0100

>> still possible, hash by hash. An offline dictionary attack
    >> (remember that the NSECINFO trick does not work) does the
    >> rest. To speed things up, you could brute-force labels with
    >> length up to 5 or 6 characters.

    Ben> If we made hashes take, say, 10 ms to compute, then this
    Ben> attack would take nearly a year. This is the point, surely?

Ever heard of Moore's law? Or how about writing an M$ worm that can
harness most of the world's Windows boxes for a dictionary attack?

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 May 2004 17:12:11 +0100

[email-masked] wrote:

> That means a requirement to implement both.

Yes. Or we could deprecate NSEC.

> If I just implement either

I'll come back to this when I've thought about it more.

> if I did not want to leave to much trails.

NSEC makes this equally easy, of course, so I don't really see how this 
is relevant?

Cheers,

Ben.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 May 2004 17:13:01 +0100

Jim Reid wrote:

> Ever heard of Moore's law? 

Indeed I have, which is why iterations is a tunable parameter.

Cheers,

Ben.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 19 May 2004 16:19:48 +0000 (UTC)

Jim Reid <jim <at> rfc1035.com> writes:

> 
> >>>>> "Ben" == Ben Laurie <ben <at> algroup.co.uk> writes:
> 

Right.  But designing DNSSEC to not introduce new realistic attack vectors,
compared to vanilla DNS, has always appeared sensible to me.  Whois is one
example of where the new attack vector can be utilized.  Improving the whois
protocol will remove whois as an example for our discussions, but it will not
remove the traversal problem.

The alternatives to NSEC do reduce the attack vector into an offline dictionary
attack, which I believe is an acceptable risk. Especially considering that
online dictionary attacks cannot be prevented fully either.  And nobody claims
online dictionary attacks is a problem today.  Keep in mind that online
dictionary attacks are cheaper than offline dictionary attacks.

Thanks,
Simon

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 19 May 2004 12:20:28 -0400

I'm trying to fit the EXIST RR into the NSEC response cases in
draft-ietf-dnsext-dnssec-proto.  I think I understand how the NSEC2 and
EXIST combos would work.

Only case 2 (no name, no wildcard) would be affected.  However, could it be
possible to do a EXIST walk of a zone?  If EXIST RRs exist at every
authoritative name in the zone, it is possible for an attacker to do the
same sort of walk just in reverse.

For example:  in the response in the draft, what if an attacker then queries
for "a.b.b.d.e IN A" or similar?  assuming they they get a negative answer
again, a new closest encloser is given (and another point in the namespace).

Scott

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 May 2004 17:23:52 +0100

[email-masked] wrote:
> On Wed, May 19, 2004 at 03:43:41PM +0100, Ben Laurie wrote:
> 	again, what registrant data is stored in the DNS?
> 	Its clearly -NOT- in the NSEC RR, based on the spec.
> 
> 	if your concern is the binding of registrant data to
> 	some lable stuck in the DNS, then the problem is not
> 	the DNS or its attendent lables, neither is it the
> 	registrant data.  The problem is the -BINDING- between
> 	these two datasets.  And that binding is not DNS related.

Then clearly it is not whois related either - so what do we fix?

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 May 2004 17:59:01 +0100

> same sort of walk just in reverse.

To be clear, EXISTs only exist where no other RR exists, but I don't 
think that changes your point.

> again, a new closest encloser is given (and another point in the namespace).

Clearly, if they want to know whether one of b.b.d.e, b.d.e, d.e or e 
exists, it is only a little more expensive to just ask than to discover 
it by being handed the EXIST record. Paricularly since in practice it is 
almost always true that the closest encloser will be the name with the 
first element removed, and will already be known to the attacker.

Cheers,

Ben.

---

From: Jim Reid <[email-masked]>
Date: Wed, 19 May 2004 19:01:04 +0100

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> Right.  But designing DNSSEC to not introduce new realistic
    Simon> attack vectors, compared to vanilla DNS, has always
    Simon> appeared sensible to me.  Whois is one example of where the
    Simon> new attack vector can be utilized.  Improving the whois
    Simon> protocol will remove whois as an example for our
    Simon> discussions, but it will not remove the traversal problem.

While this is true, I'm not convinced that there really is a traversal
problem. The DNS is a public database after all. Of course some people
restrict zone transfers for operational and policy reasons, notably
TLDs. But these are not protocol issues. And while it would be nice if
DNSSEC didn't make zone traversal easy -- like your now dead NO record
draft tried to do -- it's so far been too hard to find a way of doing
that which works for all possibilities for authenticated proof of
non-existence. If there weren't so many tricky corner cases,
especially with wildcards, no doubt something like your NO record
would have been incorporated into the current drafts.

I think we're at a point with DNSSEC where an engineering decision
needs to be made. The question shouldn't be whether DNSSEC is perfect
or not but if DNSSEC is "good enough".

    Simon> The alternatives to NSEC do reduce the attack vector into
    Simon> an offline dictionary attack, which I believe is an
    Simon> acceptable risk.

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?

---

From: Jim Reid <[email-masked]>
Date: Wed, 19 May 2004 19:06:06 +0100

>> if your concern is the binding of registrant data to some lable
    >> stuck in the DNS, then the problem is not the DNS or its
    >> attendent lables, neither is it the registrant data.  The
    >> problem is the -BINDING- between these two datasets.  And that
    >> binding is not DNS related.

    Ben> Then clearly it is not whois related either - so what do we fix?

The BINDING. Though replacing whois is also attractive.

---

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

> problem. The DNS is a public database after all. Of course some people

Jim, you know I'm all with you here and I've been arguing for years that AXFR
restrictions are not a security but an obscurity measure.

> restrict zone transfers for operational and policy reasons, notably

They've done it due to BIND (and other products) introducing the ability
and due to "security consultants" recommending it and for other non-reasons.
If it were only for those I'd say: go, do your homework.
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.

> TLDs. But these are not protocol issues. And while it would be nice if

Well, you're right, the DNS wasn't built to keep things secret but instead
to publish data. But now we have a "feature" that has been an (unspoken)
part of the system for years, which has a value for a limited but important
set of zones and it's going to go away.

> or not but if DNSSEC is "good enough".

The problem is that the engineering question is closely coupled to an
operational or maybe even policy question for a key part of the infrastructure.
If DNSSEC isn't "good enough" for TLD zones (or a significant subset of those),
that's a show stopper. Yes, we could have had this discussion earlier.

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

-Peter

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 19 May 2004 14:56:53 -0400

> From: Ben Laurie [mailto:[email-masked]]
> >

Then I don't believe I understand where the EXIST RR would be in a zone.
For example, in a flat zone (all authoritative names in the zone are
"<some_label>.example.com." and no wildcards.  Is there only one EXIST RR
(saying "example.com  IN EXIST"), or multiple?  Or is generated and signed
on the fly?

Bringing back Roy's comment on the wildcard clarification and the DNSSECbis
protocol draft, I think Sections 4 and 5 would need to be updated.
Specifically, the response in the example in section 5 would not need NSEC2
RRset (b).

Scott

---

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

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

---

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

Scott Rose wrote:

>>>Only case 2 (no name, no wildcard) would be affected.  However,
>>
>>could it be
>>

There would be none, since, presumably, there would be at least one 
other RR for example.com (e.g. SOA).

It is absolutely not generated and signed on the fly.

> Specifically, the response in the example in section 5 would not need NSEC2

Are you referring to sections 4 and 5 of DNSSECbis? Or of NSEC2?

Cheers,

Ben.

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 19 May 2004 15:54:08 -0400

> Are you referring to sections 4 and 5 of DNSSECbis? Or of NSEC2?

Sections 4 and 5 in the NSEC2 draft first, the eventually the DNSSECbis
docset if NSEC2 is adopted.   With the wildcard clarification work Ed Lewis
started a while back, it makes it easier to understand wildcards and denial
of existance responses.

Scott

---

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: Peter Koch <[email-masked]>
Date: Thu, 20 May 2004 15:06:53 +0200

>         It's a CPU burden for the authoritative nameserver.

Yes, but the operators in question (TLD registries) should be able to deal
with this.

>         authenticated zone content.

Most TLDs already have all their nameservers under their very own control
(although not necessarily on a physical level). So betrayal by 2ndary isn't
a problem. For cases where one of the servers is compromised, DoS is possible
even with DNSSEC because an attacker would be able to provide for forged
signatures. The risk of forged entries can be reduced by using different
keys. The offline key would be used to sign RRSets, securing positive responses
(mostly DS RRs). The online key could be used to sign online NSEC RRs to
be generated on the fly (and pointing at some uncritical, maybe not even
existing name). It's just that I don't see an opportunity to signal this
distinction at the moment.

-Peter

---

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: Derek Atkins <[email-masked]>
Date: Thu, 20 May 2004 10:45:16 -0400

Peter,

> Yes, but the operators in question (TLD registries) should be able to deal

I don't think you understand what level of CPU burden online signing
can be in the face of unauthenticatd queries.  It's a DoS attack
waiting to happen.  Turn this "feature" on in your DNS servers and I
can bring your server to its knees without even trying.  It's very
simple: I send a string of random requests to your server for random
(non-existant) hosts in your authoritative zone.  To make sure you
can't block this easily at your firewall I spoof the sender address (I
don't care about the responses anyways).

Even if modern TLD CPUs can handle 10,000 RSA encryptions per second
(my laptop tops out at around 2,000 with full-bore CPU usage), that
just means I need to send you 10,000 requests per second.  That's
about 10mbps (probably even less).  Not too hard to achieve.  Note
that my 2000/s is full-CPU.  You need a good deal of CPU to actually
perform the DNS query/response, so that reduces the number of actual
RSA operations possible.

The problem is that it's just too prone to DoS attacks....  Which is BAD.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

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: "Sal Mangiapane" <[email-masked]>
Date: Thu, 20 May 2004 12:36:51 -0400

> can be in the face of unauthenticated queries.  It's a DoS attack
> (non-existent) hosts in your authoritative zone.  To make sure you

A standard could be established to help thwart DoS attack.

1) Only use signatures for queries from named name servers (ns record exists).
2) Only use signatures when the named name server uses signatures (it signed the request).
3) When your server load exceeds a predefined limit (like 30% CPU) drop all query requests from unknown name servers (such as
caching name servers).
4) When your server load exceeds some next higher limit (like 50% CPU) drop all query requests except when signed from a named name
server.

This methodology will also encourage adoption of the new standard for obvious reasons.

Of course,
1) could easily be spoofed.
2) could not, but may tie up your DNS server verifying signatures.

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: Peter Koch <[email-masked]>
Date: Thu, 20 May 2004 22:00:19 +0200

> How many times does this need to be repeated?

try until it's true. I'd really appreciate if people wouldn't generally
neglect any difference between every single record of data (or a set of data)
being public (i.e. accessible anonymously without any further authorization)
and all of the data being accessible at once. There is a difference and
we have several examples, whois itself being one of it. Another are "public"
phone directories allowing for name to number mappings but not for bulk
transfer or "reverse mapping". (Commercial) databases of other kinds come to
mind. So, just repeating over and over again that "public" is "public"
doesn't lead us anywhere.

Now, back to DNS, it may well be that it wasn't designed to protect the
zone(s) from being XFRed, but there are other things it wasn't designed for,
too (like being a flat keyword index). Again, AXFR doesn't constitute a
technical or security problem per se. Of course that's a layer 9 problem,
but so what? Isn't DNSSEC as a whole there to solve layer 9 problems?
If the world weren't so bad, we wouldn't need any security protocols.

Now, for AXFR blocks not being standardized: REFUSED does exist. There's
no (longer a) DNS way to communicate between master and slaves the necessary
authorization info, but that doesn't prove anything more than you cannot rely
upon it (unless you have out of band communication).

I believe DNSSEC is necessary and I want it deployed - without a major
protocol redesign which would cost more time than available - given that
there are other protocols in the queue which kind of need a secured DNS.
But here's a deployment obstacle which has come up really late (well, NO
was worked on a few years ago, but the problem wasn't emphasized back then)
and which needs an engineering solution. Can we work on one?

-Peter

---

From: Ben Laurie <[email-masked]>
Date: Thu, 20 May 2004 21:51:08 +0100

> distinction at the moment.

If you were going to do this, it would make more sense to simply sign a 
denial of the existence of the particular domain, rather than messing 
with NSEC records. If you had a signed denial, then the easy way to 
signal it is to have an RR that is specifically for that purpose (that 
is, when you receive a NOTHISDOESNTEXIST RR you expect it to be signed 
with the special key used for that purpose alone).

This is another solution I didn't dare suggest!

Cheers,

Ben.

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 20 May 2004 23:19:43 +0200

On May 20, 2004, at 3:06 PM, Peter Koch wrote:

> The offline key would be used to sign RRSets, securing positive 
> responses

Good idea...

There is no reason why one part of a zone cannot be signed with zone 
signing key 1 and another
signed with zone signing key 2. There is no need for signaling.

This is an essential property to be remembered during key rollovers 
when there may be several RRsets from a zone living somewhere in a 
cache that have signatures made with valid keys. The zone operator 
needs to provide the public key material of both the keys during the 
rollover.

Note also that if you minimize the signature validity time on the apex 
keyset you reduce the useful lifetime of the a compromised key.

--Olaf
  (no hats)

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 20 May 2004 23:24:29 +0200

Forwarded message 2 out of 2 (there where problems posting)

> From: Paul Vixie <[email-masked]>
> Date: May 19, 2004 6:49:40 PM CEST
> Subject: this week in dnssec, 10 years ago.
>
>
>> ...  But designing DNSSEC to not introduce new realistic attack 
>> vectors,
>> compared to vanilla DNS, has always appeared sensible to me.  ...
>
> simon picked an interesting point in time to make his concerns widely 
> known
> and propose a significant protocol/system design change to address 
> them.  do
> we have some kind of carrier wave / harmonic underlying this whole 
> project?
>
>> The alternatives to NSEC do reduce the attack vector into an offline
>> dictionary attack, which I believe is an acceptable risk. ...
>
> this week in dnssec, 10 years ago, donald eastlake proposed "NX" which 
> became
> "NXT" and then "NSEC".  see below.  how much longer do we want to work 
> on
> this?  i was thinking we'd begin early deployment work this month or 
> next...
>
> re:
>
> --------
>
> To: [email-masked]
> Subject: Thought on non-existant and wildcarded names
> Date: Mon, 09 May 94 14:55:42 -0400
> From: "Donald E. Eastlake 3rd (Beast)" <[email-masked]>
> X-Mts: smtp
>
> This is what I came up with and am thinking of merging into the next 
> draft:
> 
> INTERNET-DRAFT                          DNS Protocol Security 
> Extensions
>
>
>
>
>
>
>                 Domain Name Protocol Security Extensions
>
>
>
> W. Special Handling of Wildcard Matches and Non-existence
>
> DNS security provides the means for establishing integrity and data
> origin authenticity.  However, this applies only to actual RRs in a
> secured zone.  There are two places where would be insufficient
> without some additional steps.  The first case is securely indicating
> the absence of data.  The other is the that of wildcard RRs.  Wildcard
> RRs have node names whose first label is an asterisk ("*").  These act
> as instructions for synthesizing RRs not actually present.
>
> Since there are an enormous number of possible DNS names, it is
> impossible to create and sign separate existence RRs for all possible
> wildcard matches or denial RRs for all possible queries for
> non-existent data.  These are handled securely as described below.
>
> The following example zone is used in this section:
>
>      FOO. IN     SOA  QQ.FOO.  admin.QQ.FOO.
>                       (   60   ; serial
>                           7200  ; refresh
>                           600  ; retry
>                           1000000  ; expire
>                           60  ; minimum
>                       )
>                  NS      QQ
>                  NS      X.BAR
>                  MX  10  A1
>                  MX  99  QQ
>
>      A1          A       192.0.2.252
>                  A       192.245.52.250
>                  MX  10  A1
>                  MX  99  QQ
>
>      X.BAR       A       192.0.2.253
>                  A       192.245.52.249
>                  MX  10  X.BAR
>                  MX  80  Y.Z.BAR
>
>      Y.Z.BAR     A       192.245.52.248
>                  MX  10  Y.Z.BAR
>                  MX  80  Z.BAR
>
>
> Donald E. Eastlake 3rd & Charles W. Kaufman                     [Page 
> 1]
> 
>
> INTERNET-DRAFT                          DNS Protocol Security 
> Extensions
>
>
>      *.BAR       MX  10  Y.Z.BAR
>                  MX  80  X.BAR
>
>      QQ          A       192.0.2.254
>                  MX  10  QQ
>                  MX  50  A1
>
>
>
> W.1 Wildcard RR Matches
>
> The Domain Name System contains a provision for RRs that match any name
> below a point in the name tree unless a more specific name matches.
> (See section 4.3.3 in RFC 1034.)  For example, in zone FOO, there is an
> RRs named *.BAR.FOO and also more specifiec RRs with names X.BAR.FOO 
> and
> Y.Z.BAR.FOO.  The wildcard RRs with name *.BAR.FOO can be though of as
> instructions for synthesizing RRs with matching names and the same
> class, type, TTL, and RDATA, when a matching query arrives.
>
> If a type MX query is made to zone FOO as above for Z.BAR.FOO, it will
> match the wildcard RR and not any of the more specific RRs. So a
> response will be made with the queried name (Z.BAR.FOO) substituted for
> the wildcard name (*.BAR.FOO).  On the other hand, a query for 
> X.BAR.FOO
> or Z.BAR.FOO or anything below them will ignore the wildcard and either
> respond with the specific RR or a non-existent name response.  Queries
> for xx.FOO, where xx is any label but BAR, will be unaffected by the
> wildcard.
>
> A wildcard is frequently used for such purposes as causing mail to a
> large class of name to be sent to a particular set of mail gateways by
> using wildcard MX RRs.
>
> Wildcard RRs are signed by SIG RRs with the same wildcard name and the
> signature is based on the wildcard name.  To make it possible to verify
> the signature, the SIG RR has a LABELS field which gives the number of
> actual labels in its name, above the wildcard *, if there is one, not
> counting the null label for root.  If the actual number of labels
> present in the RR name equals the LABELS field, then no wildcard is
> involved.  If the actual number of labels present is larger, then an *
> can be temporarily substituted for the synthesized part of the name to
> verify the signature.
>
> If a wildcard RR has been supressed because it appears inside a SIG on 
> a
> request for a security aware resolver to a security aware server, the
> resolver has to do the wildcard expansion.
>
>
>
>
>
>
>
> Donald E. Eastlake 3rd & Charles W. Kaufman                     [Page 
> 2]
> 
>
> INTERNET-DRAFT                          DNS Protocol Security 
> Extensions
>
>
> W.2 Non-existent Types
>
> When a secure query is made for a name and class that exist is a zone,
> but for an RR type that does not exist, there needs to be a secure way
> to know that the type does not exist.  This can be determined by
> retrieving and examining all the SIG RRs.  All types will be indicated
> within the SIGs and the partial RR set signets in the SIGs can be used
> to assure that a complete set of SIGs has been retrieved.
>
> Thus a query from a security aware resolver for a name that exists for
> some RR in a zone but not as the owner of any RR of the requested type
> should be answered by a security aware server with the usual error but
> with all the SIGs for that name as additional information.
>
>
>
> W.3 Nonexistent Names
>
> The nonexistence of a name in a zone is indicates by the NX resource RR
> for a name interval containing the nonexistent name.  An NX RR is
> returned in the additional information section, along with the error, 
> if
> the client is security aware.  NX RRs can also be returned if an
> explicit query is made for the NX type.
>
> The existence of NX records means that any query for any name to a
> security aware server serving a secure zone should result in an reply
> containing at least one signed RR.
>
>
>
> W.3.1 The NX Resource Record
>
> The NX resource record is used to securely indicate that no RRs with an
> owner name in a certain name interval exist in a domain (or that any
> specific names in that interval are masked by a wildcard).
>
> The owner name of the NX RR is an existing name in the zone.  It's 
> RDATA
> is another existing name in the zone.  The presence of the NX RR means
> that no name between its owner name and the name in its RDATA area
> exists.  This implies a canonical ordering of all domain names in a
> zone.
>
> The ordering is to sort labels as unsigned left justified octet strings
> where the absence of a byte sorts before a zero byte.  Names are then
> sorted by sorting on the highest level label and then, within those
> names with the same highest level label by the next lower label, etc.
> Since we are talking about a zone, the zone name itself always exists
> and all other names are the zone name with some prefix of lower level
> labels.  Thus the zone name itself always sorts first.
>
>
>
> Donald E. Eastlake 3rd & Charles W. Kaufman                     [Page 
> 3]
> 
>
> INTERNET-DRAFT                          DNS Protocol Security 
> Extensions
>
>
> There is a slight problem with the last NX in a zone as it wants to 
> have
> an owner name which is the last existing name is sort order, which is
> easy, but it is not obvious what name to put in its RDATA to indicate
> the entire remainder of the name space.  This is handled by treating 
> the
> name space as circular and putting the zone name in the RDATA of the
> last NX.
>
> There are additional complexities due to interaction with wildcards as
> explained below.
>
> The NX RRs for a zone can be automatically calculated and added to the
> zone by the same recommended off-line process that signs the zone.  The
> NX RRs TTL should not exceed the zone minimum TTL.
>
> The type number for the NX RR is xxx.
>
>
>
> W.3.2 NX RDATA format
>
> The RDATA for an NX RR consists simply of a domain name.
>
>
>                      1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |     next domain name                                          /
> /                                                               /
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
> W.3.3 Interaction of NX RRs and Wildcard RRs
>
> As a wildcard RR causes all possible names in an interval to exist,
> there should not be an NX record that would cover any part of this
> interval.  Thus if *.X.ZONE exists you would expect an NX RR that ends
> at X.ZONE and one that starts with the last name covered by *.X.ZONE.
> However, this "last name covered" is something very ugly and long like
> \255\255\255....X.zone.  So the NX for the interval following is simply
> given the owner name *.X.zone.  This "*" type name is not expanded when
> the NX is returned as additional information in connection with a query
> for a non-existent name.
>
> If there could be any wildcard RRs in a zone and thus wildcard NXs, 
> care
> must be taken in interpreting the results of explicit NX retrievals as
> the owner name may be a wildcard expansion.
>
> The existence of one or more wildcard RRs covering a name interval 
> makes
> it possible for a malicious server to hide any more specificly named 
> RRs
>
>
> Donald E. Eastlake 3rd & Charles W. Kaufman                     [Page 
> 4]
> 
>
> INTERNET-DRAFT                          DNS Protocol Security 
> Extensions
>
>
> in the internal.  The server can just falsely return the wildcard match
> instead of the more specificly named RRs.  If there is a zone wide
> wildcard, there will be only one NX RR whose owner name and RDATA are
> both the zone name.  In this case a server could conceal the existence
> of any more specific RRs in the zone.  It would be possible to make a
> more complex NX feature, taking into account the types of RRs that did
> not exist in a name interval, and the like, which would eliminate this
> possibility.  But it would be more complex and would be so constraining
> as to make any future dynamic update feature very difficult.  See
> Section xxx.
>
> Below is the sample zone given above with NX RRs added.
>
>      FOO. IN     SOA  QQ.FOO.  admin.QQ.FOO.
>                       (   60   ; serial
>                           7200  ; refresh
>                           600  ; retry
>                           1000000  ; expire
>                           60  ; minimum
>                       )
>                  NS      QQ
>                  NS      X.BAR
>                  MX  10  A1
>                  MX  99  QQ
>                  NX      A1
>
>      A1          A       192.0.2.252
>                  A       192.245.52.250
>                  MX  10  A1
>                  MX  99  QQ
>                  NX      BAR
>
>      X.BAR       A       192.0.2.253
>                  A       192.245.52.249
>                  MX  10  X.BAR
>                  MX  80  Y.Z.BAR
>                          ; no NX, covered by *.BAR
>
>      Y.Z.BAR     A       192.245.52.248
>                  MX  10  Y.Z.BAR
>                  MX  80  Z.BAR
>                          ; no NX, covered by *.BAR
>
>      *.BAR       MX  10  Y.Z.BAR
>                  MX  80  X.BAR
>                  NX      QQ
>
>      QQ          A       192.0.2.254
>                  MX  10  QQ
>                  MX  50  A1
>
>
> Donald E. Eastlake 3rd & Charles W. Kaufman                     [Page 
> 5]
> 
>
> INTERNET-DRAFT                          DNS Protocol Security 
> Extensions
>
>
>                  NX      FOO.
>
>
>
> W.3.4 Blocking NX Pseudo-Zone Transfers
>
> In a secure zone, a resolver can query for the initial NX associated
> with the zone name.  Using the RDATA field from that RR, it can query
> for the next NX RR.  By repeating this, it can walk through all the NXs
> in the zone.  If there are no wildcards, it can use this technique to
> find all names in a zone. If it does type ANY queries, it can
> incrementally get all information in the zone and perhaps defeat
> attempts to administratively block zone transfers.
>
> If there are any wildcards, this NX walking technique will not find any
> more specific RR names in the part of the name space the wildcard
> covers.  By doing explicit retrievals for wildcard names, a resolver
> could determine what intervals are covered by wildcards but still could
> not, with these techniques, find any names inside such intervals.
>
> If it is desired to block NX walking, the recommended method is to add 
> a
> zone wide wildcard of the KEY type which asserts the nonexistence of 
> any
> keys.  This will cause there to be only one NX RR in the zone for the
> zone name and leak no information about what real names exist in the
> zone.  This protection from pseudo-zone transfers is bought at the
> expense of eliminating the data origin authentication of the non-
> existence of names that NX RRs can provide.  If an entire zone is
> covered by a wildcard, a malicious server can return an RR produced by
> matching that wildcard and can thus hide all the real data and
> delegations with more specific names in the zone.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Donald E. Eastlake 3rd & Charles W. Kaufman                     [Page 
> 6]
> 
>
> --------
>
>

---

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: Peter Koch <[email-masked]>
Date: Thu, 20 May 2004 23:59:25 +0200

Surely someone would have come up with the following "solution" sooner or
later, I just didn't know it was as soon as 10 years back :-)

> > If it is desired to block NX walking, the recommended method is to add a

Obviously a wildcard in the "registry zone" eliminates the need for any
NXDOMAIN response and thus any "link" information coming from NSEC RRs, so
that the "pointer" part may carry bogus information. Now, that's replacing the
devil with ... and I can't believe me writing this.

-Peter

---

From: Ben Laurie <[email-masked]>
Date: Thu, 20 May 2004 23:30:39 +0100

> does not mean that dnssec has something wrong with it.

It is my understanding that what NSEC2 tries to achieve is to make 
enumeration no easier than it is with plain DNS. Clearly there is no 
point in doing more than this.

Cheers,

Ben.

---

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

Jim Reid <jim <at> rfc1035.com> writes:

> And while it would be nice if DNSSEC didn't make zone traversal
> easy -- like your now dead NO record draft tried to do -- it's
> so far been too hard to find a way of doing that which works for
> all possibilities for authenticated proof of non-existence. If
> there weren't so many tricky corner cases, especially with
> wildcards, no doubt something like your NO record would have
> been incorporated into the current drafts.

What was wrong with the wildcard handling in the expired NO draft?  I
don't recall pending technical issues last time.  Anyway, solving
wildcard handling is a simple technical matter, despite its
complexities.  I haven't seen anyone seriously suggesting it is
strictly impossible to solve it.

> hardware, assuming there aren't chips that can do this already?

My point was that nobody would bother to do dictionary attacks on
SHA-1 hashes when they can do online dictionary attacks more easily.
And online dictionary attacks cannot be prevented currently.  So the
attack has been mitigated beyond other currently acceptably attack
vectors.

Regards,
Simon

---

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: Mark Andrews <[email-masked]>
Date: Fri, 21 May 2004 10:05:31 +1000

> devil with ... and I can't believe me writing this.

	Actually it doesn't "registry zones" are treated like any
	other zone for validation.

	The wildcard response still need the NOQNAME proof to be
	sent to prove that the wildcard is actually the correct
	response and not a forged the response.  The NOQNAME proof
	will also prove if it is the correct wildcard answering the
	query or not. 

	NSEC2 does not supply the information to determine if the
	correct wildcard has been presented.  This is in the owner
	and next names of the NOQNAME NSEC proof.
 
	NXDOMAIN needs two proofs to be sent NOQNAME and NOWILDCARD
	(these may be the same NSEC record).  A wildcard response
	remove the need for the NOWILDCARD proof.

	For NSEC2 to work you would also have to send additional records.

	If the qname was a.b.c.d.e.f.example the NOQNAME proof becomes.
	one of:

	f.example does not exist.
	or
	a proof that f.example exist and a proof that e.f.example does not
	exist.
	or
	a proof that e.f.example exists and a proof that d.e.f.example does
	not exist.
	or
	a proof that d.e.f.example exists and a proof that c.d.e.f.example
	does not exist.
	or
	a proof that c.d.e.f.example exist and a proof that b.d.e.f.example
	does not exist.
	or
	a.b.c.d.e.f.example does not exist and a proof that b.d.e.f.example
	exist.

	The additional proof is to prove that there is no delegation,
	empty non-terminal.  From the above you can determine the
	correct wildcard that should be matched or the correct
	NOWILDCARD proof to look for.

	NSEC2 would also require a NSEC record for every empty
	non-terminal node.  ENUM will love this:-).

	Under NSEC there is implicit information buried in the
	names.  This has to be made explicit under NSEC2.

	Note: This is *just* a technical analysis of the proposal.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Fri, 21 May 2004 12:34:35 +1000

> helped an attacker.  This still holds, for new not yet public weaknesses in

	It also demonstrates that there are security implications for
	*not* knowing all the names and attached data in advance.

	If you want to allow rlogins from a namespace you have to have
	a local copy of that namespace.  This was a case were allowing
	AXFR *fixed* part of the security issues as it allowed you to
	get the local copy.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 21 May 2004 10:33:02 +0200

> 	and next names of the NOQNAME NSEC proof.

No, I believe sufficient information is present.  To verify that any
wildcard RR doesn't cover the queried name, you compute a few SHA-1
hashes on the only possible wildcard owner names that can be relevant,
and compare with the additional NO records returned.  This logic was
described in the NO draft.

Regards,
Simon

---

From: Jim Reid <[email-masked]>
Date: Fri, 21 May 2004 09:54:37 +0100

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

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

I don't believe anyone here is claiming they are wrong or that their
concerns about EU directives are invalid. As you say only a clueful
lawyer can make that determination. I do think it's wrong however to
attempt to solve layer 9 problems by redesigning a protocol.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 21 May 2004 10:27:25 +0100

> point in doing more than this.

Actually, I'll take that back, there may be a point in doing more, but 
there's certainly an argument that suggests that its reasonable to 
expect not to be in a worse position by virtue of switching from DNS to 
DNSSEC.

Cheers,

Ben.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 21 May 2004 16:13:40 +0200

[email-masked] writes:

> 	thats a bit presumptious, don't you think?  how can you 
> 	possibly determine relevant, possible owner names?

I may have misunderstood something.  Here is how I perceive things.

Consider any query for a non-existing name a.b.c.d.e.f.com in the zone
f.com.  To prove that a.b.c.d.e.f.com doesn't exist, the server has to
return records proving that the following names do not exist:

a.b.c.d.e.f.com
*.b.c.d.e.f.com
*.c.d.e.f.com
*.d.e.f.com
*.e.f.com
*.f.com

This is the same for NXT, NSEC and presumably all alternatives as
well.

With NXT/NSEC, the verifier can read the "next owner name" field of
the RRs, and make sure all above names are included in the range of
some of the returned RRs.

Since alternative solution doesn't have a "next owner name" field,
this technique doesn't work.  But the above set of possibly relevant
owner names is always a small number, so the verifier can compute the
hash of each of the above strings and verify that all are included in
the range of all NO RRs returned.

The only difference in processing is that during each wildcard
iteration, you compare the hash of the name instead of the name, with
what is stored in the returned RRs.

The second complication due to wildcard names is that when the
response exists and is a wildcard name, you must also prove that no
more specific owner name exists.  The logic is a bit different, but I
believe there is no problem implementing it with hashed names.

Were you thinking of some other problem?  Or is my reasoning flawed?

Regards,
Simon

---

From: Greg Hudson <[email-masked]>
Date: Fri, 21 May 2004 10:24:43 -0400

> attempt to solve layer 9 problems by redesigning a protocol.

So, I don't support modifying NSEC, but this attitude that legal
requirements should never have any impact whatsoever on an IETF protocol
is weird.  You can't "solve" all layer 9 problems at the layer 9 level.

IETF protocols exist to meet people's needs.  People have needs for a
variety of reasons, including the presence of legal requirements.  We
certainly have the right to say "we think this need is bogus, or too
hard to meet, so we're going to punt on it," but to categorically
declare the need out of scope because it's "not technical" is sophistry.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 21 May 2004 14:33:53 +0000

> there's certainly an argument that suggests that its reasonable to expect
> not to be in a worse position by virtue of switching from DNS to DNSSEC.

So, "What Once Were Vices Are Now Habits" hits it fairly close, I guess.

I hereby renew my call that someone write a BCP describing the BINDism of
rejecting AXFR based on source address or lack-of-TSIG so that this can be
called a DNS protocol feature so that DNSSEC can be called incomplete
without it.

---

From: Peter Koch <[email-masked]>
Date: Fri, 21 May 2004 17:32:13 +0200

> just means I need to send you 10,000 requests per second.  That's

you're right that expensive responses ease DoS, but the potential is there
already. Even without malicious intent one would want to evaluate the
current NXDOMAIN/referral ratio to estimate the resources needed under
"normal" operations. Shouldn't be as bad as for the root servers.
For reaction to DoS it was already suggested to start dropping answers
if the number of NXDOMAIN responses grow over a certain threshold.

> The problem is that it's just too prone to DoS attacks....  Which is BAD.

I'm not saying it's easy.

-Peter

---

From: Alex Bligh <[email-masked]>
Date: Fri, 21 May 2004 16:57:26 +0100

Paul,

> So, "What Once Were Vices Are Now Habits" hits it fairly close, I guess.

I think the issue is that RFC1034 did not mandate, but equally did not
prohibit making zonefiles not enumerable (whether or not that prohibition
is BCP), whereas current DNSSEC does (effectively) prohibit it as NSEC
(which allows the behavior) is mandatory.

>From RFC1034:

	The secondary server must request a zone transfer via an AXFR
	request for the zone.  ** The AXFR may cause an error, such as
	refused **, but normally is answered by a sequence of response
	messages.

Alex

---

From: Mark Andrews <[email-masked]>
Date: Sat, 22 May 2004 09:11:31 +1000

> This is the same for NXT, NSEC and presumably all alternatives as

	You obviously don't understand the "closest encloser"
	restrictions.  ONLY ONE AND EXACTLY ONE of those wildcards
	is relevent.

	You need to know what names exist to determine which wildcard
	to use.  NSEC provides this information in the owner and next
	names (yes both of these are required not just the next name).

	For NO/NSEC2 the information required to determine this has
	to be explicitly provided.

	The actual set of proofs reqired are

		!f.com + !*.com 
	or
		!e.f.com + !*.f.com + %f.com
	or
		!d.e.f.com + !*.e.f.com + %e.f.com
	or
		!c.d.e.f.com + !*.d.e.f.com + %d.e.f.com
	or
		!b.c.d.e.f.com + !*.c.d.e.f.com + %c.d.e.f.com
	or
		!a.b.c.d.e.f.com + !*.b.c.d.e.f.com + %b.c.d.e.f.com

	! == not exist
	% == exist

	I don't believe NO had this as general DNSSEC did not have this
	specified at the time.
	
	Mark

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 22 May 2004 01:55:06 +0200

> 		!a.b.c.d.e.f.com + !*.b.c.d.e.f.com + %b.c.d.e.f.com

And how is it impossible for NO/NSEC2 to support this?  How I see it
is that the verifier would compute a hash of all the following
strings:

 a.b.c.d.e.f.com
 *.b.c.d.e.f.com
 *.c.d.e.f.com
 *.d.e.f.com
 *.e.f.com
 *.f.com

The hashes for the positive proofs are also needed, i.e.:

f.com
e.f.com
d.e.f.com
c.d.e.f.com
b.c.d.e.f.com

Using those hash values, together with the returned records, the
client can discover which of your clauses hold (if any).  For example,
let's say we have the following (abbreviated hash values to simplify
reading, imagine they are full length SHA-1 hashes):

H(a.b.c.d.e.f.com) =  181
H(*.b.c.d.e.f.com) =  38383
H(*.c.d.e.f.com)   =  3292
H(*.d.e.f.com)     =  4959
H(*.e.f.com)       =  606
H(*.f.com)         =  1194

H(f.com)           =  5271
H(e.f.com)         =  14
H(d.e.f.com)       =  596
H(c.d.e.f.com)     =  94984
H(b.c.d.e.f.com)   =  903

Now let's assume the query is a.b.c.d.e.f.com and the returned NO
records are:

$ORIGIN _no.f.com
150 IN NO A 200  ;; the main proof that a.b.c.d.e.f.com (181) does not exist
;; Additional proofs:
550 IN NO A 650  ;; proves d.e.f.com (596) does not exist
550 IN NO A 650  ;; proves *.e.f.com (606) does not exist  (by chance, same record)
14  IN NO A 50   ;; proves e.f.com (14) exists

The verifier is able to discover that one out of all relevant wildcard
situations apply, in this case the third of your clause.  To do this
it simply iterates over all possible candidates (a small number).  The
client can now trust that a specific a.b.c.d.e.f.com do not exist, and
that e.f.com do exists but there is no d.e.f.com nor *.e.f.com.  So it
is able to authenticate denial of existence for ab.c.d.e.f.com.

If I'm going to understand why NO/NSEC2 doesn't work, please give more
details.

Thanks,
Simon

---

From: Paul Vixie <[email-masked]>
Date: Sat, 22 May 2004 06:38:39 +0000

> it simply iterates over all possible candidates (a small number). ...

it is not reasonable to ask a verifier to iterate in this additional way.

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 22 May 2004 09:30:46 +0200

> it is not reasonable to ask a verifier to iterate in this additional way.

Why not?

Are you worried about CPU efficiency?  The most computationally
expensive operation of the iteration is likely the hashing.  I don't
see anything else in the verification process that would take time;
the iteration over possible relevant names is over a small number,
typically <<100, and each loop compute a hash and can directly compare
the hash against the received NO/NSEC2 records.  You could cache some
of the hash computations to improve performance, but given the below I
doubt you would need that for performance reasons alone.

My box does ~1.000.000 SHA1 ops/second, compared to ~1.000 RSA 512 bit
verify ops/second, and ~200 RSA 1024 bit verify ops/second.

So it doesn't appear as CPU efficiency would be a valid concern.

Code complexity?  The logic is straight forward.  You can modularize
the NO/NSEC2 wildcard verify logic into a separate module.  It is just
a Small Matter Of Programming.  Compared to other warts in NXT/NSEC,
it doesn't have any consequences on the basic DNS model.  Take the
zone cut issue with NXT/NSEC, where you have two records with the same
name/type/class, but must not confuse the two as one comes from the
parent zone and one from the child zone.  Catering for this wart may
require changes to the backend of a DNS cache.  Recall that NO (and
likely also NSEC2, but I haven't read it) fixes the zone cut issue.

Regards,
Simon

---

From: Paul Vixie <[email-masked]>
Date: Sat, 22 May 2004 15:13:25 +0000

> > it is not reasonable to ask a verifier to iterate in this additional way.

because it's already iterating in several other ways, and this is basically
a new innermost-loop, and the span of the iteration can be controlled by an
attacker.

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 23 May 2004 02:06:52 +0200

> a new innermost-loop, and the span of the iteration can be controlled by an

The maximum iteration count needed can be computed from the domain
name used in the query (e.g., a.b.c.d.e.f.com), so the attacker cannot
influence the iteration count by returning special data.

An attacker may cause clients to look up a name chosen by the
attacker, perhaps as the worst case a.b.c.d.e.f.g.h.....z.com or
similar.  But the attacker is limited by the limits in the DNS
protocol -- owner names cannot be longer than 255 octets.  So the
attacker can cause the client to compute a few hundred SHA-1 hashes,
in the worst case.

A few hundred SHA-1 hashes is fast compared to a 2048 bit RSA verify.
And making a client perform a 2048 bit RSA verify is possible today,
just send it an bogus KEY/SIG pair.

Regards,
Simon

---

From: Jim Reid <[email-masked]>
Date: Sun, 23 May 2004 10:27:02 +0100

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> Take the zone cut
    Simon> issue with NXT/NSEC, where you have two records with the
    Simon> same name/type/class, but must not confuse the two as one
    Simon> comes from the parent zone and one from the child zone.
    Simon> Catering for this wart may require changes to the backend
    Simon> of a DNS cache.  Recall that NO (and likely also NSEC2, but
    Simon> I haven't read it) fixes the zone cut issue.

To "fix the zone cut issue", a delegation's NS and any glue records
would need to be in exactly one place: the child or parent, probably
the parent. AFAIK, the NO and NSEC2 drafts don't suggest that.

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 23 May 2004 21:54:27 +0200

> the parent. AFAIK, the NO and NSEC2 drafts don't suggest that.

Right.  I meant the additional zone cut issue introduced by DNSSEC.
To fix the issue completely would require more drastic measures, but
I'm not sure anyone has been suggesting this.

Regards,
Simon

---

From: Ben Laurie <[email-masked]>
Date: Mon, 24 May 2004 16:19:06 +0100

> If I'm going to understand why NO/NSEC2 doesn't work, please give more

NSEC2 does work (at least in this respect), but NO didn't. The 
difference is the EXISTS record, and the problem it solves is that 
(despite terminology) the closest encloser may not actually exist (that 
is, there may not be an RR with that exact name, just one with a longer 
name - or, to put it another way, the closest encloser can be an empty 
non-terminal).

We could demonstrate this, I guess, with hashes rather than EXISTS 
records by not _actually_ having an EXISTS record, just claiming it in 
the RR types field of NSEC2 - or even claiming no RR types at all. 
However, whilst this might be neater, it does nothing to hide the 
closest encloser (clearly, since a resolver needs to know exactly what 
it is), so its just another way of expressing the same thing. It also 
makes the logic for NSEC2 rather different from NSEC and, since it seems 
clear that the future is not likely to replace NSEC with NSEC2, but 
rather to offer them as alternatives, this would seem (to me) to be an 
unnecessary burden on implementers.

I suppose it is also worth saying that it wouldn't reduce the size of 
the zone, either, since you'd be swapping an EXISTS record for an NSEC2 
record.

Cheers,

Ben.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 24 May 2004 19:15:21 +0200

Ben Laurie <[email-masked]> writes:

>> The verifier is able to discover that one out of all relevant
>> wildcard situations apply, in this case the third of your clause.
>> To do this it simply iterates over all possible candidates (a small
>> number).  The client can now trust that a specific a.b.c.d.e.f.com
>> do not exist, and that e.f.com do exists but there is no d.e.f.com
>> nor *.e.f.com.  So it is able to authenticate denial of existence
>> for ab.c.d.e.f.com.  If I'm going to understand why NO/NSEC2
>> doesn't work, please give more details.
>
> (despite terminology) the closest encloser may not actually exist
> (that is, there may not be an RR with that exact name, just one with a
> longer name - or, to put it another way, the closest encloser can be
> an empty non-terminal).

I'm sorry to be dense, but I don't follow how NO didn't work.  What
was wrong in the algorithm verifiers can follow to prove non-existence
using NO records in my previous message?

Don't get me wrong, I'm not trying to push a NO solution (all I have
proposed is to drop one sentence in the security considerations of the
current specifications), but since we're discussing it, I'd might as
well try to learn something.

Thanks,
Simon

---

From: [email-masked]
Date: Fri, 21 May 2004 12:23:33 +0000

> Simon

--bill

---

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: Paul Vixie <[email-masked]>
Date: Mon, 24 May 2004 17:52:29 +0000

> I'm sorry to be dense, but I don't follow how NO didn't work.  ...
> Don't get me wrong, I'm not trying to push a NO solution ...

and yet, you must.  perhaps that's the component i'm seeing that others
here are not.  if we're going to reopen the dnssec design, then we have
to re-evaluate NO, opt-in, as well as NSEC2, and anything else lurking
in the shadows.  anything we don't evaluate fully enough, will clearly
just become an 11th hour showstopped 18 months from now when we next feel
ready to start deployment.  therefore, if this WG decides to adopt NSEC2,
we have to broaden the net to include competing proposals, some of whom
were shot down just because of the lateness of the hour rather than for
functional reasons.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 24 May 2004 21:00:58 +0200

> were shot down just because of the lateness of the hour rather than for

I agree with all that.  I don't mind of others wants to reconsider the
NO proposal, and time permitting I can try to assist.  But my only
goal now has been to improve the current specifications, so they can
be shipped (if that is the consensus), by dropping a misleading
statement in the security consideration.  Those two matters are
orthogonal, and quite different in proportions.  I haven't asked for a
redesign, and I'm indifferent to whether one is needed.

Regards,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 24 May 2004 23:42:15 +0200

Ben Laurie <[email-masked]> writes:

> The problem is that if (say), in your example, e.f.com only exists by
> virtue of an RR for x.e.f.com, then there will be no NO record for
> e.f.com. This is why I had to invent the EXISTS record.

Ah, I see.  Thanks for explaining!  Edward Lewis' suggestion to (in
this example) populate the otherwise empty node e.f.com with a NSEC2
RR sounds like something that might be simpler.

Thanks,
Simon

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 25 May 2004 10:06:04 -0700

> 0. It is real frustrating when a bunch of late new comers 
> suddenly say they
> 	can not deploy DNSSEC for some reason that has nothing
> 	to do with DNS, just some obsolete whois stuff and some 
> legal mumbo
> 	jumbo that only applies to about 25 countries.

Hold it right there. This issue has been raised repeatedly, but I
have yet to hear a substantive answer. All I have seen or heard is
pointers to claims that it has been answered before.

This is a classic agenda denial tactic. Don't address the substance
of the argument, attack the standing of the person making it.

The reason that this process is taking so long is that instead of
facing the real challenges for deployment these are mau-maued off
the table, then when they inevitably return the process is repeated.

It would hardly be surprising if people had been slow comming forward
with issues. The treatment they have received in this group has
hardly been wellcoming. I get hissed by the then AD and future chair
the first time I try to say a word in a DNSEXT meeting. The mode of
argument is always 'your experience, knowledge and business interests
are irrelevant to this group', followed by 'my understanding of 
the complexities of DNS means that my statements cannot be disputed'.

The fact is however that every issue that has come out at the "last 
minute" has been raised repeatedly and ignored. Now we are told that
the only options are between doing it according to the current specs
and abandoning DNSSEC entirely. This is a false choice, we do not
need to delay or abandon the DNSSEC specs, we do not need to define a
new NSEC record. All we need to do is to make NSEC optional.

Making NSEC optional reduces but does not eliminate the security
benefit of DNSSEC. Since we are talking about an infrastructure that
is currently insecure and will take many years to deploy a security
infrastructure for there it makes no sense to make NSEC a show stopper.

IF DNSSEC is deployed you will discover FAR more problems than just
NSEC.

I don't think that at the time proving non-existence of domains was
accepted as a showstopper 9 years ago that the implications for 
the present day Internet could have been understood. Over that time
the number of users has gone from a few million college students to 
a billion.

There has also been a radical change in the understanding of the 
security problem over that time. When I started doing Web security 
in 1992 the security field was still centered on the problem of
securing multiple user access to a single, non networked computer.
The role cryptography might play in a network environment was
poorly understood.

Since then there has been a radical reassesment of the appropriate 
application of cryptography in the field. Much of this is the 
result of extensive and painful experience trying to deploy
cryptographic systems.

From a pure security perspective NSEC buys you very little of value.
This is because DNS is not just a protocol, it is a component in
a system. In a system there is no useful distinction between
a subsystem that replies 'It does not exist' and one that says 
'I cannot find it'.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 25 May 2004 10:52:41 -0700

>a subsystem that replies 'It does not exist' and one that says

I strongly disagree with this.  From an application designer's perspective,
getting back a *trustable* "this does not exist" is very different from getting
"I cannot find it".  You may be thinking in terms of human driven activities
like browsing, in which there is a human to apply heuristics to an error
code; in some of those the human tends to apply the same guesses
to what to do next in response to both.  But this is not the only class
of applications, and for many of the discovery elements of those,
I believe reliable data for non-existence is required.

Speaking personally,
			regards,
				Ted Hardie

---

From: Edward Lewis <[email-masked]>
Date: Tue, 25 May 2004 13:50:00 -0700

>pointers to claims that it has been answered before.

First a plea for civility.

I've yet to see any response (on-line, I did get one verbal response) 
to my NSEC2 examples.  In my mind they listed the issues I perceive - 
"in my mind."  If what I have written is unclear or misinformed as 
far as premise, I'd appreciate comments on the examples.

The messages are:

   http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00608.html
and
   http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00610.html

(To keep threading clean, if you have comments on the messages, reply 
to those, not this message.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

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

---

From: Roy Badami <[email-masked]>
Date: Tue, 25 May 2004 23:00:42 +0100

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

    Edward> I've yet to see any response (on-line, I did get one
    Edward> verbal response) to my NSEC2 examples.  In my mind they
    Edward> listed the issues I perceive - "in my mind."  If what I
    Edward> have written is unclear or misinformed as far as premise,
    Edward> I'd appreciate comments on the examples.

Of course, the Nominet zones (at least) have no wild cards, and this
is true of most TLDs.  And the immediate example that springs to mind
of a TLD that currently uses wildcards is .museum, which uses the
wildcards to take a browser to an index page listing names in the
museum gTLD -- so they presumably would have no concerns about
enumeration.

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

I'm sure someone elsewhere in this thread implied in passing the idea
that zones might be given a choice of mechanisms for authenticated
denial: one with the properties of NXT/NSEC, or an alternative that
lacked the perceived enumeration problem but constrained the zone to
contain no wildcards.

However I think I concur with something that I think someone else in
this thread (sorry, I forget who) had in mind a while back: _if_ any
changes are going to be made to the spec at this stage, the one change
that should seriously be contemplated is introducing a mechanism
allowing a zone to declare (on a per-zone basis) what authenticated
denial mechanism they use.

I'm inclined to believe that authenticated denial should remain a
mandatory feature for secure zones, but a flag indicating what
mechanism the zone uses would make any future introduction of an
alternative to NSEC much more painless.

If an alternative authenticated denial proposal gains support
subsequent to DNSSEC deployment, then such a flag would allow
resolvers not supporting the new mechanism to (correctly) return an
unauthenticated NXDOMAIN response (or a null answer in the case of an
empty non-terminal) rather than returning SERVFAIL.

	-roy

---

From: Andrew Newton <[email-masked]>
Date: Tue, 25 May 2004 19:09:28 -0400

> alternative to NSEC much more painless.

If possible, this pick-your-poison approach sounds good to me.

-andy

---

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: Paul Vixie <[email-masked]>
Date: Wed, 26 May 2004 05:13:00 +0000

>     Roy> operators, and perhaps others, too.

last time this was proposed, i wondered whether use of such signalling
on a zone that actually did have a wildcard would be "invalid," and who
would be hurt by it if a zone was published that "invalid" way, and
whether validators, if among those hurt, could even detect the condition.

in other words, would we be providing a way to turn on both the heat and
air conditioning at the same time, or is there an interlock preventing this?
and if there's no interlock, who pays the cost of all the wasted energy,
or does the house just blow up, and are my children in it at the time?

---

From: [email-masked]
Date: Wed, 26 May 2004 09:03:09 +0200

> concerns that have motivated this NSEC2 draft. Where's this "vast

One ccTLD operator I've talked to has said that their views are pretty
well covered by what Nominet people on this list have expressed so far.
I agree that it would be good to have explicit reactions from the TLD
operators.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: [email-masked]
Date: Wed, 26 May 2004 10:25:54 +0200 (CEST)

> denial mechanism they use.

You can't declare anything 'by zone'. A resolver is _completely_clueless_
about zone concept. A zone in merely space delegate to an entity minus
subspace delegated by that entity.

If, big if, anything can be declared by zone (similar like SOA), how would
you proof that record exist ? or not exist ?

Roy

---

From: Alex Bligh <[email-masked]>
Date: Wed, 26 May 2004 09:48:53 +0100

> I agree that it would be good to have explicit reactions from the TLD

In terms of European (by which I really mean RIPE area) ccTLDs, you
are probably best asking this at some CENTR event. I am not sure a
large number of ccTLD people are on this list, and even to the extent
they are, they are probably technical people rather than technical plus
policy people.

Alex

---

From: Roy Badami <[email-masked]>
Date: Wed, 26 May 2004 11:19:38 +0100

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

    roy> You can't declare anything 'by zone'. A resolver is
    roy> _completely_clueless_ about zone concept.

We may be talking at cross purposes, but surely DNSSEC declares keys
on a per-zone basis, with DNSKEY records stored at the zone apex?  How
would this be different?

      -roy

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Wed, 26 May 2004 11:48:10 +0200

> they are, they are probably technical people rather than technical plus

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

Regards,
Marcos

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Wed, 26 May 2004 11:18:15 +0200

Roy,

> well satisfy the concerns of the vast majority of TLD operators, and

Dispatching wildcards from NSEC2 would not be an option.

The DE-zone has entries of the form

*.abc.de   some stuff

Ed's analysis (which I've collated and regard as sound) applies for these 
cases, too. However, the linear growth of server work and answer size in 
hands of the client doesn't seem that dangerous to me.

Regards,
Marcos

---

From: Peter Koch <[email-masked]>
Date: Wed, 26 May 2004 12:36:14 +0200

> The DE-zone has entries of the form

a workaround would be to simply move those into separate zones  - even without
necessarily having to change your registration policy.  That would cause
some, maybe even some more, overhead on the side of server maintenance,
but if getting rid of wildcards eases a solution it's worth exploring this path.

-Peter

---

From: [email-masked]
Date: Wed, 26 May 2004 12:27:26 +0200 (CEST)

> on a per-zone basis, with DNSKEY records stored at the zone apex?  How

I can deploy a test.dnss.ec zone where silly.test.dnss.ec is signed by the
dnss.ec DNSKEY.

Roy

---

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: Roy Badami <[email-masked]>
Date: Wed, 26 May 2004 11:48:51 +0100

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

    roy> I can deploy a test.dnss.ec zone where silly.test.dnss.ec is
    roy> signed by the dnss.ec DNSKEY.

You can?  

-proto 2.1 requires a delegated secure zone to contain a DNSKEY record
at the apex.  And 2.2 requires RRsets to be signed with at least one
RRSIG where the Signer's Name equals the name of the zone containing
the RRset. -records 3.1.7 requires the Signer's Name in an RRSIG to
match the name of the zone containing the RRset.

      -roy

---

From: [email-masked]
Date: Wed, 26 May 2004 13:35:11 +0200 (CEST)

>     roy> signed by the dnss.ec DNSKEY.

Yes, you can.

> match the name of the zone containing the RRset.

I know, I've heard of those docs. The problem is that a validator has no
way to check that.

Roy

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Wed, 26 May 2004 13:08:13 +0200

Jim,

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

Regards,
Marcos

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Wed, 26 May 2004 13:14:35 +0200

> That would cause

Agreed.

Regards,
Marcos

---

From: Roy Badami <[email-masked]>
Date: Wed, 26 May 2004 13:00:21 +0100

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

    roy> If, big if, anything can be declared by zone (similar like
    roy> SOA), how would you proof that record exist ? or not exist ?

Place a new RR at the zone apex, that specifies the authenticated
denial algorithm(s) used by the zone. You can validate it by its
RRSIG.  Make the RR mandatory for all zones that use something else
instead of (or in addition to) NSEC.  By definition, therefore, the
only secure zones that lack this RR will be able to deny its existence
using NSEC.

Require that any zone that doesn't support NSEC MUST return this new
RR as part of its authenticated denial proof.

   -roy

---

From: [email-masked]
Date: Wed, 26 May 2004 14:02:52 +0200 (CEST)

Lets stop this sillyness, and get back to Authenticated Denial Flags.

The point is, something about authenticated denial mechanism needs to be
signalled. It cannot be done by a record per_zone, since that would
introduce a circular probem. (The NSECINFO in the NSEC2 draft has this
problem).

Another way to go is to subtype this into the NSEC2 record. A version
field. Where and 8 bit version field holds either:

0 ffu
1 clear label (plain old DNSSEC)
2 reserved (later:hashed labels)
3 reserved (later:hashed ownernames)
4 reserved (later:opt-in)

etc.

And we simply document version 0, clear label. With the restriction that
version !1 MUST be discarded as being proof if version is not implemented
(AND signature verifies) and all NSEC records in a zone have the same
version.

Ofcourse future versions are not backwards compatible, so the
need-to-denial-check-aggression-cost of not compatible resolvers is placed
at those who deploy future versions.

How does that sound ?

Roy

---

From: [email-masked]
Date: Wed, 26 May 2004 13:36:36 +0200

> .de zone, guzzling bandwidth and needlessly loading the TLD's name

But it's okay to let random users enumerate the zone by following
NSEC RRs?

---

From: Jim Reid <[email-masked]>
Date: Wed, 26 May 2004 12:46:18 +0100

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

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

    sthaug> But it's okay to let random users enumerate the zone by
    sthaug> following NSEC RRs?

IMO, yes. UDP traffic to an already active socket has to be better for
the name server and underlying OS than carrying the same traffic over
freshly-created TCP connections, all other things being equal. Not
that I care about enumeration anyway, however it's done.

---

From: Roy Badami <[email-masked]>
Date: Wed, 26 May 2004 14:24:46 +0100

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

    roy> Lets stop this sillyness, and get back to Authenticated
    roy> Denial Flags.  The point is, something about authenticated
    roy> denial mechanism needs to be signalled. It cannot be done by
    roy> a record per_zone, since that would introduce a circular
    roy> probem. (The NSECINFO in the NSEC2 draft has this problem).

Hmmm, I think I've just spotted a bigger problem with any
authenticated denial flag.

If a zone (.org.uk, say) decides not to use NSEC, then (obviously) old
resolvers that don't understand the authenticated denial mechanism
chosen by .org.uk won't be able to verify non-existence proofs
presented for .org.uk, and will have to treat them much as NXDOMAIN
responses from insecure zones.  I'd been assuming that this isn't
necessarily a Very Bad Thing.

Unfortunately,  with   DS,  provably  insecure   delegations  rely  on
authenticated denial to prove the non-existence of a DS record.

So in this scenario, assuming that gnomon.org.uk is a secure zone,
someone could spoof data in my zone by spoofing an insecure delegation
from .org.uk and old resolvers would be unaware that anything untoward
had happened.

    -roy

---

From: [email-masked]
Date: Wed, 26 May 2004 21:36:39 +0200 (CEST)

> from .org.uk and old resolvers would be unaware that anything untoward

Yes. So it would fall back to vanilla DNS. That is what org.uk is now.

In fact, there is nothing lost.

Lets say example.com is required to use NSEC2 by their
constituency/lawyer/etc.

2 scenarios:

1) DNSSEC deployment is heldup until NSEC2 is done. "example.com" can
   deploy DNSSEC in 24-36 months. until then, vanilla DNS only for world.

or

2) DNSSEC deployment continues. NSEC2 development continues. "example.com"
   can deploy DNSSEC in 24-36 months, while world can adopt DNSSEC with
   NSEC in (say) 6 months.

My pick would be scenario number 2.

Note: this only works with a version field in NSEC. We simply state V1 is
NSEC as we know it. !V1 must then be interpreted as plain DNS (verify the
NSEC SIG, so the resolver knows the NSEC is legit, treat the delegation or
denial as unsecured).

Roy

---

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

> 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: Roy Badami <[email-masked]>
Date: Wed, 26 May 2004 23:30:56 +0100

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

    roy> 2) DNSSEC deployment continues. NSEC2 development
    roy> continues. "example.com" can deploy DNSSEC in 24-36 months,
    roy> while world can adopt DNSSEC with NSEC in (say) 6 months.

The problem is that a signed (NSEC2) zone can have a secure delegation
to another zone (NSEC1 or NSEC2).  People will naturally expect that
delegated zone to be safe; they need to be made aware that the subzone
is not secure as far as NSEC1 resolvers go, unless it is configured as
a trust anchor.

Note that this problem is new to DS; in RFC2535 provably insecure
delegations did not depend on authenticated denial.

Maybe this is an acceptable state of affairs, but it makes me nervous.

      -=roy

---

From: Roy Badami <[email-masked]>
Date: Thu, 27 May 2004 01:15:44 +0100

To be more specific, here is what I'm talking about.

Alice is an authoritive nameserver for tld.  She uses NSEC2.

Bob in an authoritive nameserver for sld.tld delegated from tld by
means of a DS record.  (It doesn't matter whether he uses NSEC1 or
NSEC2.)

Charlie is a security-aware resolver.  However, he only understands NSEC1.

Charlie has a secure entry point into tld (either as a trust anchor,
or delegated from a signed root).  He does not have sld.tld configured
as a trust anchor, but uses the DS record as his secure entry point.

Mallory wishes to tamper with the contents of sld.tld, as seen by
Charlie.  He therefore tampers with the DNS response from Alice
refering Charlie to Bob.  In particular, he removes the DS record, and
inserts a randomly chosen NSEC2 record from tld, together with its
RRSIG.

Charlie sees the lack of a DS record as indicating an insecure
delegation.  He can see an NSEC2 record, and he can verify that it is
signed by tld's ZSK, but he can't tell whether it proves the lack of a
DS record.  He simply has to assume that sld.tld is insecure.  At his
point Mallory can tamper with responses from Bob to Charlie with
impunity.

One fix would be to introduce a null DS record, which is semantically
identical to having no DS record, and to require NSEC2 zones to
include null DS recods for all insecure delegations.

An NSEC1 resolver then can always verify a claim of an insecure
delegation: either there will be an NSEC1 record proving the lack of
DS record, or there will be a null DS record.

   -roy

---

From: David Blacka <[email-masked]>
Date: Wed, 26 May 2004 21:00:56 -0400

> Charlie is a security-aware resolver.  However, he only understands 

Then, to Charlie, tld is, for all intents and purposes, not secure.

You can repeat this exercise with algorithms instead of different NSEC 
types: tld is signed by algorithm A, sld.tld is signed with B, Charlie 
only understands B...

Except with NSEC2, it is possible that Charlie will be able to 
establish a chain of trust to sld.tld, if no one tampers with anything.

Versioning DNSSEC, by its very nature, will fragment DNSSEC islands of 
security.

That is not much of an issue if the fragmentation happens towards the 
leaf nodes, but, at the TLD level, it will force all clients to 
understand all of the versions in order to be useful.

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

---

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

>>>>> "David" == David Blacka <[email-masked]> writes:

    David> Then, to Charlie, tld is, for all intents and purposes, not
    David> secure.

Not quite.  All records in tld can be verified by Charlie, so tld is
secure for some purposes.  Obviously, authenticated denial is not
available for RRsets in tld.  But less obviously, all delegations from
tld are insecure.  This last point is fixable.

    David> You can repeat this exercise with algorithms instead of
    David> different NSEC types: tld is signed by algorithm A, sld.tld
    David> is signed with B, Charlie only understands B...

    David> Except with NSEC2, it is possible that Charlie will be able
    David> to establish a chain of trust to sld.tld, if no one tampers
    David> with anything.

If the purpose of versioning is to allow later deployment of NSEC2,
then it would be good to consider the implications of such a
deployment strategy, and to consider fixing things that are fixable.

As a domain holder in a ccTLD that will probably choose to deploy
NSEC2 rather than NSEC, I don't much like the prospect that my
delegation will not be secure for the installed base of DNSSEC
resolvers.  If that's the case, the cost of NSEC2 is too high...

    -roy

---

From: Edward Lewis <[email-masked]>
Date: Wed, 26 May 2004 22:48:10 -0400

When I think on this topic there are a few assumptions I make.

One is that record synthesis (aka wild cards) is an integral part of 
the protocol.  It doesn't matter to me if a proposed solution has a 
problem domain that doesn't use record synthesis, the proposed 
solution must be compatible with the synthesis process.

Two is that the DNS is a very constrained lookup service.  Queries 
consist of three factors and three factors only as far as the data 
space is concerned.  Flags can be used to turn on/request processing 
at the server, but the answers returned with special processing must 
be coherent at any DNS moment.

Three is that the DNS is simple, a non-negotiated protocol.  The 
client can't indicate that it understands certain processing schemes 
and the server can't tailor an answer to the querier's dialect.

Because of these assumptions, when I see proposals that say "well, we 
don't want to use wild cards" I react negatively.  Abstractly, this 
is like defining "A and !B" operations and "!A and B" operations. 
What happens when someone in the future tries to do "A and B" 
operations?  Either we have to apply a lot of epoxy to define what 
happens when the erroneous "A and B" operations occur or we will have 
to be willing to see divergent implementations.  I.e., corner cases 
will ensue.

In the past I have tried to add a security options record to a zone, 
this proposal came out in summer 1999, just before the IETF in Oslo 
(to help fix the era in the memory of folks).  One of the pitfalls of 
this is that the record becomes one more issue for inclusion in the 
non-answer section of a reply.  I am off-line now so I can't find the 
dns-security archives, but I recall a message from John Gilmore 
rejecting the proposal "with prejudice" for another reason.  (I 
recall because I had to ask him what that meant.)

Here's the problem with having multiple approaches to negative 
answers, especially if they are not introduced simultaneously. 
NSEC-era resolvers will panic when seeing NSEC2 records - they will 
have no chance understanding the semantics.  For example, let's say 
"com." uses NSEC2 and not NSEC.  At all delegations to non-secured 
zones, a NSEC2 record will be used to prove the absence of a DS 
record.  The proper response by a NSEC-era verifier to the lack of 
either a DS set or a NSEC demonstrating no DS set is an error, 
resulting in a service failure (SERVFAIL).  It doesn't matter if we 
play a trick with key algorithms.  The older NSEC-era resolvers will 
panic, unless we retool the error handling for that state.

If we were able to include both NSEC and NSEC2 as workable solutions 
in one step, I think that would also be unwise.  DNS isn't about 
choices, it's supposed to be a lightweight system.  (Look at the 
relatively slow adoption of IPsec - too many knobs to turn and align 
right.)  DNS isn't supposed to be a feature-rich service.  (Remember 
the lessons from the A6 deprecation.)  I'd rather see just one 
defined and the other forgotten.

The WG has a technically sound set of documents pending promotion. 
The WG has also heard some concerns about new requirements that the 
current document set does not meet.  The dilemma is that the WG 
represents the collective wisdom of DNS oriented engineers and that 
the new requirements are still seemingly incompletely defined in the 
WG's realm of expertise.  (Meaning that TLD's in different legal 
jurisdictions have different requirement sets.)

A solution to the question "how do we proceed" is for the WG to 
deliver the documents to the IETF and IESG.  The broader community of 
the IETF, with guidance and expertise contacted by the IESG, will 
then have in their hands a sound approach to securing DNS within a 
given set of assumptions and requirements made by the WG.  With a 
broader base of review, the perceived new requirements can be 
evaluated and judged and a determination can then be made the WG's 
documented solution is good enough or that the WG must go back to the 
chalk board and update the design.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 27 May 2004 04:01:13 +0000

> From: Edward Lewis <[email-masked]>
> ...
> In the past I have tried to add a security options record to a zone, this
> proposal came out in summer 1999, just before the IETF in Oslo (to help fix
> the era in the memory of folks).  One of the pitfalls of this is that the
> record becomes one more issue for inclusion in the non-answer section of a
> reply.  I am off-line now so I can't find the dns-security archives, but I
> recall a message from John Gilmore rejecting the proposal "with prejudice"
> for another reason.  (I recall because I had to ask him what that meant.)

see attached.

Subject: Re: (Almost final) Agenda for dnsind/dnssec in Oslo
From: John Gilmore <[email-masked]>
To: Paul A Vixie <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: Mon, 28 Jun 1999 01:49:48 -0700

> > 11. SECure-RR			(5 minutes)		Edward Lewis
> > 	<draft-ietf-dnsind-sec-rr-00.txt>
> i very much hope that john gilmore will be at the oslo meeting to defend his
> point of view (that we can't deploy a new RR at this time if we're expecting
> to use dnssec widely this year.)

I won't be in Oslo, unfortunately.  Hugh Daniel will be there, but
he doesn't have the history.

Deploying an RR type that only exists in superzones is not quite as
bad as deploying one that exists everywhere.  The number of superzones
is smaller than the number of zones, and the most critical superzones
(. and .com and etc) are running on machines that "nominally" always
upgrade to the latest BIND anyway, so they'll be able to serve new RR
types.

Having scanned the draft once:

Summary: REJECT WITH PREJUDICE.  Poorly defined, unnecessarily complex,
doesn't solve the problem it claims to, doesn't even address the
real problems of DNSSEC.

The biggest problem with DNSSEC appears to be paper designs that do
not benefit from operational evolution.  In other words, DNSSEC is not
going through the winning part of the IETF process (draft, implement,
try, redraft, implement, try, ... standardize).  Instead we go through
a series of paper specs trying to standardize them with no operational
experience.  Note I said operational, not programming.

I suggest that we operate with the specs we have and learn from 'em.
THEN change 'em.

This paper design continues many of the problems of prior DNSSEC
drafts; it lays out grand schemes without considering the operational
details.  The open-ended "Security parameters of a zone" is one
example (including things like "Signature policy.  This is an untested
issue.").

The draft goes to even more ridiculous lengths than NXT to secure
negative answers.  (NXT more than doubles the size of your zone, to
give definitive "NO"s for names that aren't in the zone.)  In addition
to NXT, we now have a bitmap in the parent zone (!!!) that gives five
options on how the child zone might handle negative answers.  These
options can be used in combination.  (At least if the WG thinks this
level of abomination is needed, it should be expressed in the child
zone rather than in the parent.  Such a record in the child would be
signed by the zone key, so it can't be spoofed.  Though I suppose its
*absence* could be spoofed, hmm...)

Then we get to the meat.  The SEC record doesn't really have fields
that specify security parameters.  Instead it holds little
sub-packets, each of which has to be parsed, each of which specifies
security parameters.  These sub-packets have option specifier bytes,
optional lengths, and data.  The length of most of the options is
defined in the spec, so that when new options are added, all existing
implementations will be unable to parse them.  The draft specifies
various combinations of options that are not permitted together.  I
don't see why we don't just go straight to X.509 and ASN.1 instead --
it's simpler and easier.

The text file format is highly readable, consisting of a series of hex
numbers.  (At least the numbers are in hex; the DNSSEC KEY record has
bit-flags expressed in decimal.)  The parsing of the hex is screwy;
some fields have 0x, some do not, and this difference appears to have
some meaning, though it's not clear what meaning.

The draft claims it's a successor to Zone Key Referral by me and Jerry
Scharf.  Did I really do that?   It doesn't actually include the name of
the Zone Key Referral draft, but elsewhere it says it's "by the same
authors" (as itself, presumably).

	John

---

From: David Blacka <[email-masked]>
Date: Thu, 27 May 2004 01:02:41 -0400

> tld are insecure.  This last point is fixable.

It is possible that you are using a different set of assumptions than I 
am.  I'm assuming that Charlie, when it doesn't understand NSEC2, 
operates under the current DNSSECbis specs.

That assumption sort of rules out null DS records, I think.  I make 
this assumption because if, for instance, Charlie would have to 
understand both NSEC and null DS, then it might as well understand 
NSEC2 as well.

> deployment strategy, and to consider fixing things that are fixable.

I absolutely agree with this.  However, even though we may now think we 
know what NSEC2 looks like, if we pursue this versioning path, we will 
have to assume that we do not actually know what future NSEC-like 
records will look like.  That makes it pretty difficult to figure out 
how to compensate for it, I think.

---

From: Roy Badami <[email-masked]>
Date: Thu, 27 May 2004 10:23:16 +0100

>>>>> "David" == David Blacka <[email-masked]> writes:

    David> It is possible that you are using a different set of
    David> assumptions than I am.  I'm assuming that Charlie, when it
    David> doesn't understand NSEC2, operates under the current
    David> DNSSECbis specs.

Possibly.  I am assuming that DNSSECbis is modified so NSEC RRs
contain a version field, which is set to 1 (say).  I am also assuming
that when a DNSSECbis resolver sees a response in which all the NSEC
RRs have a version greater than 1 (and those RRs are correctly
signed), it treats the response as insecure, rather than bogus.

The question is, would this allow the subsequent introduction of a
version 2 NSEC record in a relatively painless manner?

I assert that the null DS record would make such introduction more
painless.  The main cost (increased zone size) is borne by those who
want to use later versions of NSEC, though it does of course add a
(small) additional complexity to DNSSECbis resolvers.

    David> I absolutely agree with this.  However, even though we may
    David> now think we know what NSEC2 looks like, if we pursue this
    David> versioning path, we will have to assume that we do not
    David> actually know what future NSEC-like records will look like.
    David> That makes it pretty difficult to figure out how to
    David> compensate for it, I think.

That's true.  But null DS records don't rely on having any NSEC-like
records at all.  So it would seem to me that they can complensate for
_any_ change to NSEC.

      -roy

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Thu, 27 May 2004 11:30:11 +0200

> > zone at everyone's disposal via anonymous FTP either.

In virtue of what?

Regards,
Marcos

---

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

> > > zone at everyone's disposal via anonymous FTP either.

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: Jim Reid <[email-masked]>
Date: Thu, 27 May 2004 16:37:10 +0100

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

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

Why? There are perfectly good operational reasons for that. Like not
wanting their name servers burdened with large numbers of long-lived
TCP connections. Some may even be running DNS software that doesn't
*implement* AXFR.

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

Apart from the obvious universal truths, that's a given. Around the
world there are too many different (mutually exclusive?) laws on stuff
like data protection, privacy, crypto, consumer protection, monopolies
and so on. Reconciling these is impossible. It would be foolish to
even try.

---

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?

---

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: Robert Elz <[email-masked]>
Date: Fri, 28 May 2004 17:51:16 +0700

Date:        Wed, 26 May 2004 13:36:36 +0200
    From:        [email-masked]
    Message-ID:  <[email-masked]>

[quoting someone...]
  | > 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.
  | 
  | But it's okay to let random users enumerate the zone by following
  | NSEC RRs?

There's a big difference (and Jim, it isn't TCP vs UDP, for a zone
transfer, the extra overhead of TCP is in the noise).

The "problem" of AXFR is that it requires a stable zone image to transfer,
and so the server must (somehow) create that stable zone, when the AXFR
request is made, and then transfer the zone as it was at the instant the
initial SOA of the response was sent - regardless of any later changes that
are made to the zone.

Since the server has no idea whether or not any changes may be made to the
zone while the transfer is in progress, it has to do something to prepare for
the possibility that they may occur (as it also has no way to know how long
the zone transfer will take to complete, it also can't just delay updates
until after that has happened - that could be hours, or more, into the future).

This is what makes AXFR costly, and is certainly why I disabled it for
non-secondaries when I was running zones for which it made a difference.

The extra load of some number of random people doing zone slurps
(especially using an NSEC type technique, where each subsequent query has
to wait till the reply to the former is received, as that's where the
qname for the next query comes from) when compared to the normal load on
a busy server of handling "normal" queries (the ones that succeed, and
even more, the ones that end up failing) is barely going to be noticeable.
You'd need to postulate hundreds, or more likely, thousands, of people
all deciding to walk the chain at the same time before the query rate would
really start to be noticeable.  [Yes, I know, the really busy servers don't
want any unnecessary queries, but there are better things to try and stop
than this I suspect].

It is also worth noting that the oft made claim that NSEC allows pristine
zone copies to be made is false - it improves the chances of that happening
over some other methods, but it is certainly not a technique that will
guarantee the successful transfer of a zone.

kre

ps: apologies for the bogus copyright law noise I sent in an earlier
message, it has been a long time since I needed to look at that stuff.
Copyright was created initially as a means to encourage publication,
so that was a requirement to get the protection - beats me why that
requirement was dropped, but apparently it has been.

---

From: [email-masked] (Geoffrey Sisson)
Date: Fri, 28 May 2004 12:48:43 +0100 (BST)

> even more, the ones that end up failing) is barely going to be noticeable.

It would be surprising if NSEC RR elaboration techniques didn't
incorporate considerable parallelism, especially for large zones.  This
could impose arbitrarily high loads on a busy nameserver.  For example,
multiple simultaneous elaborations could be run, one starting at
'aaa.co.uk', another starting at 'aab.co.uk', and so on.

This isn't idle speculation: prior to incorporating token bucket into
the WHOIS server at whois.nic.uk [note: reference to WHOIS for
illustrative purposes only!] we used to have a one-second sleep to
limit the impact of scripts.  Impatient data miners designed tools
which sent queries in parallel -- sometimes hundreds per second -- in
order to collect data at higher rates.  The consequences to server
performance were, well, predictable . . .

Regards

Geoff

---

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: Paul Vixie <[email-masked]>
Date: Fri, 28 May 2004 14:24:50 +0000

robert wrote:

> The "problem" of AXFR is that it requires a stable zone image to
> transfer, and so the server must (somehow) create that stable zone,
> when the AXFR request is made, and then transfer the zone as it was at
> the instant the initial SOA of the response was sent - regardless of
> any later changes that are made to the zone.
> 
> Since the server has no idea whether or not any changes may be made to
> the zone while the transfer is in progress, it has to do something to
> prepare for the possibility that they may occur (as it also has no way
> to know how long the zone transfer will take to complete, it also
> can't just delay updates until after that has happened - that could be
> hours, or more, into the future).
> 
> This is what makes AXFR costly, [...]

RFC 1035 makes a provision for killing in-progress AXFR if the zone changes
while it's being transferred, and BIND4/BIND8 work that way.  this causes
problems for extremely-dynamic zones, like when UPDATE is used by dhcp in
an enterprise or wireless context, and so BIND9 has extensive (and expensive)
internal versioning and refcounting so that a zone at a certain serial number
can continue its AXFR even though newer zones (with different serial numbers)
are being used for subsequent queries (or even subsequent AXFR).  robert is
quite right, this is the biggest reason why a TLD registry (or anyone else)
would find AXFR expensive.

however, back in the days when f-root served COM, we were alone among the
root servers in supporting AXFR for it.  network solutions hated this
practice, and ultimately had someone in USGov send us a letter asking us
to turn it off, which we did.  but while it was on, our puny little 8GB
4x500MHz alphas handled a hell of a lot of outbound AXFR traffic for what
was, even then, the largest zone on the planet.  we did it on BIND8 and we
did it on BIND9.  the load, while expensive in exactly the ways that robert
suggests above, was never a noticable problem for a little nonprofit without
a hardware budget who was totally dependent on the kindness of our friends.

in these days when a dual or quad Opteron with 16GB and 2x2GHz or 4x2GHz
can be had from reputable vendors like sun, ibm, hp, or a hundred whitebox
vendors for a couple thousand USD, no serious commercial entity can complain
that any zone, even one the size of COM, cannot support AXFR.

> guarantee the successful transfer of a zone.

agreed.  an NSEC chainwalk would have none of AXFR's guaranteed stability.
if the zone changes during a chainwalk, then you get part of the old and
part of the new.  not that this makes much difference to the zone operators,
who are clearly more concerned with competition and abuse than with copyright
or resources.

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: 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: 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: [email-masked]
Date: Fri, 28 May 2004 16:49:49 +0200 (CEST)

On Fri, 28 May 2004, Paul Vixie wrote:

> during an extended overlap period.

Okay, if I sign dnss.ec with TRUDY algorithm only, would your resolver,
incapable of understanding TRUDY treat that zone as signed ? unsigned ?
Bad ?

If you'd follow spec, you should treat is as unsigned. WHOA there is your
downgrade attack.

> (did you think dnssec could be at its third unreleased version after a
> ten year period without solving something so simple?)
>

Then we better well spec your upgrade path. Its not the alternative
signing algorithm hack, right ?

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.

---

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