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: "Christian Huitema" <[email-masked]>
Date: Tue, 18 May 2004 13:21:01 -0700

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

Ben is right. Rate limiting is trivially defeated by exploring the
domain slowly. The slow-down can be easily compensated by performing
several searches in parallel, or by distributing the load among several
machines. These techniques are commonly used to scan subnets and ports
today. 

Similarly, firewall filtering is hard to apply if the server intends to
publish the information in the first place.

-- Christian Huitema

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Wed, 19 May 2004 09:46:32 +0200

I concur with Simon and would feel more confortable when dropping the 
statement "there are non-DNS protocol means [...]".

Why "are"? Have we seen some implementation of it? Do we know how 
practicable it is or how well the problem gets addressed? One could say 
"there could be non-DNS protocol means..", but that is a non-statement.

The problem is there. There is no real solution today. Let's face it.

Regards,
Marcos

---

From: [email-masked] (Ted Lindgreen)
Date: Wed, 19 May 2004 10:10:05 +0200

[Quoting Marcos Sanz/Denic, on May 19,  9:53, in "RE: WG Last Call: DN ..."]
> "there could be non-DNS protocol means..", but that is a non-statement.

There _are_ implementations to reduce the (privacy-) problems that
are aggrevated by zone walking, and there are people actively working
on this issue, both from the legal and technical perspective.

I think the current text is as good as it gets and propose to keep
it as it is now.

Regards,
-- ted

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Wed, 19 May 2004 10:35:57 +0200

> are aggrevated by zone walking, 

Then I am sorry for divulging FUD. Can somebody send a pointer to these 
existing solutions?

Regards,
Marcos

---

From: [email-masked] (Ted Lindgreen)
Date: Wed, 19 May 2004 10:45:43 +0200

[Quoting Marcos Sanz/Denic, on May 19, 10:39, in "RE: WG Last Call: DN ..."]
> Then I am sorry for divulging FUD. Can somebody send a pointer to these 

You must have missed my answer to you directly, so I'll repeat it
on the list.

--- Forwarded mail from [email-masked] (Ted Lindgreen)

>From [email-masked] Wed May 19 10:41:29 2004
Date: Wed, 19 May 2004 10:41:27 +0200
In-Reply-To: "Marcos Sanz/Denic's message as of May 19, 10:19"
To: Marcos Sanz/Denic <[email-masked]>, [email-masked] (Ted Lindgreen)
Subject: RE: WG Last Call: DNSSEC bis documents

[Quoting Marcos Sanz/Denic, on May 19, 10:19, in "RE: WG Last Call: DN ..."]
> Excuse my ignorance, Ted: can you send me a pointer? I haven't read about 
> that anytime in namedroppers.

Probably right: I don't think it is a protocol issue anyway.

As for a pointer, see f.i. the presentation from Bart Boswinkel
(CEO of SIDN/.nl) in:
 http://www.sdl.sri.com/other/dnssec/DNSSEC04MayNL-Info.html

As for work done: the main problem is that zonewalking facilitates
extracting whois info (zonewalking as such can not be expected to
have big legal implications, as DNS-info is intentionally made
public; however, whois-info is sensitive in terms of the European
privacy legislation, therefore the combination is dangerous).

SIDN has put significant effort to make the internet community
(in the broad sense) aware of the problem and to work to consensus
how to deal with it.

Regards,
-- ted

--- End of forwarded message from [email-masked] (Ted Lindgreen)

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Wed, 19 May 2004 11:04:23 +0200

Ted,

> http://www.sdl.sri.com/other/dnssec/DNSSEC04MayNL-Info.html

The presentation is interesting, but I couldn't find any existing 
technical solution to the NSEC traversal problem there. This was what I 
was looking for when I asked for a pointer of "non-DNS protocol means of 
detecting and limitting this attack".

> extracting whois info

If there is a problem with whois, whois should be fixed. I personally 
agree with you. But the problem is "a zone can be traversed" and the 
policy of many registries doesn't allow zone transfer. There, I was 
looking for a solution.

> (in the broad sense) aware of the problem and to work to consensus

No criticism at all on SIDN's work.

I am for dropping the sentence.

Regards,
Marcos

---

From: [email-masked] (Ted Lindgreen)
Date: Wed, 19 May 2004 15:42:03 +0200

[Quoting "Olaf M. Kolkman", on May 18, 8:55, in "WG Last Call: DNSSEC ..."]
>    draft-ietf-dnsext-dnssec-records-08.txt

I have carefully read the three documents. On a number of issues,
we (NLnet Labs) had some violant discussions, but in all cases we
concluded that the solutions and wordings as chosen by the authors
were the best possible.

I would like to state that I support the document set as is, and
thank the authors for the tremendous amount of work they have done.

Regards,
-- ted

---

From: [email-masked] (Geoffrey Sisson)
Date: Wed, 19 May 2004 15:01:34 +0100 (BST)

Jim Reid <[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.

FWIW we've in the last two years weve observed an increase in WHOIS
elaboration attempts against whois.nic.uk which employ pools of
unsecured WHOIS (and web) proxies, as well as what are probably
`botnets'.  I suspect that unsecured DNS resolvers are considerably
more numerous, and that no suitable rate-limiting mechanisms -- even
intelligent ones which might employ advanced pattern analysis -- will
be practicable againt NSEC RR enumeration.

Regards

Geoff

---

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

>>>>> "Ted" == Ted Lindgreen <[email-masked]> writes:

    Ted> I would like to state that I support the document set as is,
    Ted> and thank the authors for the tremendous amount of work they
    Ted> have done.

I heartily agree. Gentlemen, please take a bow. We should all shake
you warmly by the hand and buy you a drink. Perhaps in San Diego?