WG Last Call: DNSSEC bis documents
Olaf M. Kolkman
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 <dnssec-...@east.isi.edu>.
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 namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Simon Josefsson
> This message starts the WG last call for the DNSSEC-bis document set.
>
> 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
Jim Reid
>> 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.
Christian Huitema
> >> 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.
>=20
> 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.=20
Similarly, firewall filtering is hard to apply if the server intends to
publish the information in the first place.
-- Christian Huitema
Simon Josefsson
> 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.
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
David Blacka
> What are those "non-DNS protocol means of detecting and limiting the
> attack"?
...
> 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 <dav...@verisignlabs.com>
Sr. Engineer VeriSign Applied Research
Marcos Sanz/Denic
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
Ted Lindgreen
> 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.
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
Marcos Sanz/Denic
> are aggrevated by zone walking,
Then I am sorry for divulging FUD. Can somebody send a pointer to these
existing solutions?
Regards,
Marcos
Ted Lindgreen
> > There _are_ implementations to reduce the (privacy-) problems that
> > are aggrevated by zone walking,
>
> Then I am sorry for divulging FUD. Can somebody send a pointer to these
> existing solutions?
You must have missed my answer to you directly, so I'll repeat it
on the list.
--- Forwarded mail from t...@NLnetLabs.nl (Ted Lindgreen)
>From t...@open.nlnetlabs.nl 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 <sa...@denic.de>, t...@NLnetLabs.nl (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 ..."]
> > There _are_ implementations to reduce the (privacy-) problems that
> > are aggrevated by zone walking,
>
> 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 t...@NLnetLabs.nl (Ted Lindgreen)
Marcos Sanz/Denic
> 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
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".
> As for work done: the main problem is that zonewalking facilitates
> 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.
> 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.
No criticism at all on SIDN's work.
I am for dropping the sentence.
Regards,
Marcos
Jim Reid
>> 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.
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.
Ben Laurie
>>>>>>"Simon" == Simon Josefsson <j...@extundo.com> 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.
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
Ted Lindgreen
>
> Dear Colleagues,
>
> This message starts the WG last call for the DNSSEC-bis document set.
>
> draft-ietf-dnsext-dnssec-intro-10.txt
> and
> 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
Geoffrey Sisson
> 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.
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
Jim Reid
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?
Edward Lewis
>- Part of my reason for wanting to ship now is that I have learned,
> the hard way, that DNSSEC is (necessarily, due to backward
> compatability issues) a very complex beast whose semantics we aren't
> smart enough to change quickly (at least, I know that -I'm- not that
> smart -- whether others here really are that smart or are just
> kidding themselves is a personal matter between any such people and
> their respective rabbis, none of my business).
To wit: after talking on the phone with someone about my earlier
message on NSEC2 (not a linear growth, but a small constant bump),
the question of all the new hash names was still there. I.e., do we
have to provide auth denial for the names created as part of the
hash? What if there's a name clash?
Not to discuss that - but to illustrate - there's still a lot to consider.
>- As one of the people who was originally muttering about perhaps
> adding a version number in the NSEC RR, I should state that over the
> weekend I came to the same conclusion as Paul Vixie did, namely,
> that another typecode roll would probably be the best way to handle
> an incompatable change (whether to NSEC2 or to something else).
Again - there's a lot more needed on this. What is the impact on the
design of the applications "above" DNS? I don't think we've
adequately discussed and presented this to applications developers.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-703-227-9854
ARIN Research Engineer
Even the voices inside my head are refusing to talk to me anymore.
Rob Austein
(etc) debate has raged, I will nonetheless note that today is the last
day of the WGLC, so here's my opinion, for whatever it's worth:
Summary: Ship it.
Disclaimers: I'm one of the DNSSECbis editors, so I have to recuse on
whether the current documents adaquately express the current protocol.
Due to my day job, I also have some interest in getting BIND 9.3.0 out
the door, and thus find last minute proposals for semantic changes
somewhat disturbing, particularly given that the January 2004 WGLC
concluded that the protocol semantics were cooked and that it was just
the documents expressing those protocol semantics that still needed
work. None of this is the WG's problem, just bias disclosure.
Rationale for why I think we should ship DNSSECbis as it stands:
- I believe that the protocol is reasonable as an attempt to address
the stated design goals (see draft-ietf-dnsext-dns-threats-07 and
the earlier source material it references).
- I, personally, wearing my just-another-bozo-on-this-bus hat, do not
believe that the NSEC enumeration threat is worth further delay at
this point, for two reasons: avoiding it wasn't a design goal, and
I, personally, don't believe that the information leak in question
can really be controlled in any case, given the combination of
dictionary attacks, address walking, web crawling, and so forth.
- I do understand that some view zone walking as a serious problem,
and would not be adverse to further work that attempts to find a way
to avoid it, but will note that this would be design goal change and
might have nontrivial implications that we don't yet understand.
- Part of my reason for wanting to ship now is that I have learned,
the hard way, that DNSSEC is (necessarily, due to backward
compatability issues) a very complex beast whose semantics we aren't
smart enough to change quickly (at least, I know that -I'm- not that
smart -- whether others here really are that smart or are just
kidding themselves is a personal matter between any such people and
their respective rabbis, none of my business).
- As one of the people who was originally muttering about perhaps
adding a version number in the NSEC RR, I should state that over the
weekend I came to the same conclusion as Paul Vixie did, namely,
that another typecode roll would probably be the best way to handle
an incompatable change (whether to NSEC2 or to something else).
- To the extent that DNSSECbis as currently specified might be useful
to anybody, it would be a disservice to those users to delay it (yet
again) while we hack new semantics.
- At the end of the day, I'm left asking myself a simple question: is
DNSSECbis cooked enough that it's better than what the users have
now? I think that it is, so I think we should ship it.
Finally, a recommendation: If I were on the IESG and I were to receive
a request for advancement of the DNSSECbis docs, I would find it very
helpful to receive, as part of the write-up, several paragraphs
explaining the discussion which the WG has already had on this topic,
since otherwise I would feel duty-bound to ask the WG about it. This
is a sufficiently complex topic and has gone on at sufficient length
that it would not be reasonable to expect the entire IESG to follow
the debate (not if we also expect them to get anything else done,
anyway). So we need to help. That's our chairs' job, but they may
need our help, in which case I expect that they will ask us for it.
Rob Austein
> At 15:15 -0400 6/1/04, Rob Austein wrote:
>
> > adding a version number in the NSEC RR, I should state that over the
> > weekend I came to the same conclusion as Paul Vixie did, namely,
> > that another typecode roll would probably be the best way to handle
> > an incompatable change (whether to NSEC2 or to something else).
>
> design of the applications "above" DNS? I don't think we've
> adequately discussed and presented this to applications developers.
I'm reasonably confident that a complete type code roll would simply
revert any DNSSECbis-using applications back into the universe we have
today in a relatively clean way.
A partial type code roll might be more, um, "interesting".
Ben Laurie
> At 15:15 -0400 6/1/04, Rob Austein wrote:
>
>> - Part of my reason for wanting to ship now is that I have learned,
>> the hard way, that DNSSEC is (necessarily, due to backward
>> compatability issues) a very complex beast whose semantics we aren't
>> smart enough to change quickly (at least, I know that -I'm- not that
>> smart -- whether others here really are that smart or are just
>> kidding themselves is a personal matter between any such people and
>> their respective rabbis, none of my business).
>
>
> To wit: after talking on the phone with someone about my earlier message
> on NSEC2 (not a linear growth, but a small constant bump), the question
> of all the new hash names was still there. I.e., do we have to provide
> auth denial for the names created as part of the hash? What if there's
> a name clash?
My view would be that the names don't really exist, or can be considered
to be in a different namespace. I don't know if there's some obscure
reason that this is the wrong view to have, though.
> Not to discuss that - but to illustrate - there's still a lot to consider.
I guess we have to discuss it at some point!
Cheers,
Ben.
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
--