RE: Proposal to fix NSEC
Scott Rose
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: owner-nam...@ops.ietf.org
> [mailto:owner-nam...@ops.ietf.org]On Behalf Of Ben Laurie
> Sent: Wednesday, May 19, 2004 7:36 AM
> To: namedr...@ops.ietf.org
> Subject: Proposal to fix NSEC
>
>
> 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.
>
> --
> http://www.apache-ssl.org/ben.html http://www.thebunker.net/
>
> "There is no limit to what a man can do or how far he can go if he
> doesn't mind who gets the credit." - Robert Woodruff
>
>
> --
> to unsubscribe send a message to namedroppe...@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
>
--
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/>
Mark Andrews
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: Mark_A...@isc.org
Paul Vixie
> ...
> However, "fixing NSEC" will not fix the real (whois) problem.
>
> -- teds
i agree with ted. dns is a publication mechanism, and if you don't want
something published you probably shouldn't be putting it into dns at all.
and, if your only way to keep whois safe is to hide its index, then you
have probably got other troubles. parts of the "index" are exposed every
day in server logs or in-addr.arpa/ip6.arpa walks.
Simon Josefsson
>
> >>>>> "Ben" == Ben Laurie <ben <at> algroup.co.uk> writes:
>
> >> 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.
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
Scott Rose
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
Scott Rose
> -----Original Message-----
> From: Ben Laurie [mailto:b...@algroup.co.uk]
> >
> > 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.
>
> To be clear, EXISTs only exist where no other RR exists, but I don't
> think that changes your point.
>
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 Rose
> -----Original Message-----
> From: Ben Laurie [mailto:b...@algroup.co.uk]
>
> > 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).
>
> 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
> 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
>
Robert Elz
From: Peter Koch <p...@TechFak.Uni-Bielefeld.DE>
Message-ID: <200405191828...@grimsvotn.TechFak.Uni-Bielefeld.DE>
| 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.
Loomis, Rip
> > The problem is that [online signing is] just too prone to
> > DoS attacks.... Which is BAD.
>
> A standard could be established to help thwart DoS attack.
>
> 1) Only use signatures for queries from named name servers
> (ns record exists).
This blatantly ignores the completely common case where
the set of recursive/caching/resolving nameservers for an
organization are separate from the set of authoritative
nameservers (with NS records for the zone delegation)
for that organization. As a result, your notional standard
is not likely to work.
--Rip
Paul Vixie
> 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
> allow enumeration.
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.
r...@dnss.ec
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
Ben Laurie
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.
"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
> bman...@vacation.karoshi.com 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.
That is correct: the whois data is the (privacy legislation) problem,
and being able to walk the tree exposes this problem even more, and
certainly makes it more visible.
However, "fixing NSEC" will not fix the real (whois) problem.
-- teds
--
Ben Laurie
> On Wed, May 19, 2004 at 12:35:44PM +0100, Ben Laurie wrote:
>
>>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 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.
"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
--
Marcos Sanz/Denic
> We've already done this 3 years ago and I see no reason in bringing this
> 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
Jim Reid
>> 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.
--
Ben Laurie
> 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.
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
> become a DoS attack vector by a malicious or silly admin setting the number
> arbitrarily high?
Yes, I noted that somewhere, implementations should probably just fail
for values locally considered to be too 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?
Its to prevent precomputed dictionary attacks (this is explained in the
security considerations). This matters if your zone is worth rescanning
frequently.
> 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.
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.
"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
--
r...@dnss.ec
> Roy,
>
> > We've already done this 3 years ago and I see no reason in bringing this
> > back.
>
> With all my respects, the reason is on the table:
> 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
Ben Laurie
> <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
Correct, though I did reinvent it all on my own :-)
> 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).
Surely the returned RRs could simply be either NSEC or NSEC2, and the
resolver chews whichever it gets?
> 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.
Why is the assumption false?
> 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.
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.
> 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.
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.
"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
--
Ben Laurie
>>>>>>"Ben" == Ben Laurie <b...@algroup.co.uk> writes:
>
>
> >> 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.
The problem is the _combination_ of NSEC and whois.
r...@dnss.ec
> r...@dnss.ec wrote:
> > <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
>
> Correct, though I did reinvent it all on my own :-)
>
> > 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).
>
> Surely the returned RRs could simply be either NSEC or NSEC2, and the
> 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.
> > 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.
>
> Why is the assumption false?
That would be in the dnssec-protocol draft. Empty non-terminals are not
special in DNSSEC.
> > 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.
>
> 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.
>
> > 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.
>
> 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).
I would prefer an offline dictionary attack over a online querying attack
if I did not want to leave to much trails.
Roy
Jim Reid
>> 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?
Ben Laurie
> On Wed, 19 May 2004, Ben Laurie wrote:
>
>
>>r...@dnss.ec wrote:
>>
>>><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
>>
>>Correct, though I did reinvent it all on my own :-)
>>
>>
>>>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).
>>
>>Surely the returned RRs could simply be either NSEC or NSEC2, and the
>>resolver chews whichever it gets?
>
>
> That means a requirement to implement both.
Yes. Or we could deprecate NSEC.
> If I just implement either
> NSEC or NSEC2 in my resolver, one can be used to downgrade the other.
>
>
>>>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.
>>
>>Why is the assumption false?
>
>
> That would be in the dnssec-protocol draft. Empty non-terminals are not
> special in DNSSEC.
I'll come back to this when I've thought about it more.
>>>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.
>>
>>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.
>>
>>
>>>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.
>>
>>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).
>
>
> I would prefer an offline dictionary attack over a online querying attack
> 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.
"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
--
Ben Laurie
>>>>>>"Ben" == Ben Laurie <b...@algroup.co.uk> writes:
>
>
> >> 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?
Indeed I have, which is why iterations is a tunable parameter.
r...@dnss.ec
> Peter Koch wrote:
> >
> > There are other alternatives, including online signing, maybe with a
> > different key. The zones in question have some special properties (almost
> > "NS only"), which may also be exploited to find a solution.
>
> I have hesitated to suggest alternatives that include online signing,
> because of the principle that private keys should not be exposed by
> putting them on connected machines.
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
Ben Laurie
> On Wed, May 19, 2004 at 03:43:41PM +0100, Ben Laurie wrote:
>>The problem is the _combination_ of NSEC and whois.
>
> 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?
"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
--
Ben Laurie
> 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.
>
> 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.
To be clear, EXISTs only exist where no other RR exists, but I don't
think that changes your point.
> 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).
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.
Jim Reid
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?
Jim Reid
>> 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.
Ben Laurie
> Jim reid wrote:
>>If the rewards for a successful attack are high enough, this isn't an
>>acceptable risk. How much would it cost to implement SHA-1 in
>>hardware, assuming there aren't chips that can do this already?
>
>
> different key. The zones in question have some special properties (almost
> "NS only"), which may also be exploited to find a solution.
I have hesitated to suggest alternatives that include online signing,
because of the principle that private keys should not be exposed by
putting them on connected machines. However, it is definitely worth
saying that online signing would completely eliminate traversal.
Cheers,
Ben.
"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
--
Peter Koch
> 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
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.
> 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".
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.
> 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?
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
Ben Laurie
>
>>-----Original Message-----
>>From: Ben Laurie [mailto:b...@algroup.co.uk]
>>
>>>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.
>>
>>To be clear, EXISTs only exist where no other RR exists, but I don't
>>think that changes your point.
>>
>
>
> 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?
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.
> 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).
Are you referring to sections 4 and 5 of DNSSECbis? Or of NSEC2?
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
--
Bob Halley
> 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.
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.
Sal Mangiapane
> Peter Koch <p...@TechFak.Uni-Bielefeld.DE> writes:
>
> > Bob Halley <Bob.H...@nominum.com> wrote:
> >
> >> The problems with online signing are:
> >>
> >> It's a CPU burden for the authoritative nameserver.
> >
> > Yes, but the operators in question (TLD registries) should be able to deal
> > with this.
>
> I don't think you understand what level of CPU burden online signing
> can be in the face of unauthenticated 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-existent) 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.
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
George Michaelson
>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
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: g...@apnic.net | PO Box 2131 Milton QLD 4064
Phone: +61 7 3858 3150 | Australia
Fax: +61 7 3858 3199 | http://www.apnic.net
Ben Laurie
> On Wed, 19 May 2004, Ben Laurie wrote:
>
>
>>Peter Koch wrote:
>>
>>>There are other alternatives, including online signing, maybe with a
>>>different key. The zones in question have some special properties (almost
>>>"NS only"), which may also be exploited to find a solution.
>>
>>I have hesitated to suggest alternatives that include online signing,
>>because of the principle that private keys should not be exposed by
>>putting them on connected machines.
>
>
> A ssh/tls/ipsec capable machines have a private key on connected
> machines.
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.
"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
--
Marcos Sanz/Denic
that
> | 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.
> 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.
Simon just said it: fixing whois will remove whois from the examples, but
won't remove the traversal problem.
Regards,
Marcos
Jim Reid
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.
Roy Badami
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
Jim Reid
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.
Jim Reid
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.
Roy Badami
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
Jim Reid
Jim> This is already known. Now why do some people believe that
Jim> this enumeration is a *technical* problem?
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.
Peter Koch
> The problems with online signing are:
>
> It's a CPU burden for the authoritative nameserver.
Yes, but the operators in question (TLD registries) should be able to deal
with this.
> 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.
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
Derek Atkins
Peter Koch <p...@TechFak.Uni-Bielefeld.DE> writes:
> Bob Halley <Bob.H...@nominum.com> wrote:
>
>> The problems with online signing are:
>>
>> It's a CPU burden for the authoritative nameserver.
>
> Yes, but the operators in question (TLD registries) should be able to deal
> with this.
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
de...@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant
Sal Mangiapane
> On Wed, 19 May 2004, Ben Laurie wrote:
>
> > Peter Koch wrote:
> > >
> > > There are other alternatives, including online signing, maybe with a
> > > different key. The zones in question have some special properties (almost
> > > "NS only"), which may also be exploited to find a solution.
> >
> > I have hesitated to suggest alternatives that include online signing,
> > because of the principle that private keys should not be exposed by
> > putting them on connected machines.
>
> 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.
>
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
Olaf Kolkman
Dear Colleagues,
Let me try and sumarise what I've seen so far and suggest a way
forward.
Ben proposed a mechanism to fix "NSEC zone traversal" that apparently
hinders TLDs in the deployment of DNSSEC. Although the discussion on
the validity of this reason is interesting it is not a protocol issue.
We
will not be able to change TLD policies.
The proposed mechanism, I'll refer to is as NSEC2, may have technical
merit.
I think it is fair to say that the working group is still digesting the
technical
details of the proposal. Please continue to do so, having documented
why a
technology will or will not work is a good thing.
As far as I understand the security properties of the proposed
technology are such that changes are needed to the protocol as in
DNSSEC-bis. This means that we have to introduce a flag day. That flag
day either is "now" or after the DNSSEC-bis protocol is out in the
field.
We as a working group have a choice.
- We take up this NSEC2 proposal as a working item.
If we do so we will have to merge the technology into the current
DNSSEC-bis document set. Having a flag day, after introducing
DNSSEC-bis just does not make sense.
Realize that taking up this as a working item would result in an
unknown delay of getting the DNSSEC specifications done. Not only
will the WG need time to assess the quality of the proposed
solution but people currently funded to work on the effort may see
that funding stop and walk away. Realisticly we are looking at
significantly more than 6 months [*] delay. (We'll have to assess
interaction with wildcards and other DNS elements. We'll have to
test for corner cases, &c, &c). There are more pessimistic scenarios
than the 6 months scenario.
- We do not take up NSEC2 as a working item
This would not imply that the "NSEC zone traversal" is a non-issue.
It may actually hinder deployment of DNSSEC some TLD zones.
If we go this route we may have a proposed standard and start of
deployment in some zones this year in less than 6 months [*].
The DNSSEC-bis document set is clear on the fact that DNSSEC does
not offer privacy. We just have to live with that.
I'll be tracking the discussion with the following in mind.
If I do not see rough consensus on taking up NSEC2 as a work item by
June 1
I'll reject this as a work item.
If, after June 1, there is consensus on taking up NSEC2 as a work item
I'll try to make an inventory on how many participants of the working
group can commit resources to make this work. If it turns out we
cannot produce standards, documents and code on a reasonable time or
we alienate a significant fraction of the people that are now
committed on working on this we'll also not take NSEC2 up as a work
item.
If we'll take NSEC2 as a work item then - in order to avoid a flag day -
the current DNSSEC-bis doc set will be put on hold until NSEC2 is cooked
enough to be merged into the DNSSEC-bis documents.
Olaf Kolkman
DNSEXT Co-Chair
(Olafur is away from keyboard for a week or two.)
[*] I've been telling people that DNSSEC will be ready in 6 months
over the last 3 years. As a result the combination of "6 months"
and DNSSEC in one sentence rises suspicion.
Olaf Kolkman
On May 20, 2004, at 3:06 PM, Peter Koch wrote:
> 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.
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)
Olaf Kolkman
--Apple-Mail-1--593162129
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
format=flowed
Forwarded message 1 out of 2 (there where problems posting)
> From: Paul Vixie <pa...@vix.com>
> Date: May 19, 2004 4:33:42 PM CEST
> To: namedr...@ops.ietf.org
> Subject: Re: Proposal to fix NSEC
>
>
>>> NSEC provides an index to whois.
>> ...
>> However, "fixing NSEC" will not fix the real (whois) problem.
>>
>> -- teds
>
> i agree with ted. dns is a publication mechanism, and if you don't
> want
> something published you probably shouldn't be putting it into dns at
> all.
> and, if your only way to keep whois safe is to hide its index, then you
> have probably got other troubles. parts of the "index" are exposed
> every
> day in server logs or in-addr.arpa/ip6.arpa walks.
>
>
--Apple-Mail-1--593162129
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
charset=US-ASCII
Forwarded message 1 out of 2 (there where problems posting)
<excerpt><bold><color><param>0000,0000,0000</param>From:
</color></bold>Paul Vixie <<pa...@vix.com>
<bold><color><param>0000,0000,0000</param>Date: </color></bold>May 19,
2004 4:33:42 PM CEST
<bold><color><param>0000,0000,0000</param>To:
</color></bold>namedr...@ops.ietf.org
<bold><color><param>0000,0000,0000</param>Subject: </color>Re:
Proposal to fix NSEC
</bold>
<excerpt><excerpt>NSEC provides an index to whois.
</excerpt>...
However, "fixing NSEC" will not fix the real (whois) problem.
-- teds
</excerpt>
i agree with ted. dns is a publication mechanism, and if you don't
want
something published you probably shouldn't be putting it into dns at
all.
and, if your only way to keep whois safe is to hide its index, then you
have probably got other troubles. parts of the "index" are exposed
every
day in server logs or in-addr.arpa/ip6.arpa walks.
</excerpt>
--Apple-Mail-1--593162129--
Paul Vixie
> of "there's no possible reason why this issue should botther you" in
> 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.
> 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.
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.
> These differences may well affect what a registry feels comfortable
> 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.
> 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.
that's a reasonable middle ground, in my opinion.
Robert Elz
From: Roy Badami <r...@gnomon.org.uk>
Message-ID: <16556.39523....@giles.gnomon.org.uk>
| 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
Simon Josefsson
> 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.
> 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?
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
Simon Josefsson
> 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.
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
Hallam-Baker, Phillip
I am trying to work out the reason for the hash iterations.
Let us call the set of names in the zone
D = {d0, d1, d2, d3 ... dn}
The problem is to be able to enumerate the inverse of the set
D' = { ]d0-d1[, ]d1-d2[ ... ]dn-d0[ }
It suffices to present one member of D' to prove that any given domain is
not a member of D.
To describe a member of D we simply specify dx, dx+1
So what you are saying is that we do not need to deal with D, we can apply a
one way function...
HD = {H(d0), H(d1), ... H(dn) }
HD' = { { ]H(d0)-H(d1)[, ]H(d1)-H(d2)[ ... ]H(dn)-H(d0)[ }
So why do we need to specify more than H(dx), (H(dx+1)) ???
Ben Laurie
>>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'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.
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.
"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
--
Sal Mangiapane
> > > The problem is that [online signing is] just too prone to
> > > DoS attacks.... Which is BAD.
> >
> > A standard could be established to help thwart DoS attack.
> >
> > 1) Only use signatures for queries from named name servers
> > (ns record exists).
>
> This blatantly ignores the completely common case where
> the set of recursive/caching/resolving nameservers for an
> organization are separate from the set of authoritative
> nameservers (with NS records for the zone delegation)
> for that organization. As a result, your notional standard
> is not likely to work.
>
> --Rip
>
This is exactly what each group would need to establish. In this case, what the criteria for DNS would be.
The Internet benefits from the ubiquity of DNS. Couldn't the same be true for a single system of digital signatures?
Andras Salamon
> Currently, the
> unauthenticated queries, but to deny enumeration of the zone to
> unauthenticated parties.
As Jim stated, some _implementations_ of DNS servers allow this kind
of control.
> This is a technical change: specifically, the authentication model is
> now less fine-grained than it used to be.
More accurately, a previously possible hack would no longer be possible.
> Whether this technical change constitutes a problem would seem to
> depend on the legal and policy framework in which the nameserver is
> 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 and...@dns.net
Roy Badami
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
Peter Koch
> 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
Ben Laurie
> Bob Halley <Bob.H...@nominum.com> wrote:
>
>
>>The problems with online signing are:
>>
>> It's a CPU burden for the authoritative nameserver.
>
>
> Yes, but the operators in question (TLD registries) should be able to deal
> with this.
>
>
>> 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.
>
>
> 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.
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.
"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
--
Roy Badami
Olaf> Ben proposed a mechanism to fix "NSEC zone traversal" that
Olaf> apparently hinders TLDs in the deployment of
Olaf> DNSSEC.
I had been intending to avoid making any further on-list comments,
given I haven't been a WG participant, and that much of this thread
has been discussing issues which are both outside the scope of this WG
and outside the expertese of this WG.
But I just want to make one further point.
Contrary to what you suggest, I don't believe anyone with authority to
do so has clearly stated that that zone file traversal is a serious
barrier to deployment in certain registries. Ben very specifically
stated that he speaks for Nominet only on technical matters, not on
policy matters and, I believe, has avoided commenting in this thread
other than on the technical issues relating to his proposal. There
may be other people who have expressed this view whose afiliations I
am unware of, of course.
I don't have a strong opinion as to whether zone file traversal is a
serious issue for adoption or not. I'm just trying to suggest that
the answer to this question isn't as obvious as some particpants seem
to believe.
Nor am I expressing an opinion as to whether it would be appropriate
to consider modifying the DNSSECbis document set at this late stage.
However unless it is possible to get relevent input from those TLDs
that currently have a policy of not making their zone files available
to the public, then I suggest it would not be productive to persue
this issue at this stage, but that it should simply be noted as an
item for possible future study.
-roy
Roy Badami
Olaf> As far as I understand the security properties of the
Olaf> proposed technology are such that changes are needed to the
Olaf> protocol as in DNSSEC-bis. This means that we have to
Olaf> introduce a flag day.
It's not obviously (to me) an incredibly nasty flag day. If there is
a real desire to do this subsequently, zones can be given a choice of
publishing NSEC or NSEC2 records or both. The flag day is then the
day on which publishing NSEC records ceases to be mandatory. On this
day, old resolvers which don't understand the NSEC2 RR will start
getting resolution failures for non-existent domains, rather than
getting a clean NXDOMAIN answer.
Whilst not entirely ideal behaviour, this is potentially a manageable
scenario...
Mark Andrews
> Robert Elz <kre <at> munnari.OZ.AU> writes:
>
> > 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.
>
> 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 t
> hat
> access to the information about names in a domain, acquired via zone transfer
> s,
> helped an attacker. This still holds, for new not yet public weaknesses in
> various applications.
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.
> 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 soun
> d
> at first. A nice write-up that expand on this theme is:
>
> http://www.cs.uwyo.edu/~rex/privacy.html
>
> Regards,
> Simon
>
> --
> 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/>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
Paul Vixie
> > enumeration no easier than it is with plain DNS. Clearly there is no
> > point in doing more than this.
>
> 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.
Mark Andrews
> I see a some of arguments being made about EU concerns over privacy.
> The subject whether DNSSEC would be run into EU privacy concerns
> pops up on a regular base in various places.
>
> Therefore, SIDN, the Dutch registry, asked for an opinion of the
> faculty of law of the University of Brabant. These people, all
> lawyers, are specialized in privacy and the influence of crypto
> technology on the law (and vice versa). They don't have no specialist
> knowledge of the DNS, but know the role it has in the proper working
> of the Internet.
>
> I explained them the situation:
>
> Lots of ccTLDs are preventing zone transfers to be done by
> the public in general often using privacy concerns as the
> primary motif. I also explained that DNSSEC has this back
> door where you can get the names out of the zone by walking
> the NXT records. So the basic question was, is there really
> a concern that this backdoor might prevent the deployment
> of DNSSEC in Europe because of privacy regulation?
>
> Note, this was before NSEC records existed. I'm sticking here to
> the term NXT records to stay close to the original conversation.
>
> They were willing to do an small study, and, if they thought that
> there might be any problems, they would raise that and then we would
> decide whether a larger study was necessary.
>
> It resulted in:
> Tilburg University (B.J. Koops & E. Schreuders), Quickscan
> DNSsec/NXT and privacy, March 2003 (unpublished).
>
> It is not really big, I give here a translation from the Dutch,
> leaving out some of the details.
>
> We don't think that there is a special privacy problem with
> the deployment of DNSSEC caused by the NXT walking which
> would give you a list of names which might be used to query
> the whois service. The privacy rules are already in force
> by the Wbp (Dutch privacy law, fully implementing the EU
> directives --j) and the regulation of the registry. (I'm
> skipping the details they quote from court cases and articles
> in our regulations --j).
>
> DNSsec only offers something new by the capability to get
> a list of domain names. This list is irrelevant from a
> privacy point of view, only the combination with the whois
> database gives the list personal sensitive information (with
> the exception that of domain names such as michaeljfox.com,
> vix.com and jaap-akkerhuis.nl). Possible problems occur
> when the list is used for interrogating the whois database.
> But for that, there are already existing rules so DNSsec
> doesn't add any problems.
>
> In short, the back door can give personal data but only
> in combination with whois for which is existing regulation.
>
> Although they don't claim that they didn't do "fundamental research",
> We (SIDN) would have been happy to pay for such a study as well,
> but they refused, since they thought that such a study would have
> a very similar outcome.
>
> So, we concluded that the NXT walking (now NSEC) and (EU) privacy
> concerns would not be a show stopper for introducing DNSSEC in the
> NL zone.
>
> On this list in this context I noticed that also concernsabout the
> IP-rights (Intellectual Property rights) popped up, like one had
> on a telephone directory. (There the data is also meant to be public,
> but on how it is organized there are IP rights). You cannot just
> copy a directory because of that.
But you can compile your own. I seem to remember a court case
here where OCR scanning of a existing directory was illegal but
getting a team of typists to re-enter all the data in a
existing directory was legal.
> For a zone file you can claim
> this probably as well. That gives you a handle to whack people
> making copies. We discussed this internally somewhat. We think
> that IP-rights on a zone file is an interesting idea, but doesn't
> prevent zone enumeration. It has more juridical aspects then
> technical.
>
> Back to (EU and other) pivacy concerns. Given the fact that there
> are multiple ways to do data mining for domain names in a zone as
> pointed out by Paul Vixie and Robert Elz, one really must take steps
> to limit access to "whois data".
>
> jaap
>
> --
> 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/>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
--
Hallam-Baker, Phillip
> 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.
I disagree. The ONLY purpose of the protocols is to solve layer 9
problems. Layer 9 is PEOPLE.
Roy is stating that this issue is a showstopper for him. Your proposal
is in effect saying that the IETF, an organization with zero internal
democracy and zero accountability should override European Union law
decided by the democratically appointed European parliament and the
council of ministers appointed by the democratically elected European
governments.
Please consider the fact that the IETF claim to be above international
law might just possibly be the result of a ridiculous degree of
arrogance.
It is a valid point to say that the IETF may not have competence in
this area, but that may well mean that the IETF does not have competence
to write any specs whatsoever. if the legal interpretation is an issue
I suggest that we ask Michael Froomkin or some other DNS savy lawyer
their opinion rather than saying, "I do not understand this issue,
therefore I will not allow it to be raised."
It seems somewhat strange that people are arguing that the effects
of DNS zone walking are so well understood that no change could
possibly be required. The same people were arguing a little while
ago that a minor change that would introduce the risk of severe
DNS operational instability should be rejected for the sole reason
that the implication of the change could not possibly be understood.
Hallam-Baker, Phillip
> > So why do we need to specify more than H(dx), (H(dx+1)) ???
>
Ben,
I think that this risks turning a good proposal into one with a
questionable feature that will distract from the main value. Essentially all
you are arguing for here is an expensive hash function.
The valud of crypto is that you can introduce asymmetric attack
costs. It is much harder for an attacker to break DES than it is for the
defender to encrypt their message - 2^55.5 times as hard in fact. That is a
real benefit.
Here you just make the problem harder by an equal factor for
attacker and defender. That is not a core value here.
Leaving aside that nit, the proposal has real value and adds real
security. The comparative attack analysis that has been offered is totally
bogus:
The DNS system without DNSSEC provides a lookup function that
returns an answer to the question "is x a member of S" and returns a binary
response.
With DNSSEC and NSEC you get a response "there are NO members of x
in the range a,b AND a,b are both members of S"
Sorry, but anyone who claims that there is no security issue raised
here is speaking through their hat. The fact that I publish a binary
response function returning set membership does not mean that I am willing
to reveal the set. That is simply untrue.
The number of real world attacks that are made possible by revealing
S is very, very large and very, very significant. I know that there are folk
who dispute this in the IETF, remember however that there are people in the
IETF who have actively discouraged the deployment of firewalls in the past,
and some still do. Regardless of where you stand on that debate please
understand that the fact that if you want to deploy a security protocol it
had better meet the security requirements set by the security establishment.
In the real world the fact that there is an easy way for an attacker
to discover the names of all my public facing machines is a really really
significant issue. In the real world 95% of attacks are made by people who
are clueless. In the real world security is risk management, not risk
elimination. If you do not believe me on this go talk to Bruce S. or read
Secrets and Lies.
In the real world every security incident costs real money. Filters
that catch 95% of the bozos save real money.
The current NSEC record is bogus. It insists on addressing a
security issue that simply does not exist (securing insecure zones) while
refusing to address a real security issue which is rightly considered by
many to be a showstopper for adoption.
If there was a logic to the IETF process we would ask people two
questions, first what are the showstoppers that would cause you not to
deploy? second why should we care? I know the IETF lives in a
crypto-communist la-la land where it is impolite to ask such questions but
the failure to do so is the reason that DNSSEC is still a failed spec ten
years on. The canonical texts for my company are Jim Collins, built to last
where facing the brutal facts is considered one key to success.
My showstoppers are 1) the spec must be incrementally deployable in
large zones and 2) it must address the zone walking issue.
The reason you should care is that I am one of the very few members
of the security field who has an interest in this group. I am Principal
Scientist of the security division of company that has major influence in
the Security field. I also have personal influence, as the author of XKMS,
and co-editor of SAML and WS-Security I can help convince key constituencies
that they should buy in to DNSSEC.
The security community is not going to support a spec that
introduces a new security vulnerability that was not previously present and
introduces operational demands that threaten the stability of core DNS. As
the spec stands I cannot recommend it to my colleagues and in fact would
have to recommend that they do NOT deploy.
With an updated NSEC record that meets the showstopper objections I
describe I will be in a position to recommend DNSSEC. I believe that it is
even possible that with a small amount of appropriate preparation work it
might be possible that MARID and MARID accreditations could serve as a
'killer-app' for DNSSEC. One important political point here is that a MARID
accreditation service would be outside the control of ICANN. Remember that
killer-app means, the app which motivates building the infrastructure, not
necessarily the most important app the infrastructure will serve. Email was
not the Internet killer app, everyone had to be online before it had value,
but now everyone is online email is more important than the web.
Phill
Robert Elz
From: "Hallam-Baker, Phillip" <pba...@verisign.com>
Message-ID: <C6DDA43B91BFDA49AA2...@mou1wnexm05.vcorp.ad.vrsn.com>
| Roy is stating that this issue is a showstopper for him. Your proposal
| is in effect saying that the IETF, an organization with zero internal
| democracy and zero accountability should override European Union law
Don't be totally absurd. As Jaap already showed (after more research
than the topic deserved), the European laws have nothing whatever to do
with this. They're designed to protect the privacy of the individual,
who in this case, has given their domain name to the DNS operator to
publish - by request (or more likely, by contract, if the data weren't
published, there might be legal action involved).
Incidentally, nor does copyright, which has also been mentioned - in order
to get copyright protection, the item to be protected has to have been
published, which is exactly what the organisations that are objecting don't
want to do, they're trying to keep their list of names secret, which is
really the anthises of the whole purpose of the DNS.
If they were to publish it, they could get copyright protection, but as
they don't want that, they're resorting to all kinds of avenues to try
to keep the secret - which is, without doubt, difficult, or impossible.
kre
Hallam-Baker, Phillip
> more research
> than the topic deserved),
What I was objecting to was the assertion that regardless of
whether the law was applicable or not that 'layer 9' is out
of scope.
> the European laws have nothing
> whatever to do
> with this. They're designed to protect the privacy of the
> individual,
> who in this case, has given their domain name to the DNS operator to
> publish - by request (or more likely, by contract, if the data weren't
> published, there might be legal action involved).
The domain name is in many cases a personal identifier. The use
that the owner has authorized is publication of that data in
isolation. Privacy law has volumes of case law where a distinction
is made between isolated publication and publication of compilations.
> Incidentally, nor does copyright, which has also been
> mentioned - in order
> to get copyright protection, the item to be protected has to have been
> published, which is exactly what the organisations that are
> objecting don't
> want to do, they're trying to keep their list of names
> secret, which is
> really the anthises of the whole purpose of the DNS.
You are clearly not a lawyer, copyright has not required
publication since the ratification of the Berne convention
several decades ago.
Hallam-Baker, Phillip
> >
> > Here you just make the problem harder by an equal factor for
> > attacker and defender. That is not a core value here.
>
> more things than the defender. However, an asymmetric
> solution would be even nicer, I'll agree.
We have a dictionary corpus of n values and perform r iterations.
You are saing that the attacker has to perform n*r work units rather than
only n units and that this is sufficient value to justify increasing the per
lookup work function of client and server from 1 unit to r units.
I still don't see the value. We usually assume that an attacker is likely
to use hardware.
A dictionary attack is going to work in any situation where you can
perform individual lookups without restriction. That is not the attack
that causes real concern here. What I am concerned with is dictionary
discovery.
Paul Vixie
I'm Paul. He's Robert.
> --On 22 May 2004 13:53 +0700 Robert Elz <k...@munnari.OZ.AU> wrote:
> > ...
> > Don't be totally absurd. As Jaap already showed (after more research
> > than the topic deserved), the European laws have nothing whatever to do
> > with this ... Incidentally, nor does copyright, which has also
> > been mentioned - in order
>
> ...
> For me the point, however, isn't wholly about the law. It's about what
> stakeholders want. They do not want ccTLD operators publishing zonefiles.
> And ccTLD operators do not want to publish zonefiles. It appears the same
> might be true of VRSN. Current RFCs permit non-publication. ...
Have any of you here looked at <http://www.isc.org/ops/ds/>, perchance?
The thing that's boggling my mind at the moment is that the stakeholders,
or ccTLD operators, or VRSN, believes that by prohibiting zone transfers
they are preventing enumeration. It just ain't so, and while I'm still
Paul and he's still Robert and I can't authoritatively speak for him, I
suspect that Robert's use of the word "absurd" has to do with the general
misconception that preventing direct enumeration at the DNS protocol level
is actually buying anything for anybody.
> ... Whether or not all these people are unduly worried is to an extent
> a moot question, ...
No, it's not moot, not yet anyway. DNSSECbis as documented in the current
set of drafts and as implemented in BIND 9.3.0-beta4 has undergone
significant review and lab testing and appears ready for deployment. If
the DNS protocol development community is going to back away and redesign
it again, then two questions have to be answered first:
1. what exactly is it that you think you're going to get by making
the enumeration of your zones an indirect activity rather than
a direct one, noting that anyone who wants the enumeration can
get it by indirect data mining techniques...?
2. why are we doing this in May, when every other time that we've
pulled DNSSEC back for yet another redesign that's added one or
two years to the schedule, we've done it in December...?
> ... though personally I agree with Phillip Hallam-Baker's analysis
> that more information is revealed.
If he said that, he was wrong. More likely you misunderstood him. The
same information is revealed, it just happens slightly later and is an
indirect activity. Take a look at <http://www.isc.org/ops/ds/> before
you try to decide what's "finally and actually" revealed, no matter what.
(Noting that the ISC Domain Survey does not use or depend upon AXFR.)
Paul Vixie
> requirements of those deploying the protocol (ignoring, for a minute, why
> they have those requirements) appear occasionally to be only a secondary
> consideration in protocol design.
I apologize for the apparent truth of that reflection, but it's inaccurate.
SLD holders outnumber TLD holders by a factor of many millions. As an SLD
holder I can tell you that I do not fear enumeration as much as I fear
spoofing. There are a few SLD holders who hold the opposite view, just as
among TLD holders you will find both views.
When the "NO RR" was evaluated by the dnsext working group, these opposing
requirements were taken into account, and anti-enumeration lost out. I had
no dog in that race so this was only of academic interest to me -- "what
does BIND have to implement?" and "how can we get DNSSEC done in a decade?"
where my only concerns.
If the WG made the wrong choice and if DNSSEC is unimplementable because TLD
holders fear enumeration and so SLD holders will have secure path to the
root zone, then it appears that there's really no choice except to declare
failure. Perhaps Ohta or Bernstein would like to take a shot at the problem.
> I would suggest there is perhaps a positive correlation between on the
> one hand to the IETF listening to to the requirements of those who
> want to deploy a protocol on the one hand, and the protocol actually
> getting deployed on the other.
Many voices were heard. Primary among them were SLD holders, who either
don't care about enumeration, or who fear a two-decade approach to
DNSSEC even more, or who fear spoofing even more.
> In the context of a requirement to preserve existing functionlity, the
> fact that *you* think requirements are misplaced (I don't, but who
> knows, in the final analysis you might well be right) doesn't cut much
> mustard when the requirement comes from the internet community, as
> communicated to those who are going to make the deployment decision.
What *I* think, since you mentioned it, is that TLD holders who fear
enumeration think that restricting AXFR is actually preventing
enumeration, and that if they'd spend a few years in the trenches
against spammers and data miners they would come to the conclusion that
"all useful malevolent forms of enumeration are already possible and are
already being done" and would then conclude that a one-decade DNSSEC is
better than a two-decade DNSSEC, given that all other things are equal.
Jim Reid
This discussion is getting off-topic for this list which is supposed
to be about DNS protocol issues.
Alex> With respect Paul, I think you are handwaving. The wish to
Alex> have data published in response to a specific query is not
Alex> necessarily commensurate with the wish to have it published
Alex> under any circumstances whatsoever. Many people write
Alex> emails, and thus publish their email addresses. This does
Alex> not necessarily mean they want them compiled into lists of
Alex> email addresses, associated with other data, and sold as a
Alex> database.
With all respect, I think this is hand waving too. Anyone with half a
clue will realise that by publishing their email address, they have no
control over what others may do with that data. Even when there are
supposedly the safeguards of data protection and anti-spam legislation.
For instance, by responding to this mail I accept the risk that
someone may harvest my address and send me spam even though I don't
want them to do that. Going back to DNS, I doubt very much if anyone
registering a domain name in a TLD cares or even realises that the
whole TLD zone file might be available. Or not as the case may be.
They just want their domain name visible through the DNS protocol.
Alex> However, the problem goes beyond that. In this instance, in
Alex> my opinion, the law is merely a symptom of what people want.
A discussion about "what people want" is well off-topic for this list.
Alex> That's why we are concerned about protocol
Alex> changes which remove our ability to do protect zonefiles.
It's still not clear to me what those concerns actually are and why
traversing the zone file is such a worry. Maybe I'm just being more
stupid than usual. As Paul has pointed out, there are plenty of ways
of enumerating a TLD zone today, with or without some flavour of
DNSSEC, irrespective of whether zone transfers are possible. If the
concern is NSEC records makes whois disclosure easier, then fix whois:
that's where the personal data lives after all. That data isn't in the
DNS. If it's about copyright, the copyright holder's rights should
still apply. Just like record companies sell copyrighted material on
(copy-protected) CDs but are able to pursue anyone who illegally
duplicates that material.
In some respects, zone traversal might actually alleviate the concerns
of these TLDs. Suppose you put a delegation into the zone that doesn't
have a genuine whois entry or a registrar or end user. The delegated
zone has no web server or MX records so nothing other than the domain
name itself is ever published. And that's found by walking the NSEC
list. If this name pops up in your query logs, voila! The honey trap
has found someone who's up to no good and you can set your lawyers on
them.
Sal Mangiapane
> > This blatantly ignores the completely common case where
> > the set of recursive/caching/resolving nameservers for an
> > organization are separate from the set of authoritative
> > nameservers
These DNS servers can receive a trusted response but could not respond
to the originating request with a trusted (signed) answer.
They can't because they are unknown by authoritative nameservers.
I'm thinking they are outside the chain of trust.
What am I missing? Will these become obsolete?
Regards,
Sal
Salvatore Mangiapane
Ben Laurie
> Interesting.
>
> I am trying to work out the reason for the hash iterations.
>
>
> Let us call the set of names in the zone
> D = {d0, d1, d2, d3 ... dn}
>
> The problem is to be able to enumerate the inverse of the set
> D' = { ]d0-d1[, ]d1-d2[ ... ]dn-d0[ }
>
> It suffices to present one member of D' to prove that any given domain is
> not a member of D.
>
> To describe a member of D we simply specify dx, dx+1
>
>
> So what you are saying is that we do not need to deal with D, we can apply a
> one way function...
>
> HD = {H(d0), H(d1), ... H(dn) }
>
> HD' = { { ]H(d0)-H(d1)[, ]H(d1)-H(d2)[ ... ]H(dn)-H(d0)[ }
>
> So why do we need to specify more than H(dx), (H(dx+1)) ???
To increase the cost of dictionary attacks.
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
--
Marcos Sanz/Denic
> If I do not see rough consensus on taking up NSEC2 as a work item by
> June 1 I'll reject this as a work item.
Thanks to the chairs for hearing the voices of those stating they have a
deployment problem with the specification in its current form.
While it is true that DNSSec has a long and painful story tracking back to
10 years ago, that's plainly because the protocol itself isn't so easy as
thought in the beginning. I wouldn't like to see these kind of
retrospective arguments bound to the future of proposals to solve the NSEC
traversal.
Regards,
Marcos
Jim Reid
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.
--
Ben Laurie
> Paul Vixie wrote:
>
>>> 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'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.
>
>
> 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.
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.
"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
--
Alex Bligh
> i agree with ted. dns is a publication mechanism, and if you don't want
> something published you probably shouldn't be putting it into dns at all.
> and, if your only way to keep whois safe is to hide its index, then you
> have probably got other troubles. parts of the "index" are exposed every
> day in server logs or in-addr.arpa/ip6.arpa walks.
With respect Paul, I think you are handwaving. The wish to have data
published in response to a specific query is not necessarily commensurate
with the wish to have it published under any circumstances whatsoever.
Many people write emails, and thus publish their email addresses. This
does not necessarily mean they want them compiled into lists of email
addresses, associated with other data, and sold as a database.
Current DNS protocol and servers allow a granularity of policy decision on
what gets published, when, and to whom. The currently proposals for DNSSEC
would remove the ability of DNSSEC users to take advantage of that
granularity (i.e. they reduce current functionality that is in use, and
wanted, at least by a significant subset of users)
Whether or not making use of a function that prevents publication of entire
zone files is desirable is a policy question, and not a protocol question.
However, given that the current DNSSEC proposals remove functionality that
is in use (prevention of publication of entire zone files), it's worth a
few of lines describing why removal of that functionality is important.
The problem has been described as simply a legal problem. Whilst indeed
there are EU law considerations, I am aware that the IETF's approach to
legal problems in the past has often been "fix the law"; and indeed, often
rightly so.
However, the problem goes beyond that. In this instance, in my opinion, the
law is merely a symptom of what people want. RFC1591 talks about the local
internet community. In the UK, and the rest of the EU, people are perhaps
more sensitive to privacy issues than they seem to be in the US. Hence, if
you sign up for a phone here, you have the (legal) right to have your
number listed in directory enquiries, but not to have your name included in
a database of names and phone numbers sold to others by the phone company,
and indeed the phone company has an obligation not to distribute the data
for purposes other than those for which it collected it. That legal right
is based on widely held beliefs about privacy. I picked the phone book
example because it's the closest I could find to DNS. And there is a
strongly held local internet community (in an RFC1591 sense) views that
such privacy should continue to apply. See for instance item 8 at:
http://tinyurl.com/2l59u
I'm posting this rest of this message in a personal capacity, but as a
director of Nominet since it started, and a member of its policy advisory
board, I'll submit the following: the issue of zonefile protection has been
a very significant issue for stakeholders, and an issue on which we
(Nominet) have spent a considerable amount of time and money. And the
reason we've done this is not for narrow commercial advantage, but because
over the past years we've come to realize it's an important matter to the
local community. That's why we are concerned about protocol changes which
remove our ability to do protect zonefiles. My understanding is that
several other ccTLDs have the same concerns for similar reason.
Alex
Roy Badami
Alex> See for instance item 8 at: http://tinyurl.com/2l59u
And although Alex doesn't state this explicitly, the PAB minutes
available at the URL above seem to indicate that it is Nominet's
stated policy that zone file protection takes precedence over DNSSEC
deployment.
Which means for me (as an end user) that I won't be getting a secure
delegation of my .org.uk domain in the foreseeable future...
-roy
Alex Bligh
--On 21 May 2004 14:15 +0100 Roy Badami <r...@gnomon.org.uk> wrote:
> And although Alex doesn't state this explicitly, the PAB minutes
> available at the URL above seem to indicate that it is Nominet's
> stated policy that zone file protection takes precedence over DNSSEC
> deployment.
We are constrained by what is legal, and guided by what our stakeholders
want. Enumerable zonefiles seem to have problems on both grounds.
My assessment is that there is (perhaps wrongly) rather more stakeholder
interest in privacy aspects than DNSsec (to which the normal answer
is "what?").
> Which means for me (as an end user) that I won't be getting a secure
> delegation of my .org.uk domain in the foreseeable future...
This would depend in part on whether or not the problem is fixable or
workroundable via NSEC2 or some other way. Nominet would love to deploy it,
indeed it's been a strategic objective for over a year:
http://tinyurl.com/2mk8f
Alex
Roy Badami
Mark> But you can compile your own. I seem to remember a
Mark> court case here where OCR scanning of a existing directory
Mark> was illegal but getting a team of typists to re-enter all
Mark> the data in a existing directory was legal.
Hmm, I'm kind of surprised that even OCR was illegal in the US. But
there is a significant difference between UK and US copyright law in
this area. AIUI in US copyright law there is an exclusion from
copyright for a unique, canonical representation of a set of data. A
consistently formatted alphabeticised list of names and phone numbers
of all telephone users would hence fall into this category, since it
is not regarded as a creative work.
Many other jurisditions (certainly the UK) do not draw this
distinction.
-roy
Greg Hudson
> 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.
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.
Alex Bligh
--On 21 May 2004 15:11 +0100 Jim Reid <j...@rfc1035.com> wrote:
(with apologies for reodering)
>>>>>> "Alex" == Alex Bligh <al...@alex.org.uk> writes:
>
> This discussion is getting off-topic for this list which is supposed
> to be about DNS protocol issues.
...
> A discussion about "what people want" is well off-topic for this list.
The protocol issue at stake is the removal of a piece of functionality
(granularity in zonefile protection). I think you agree that much. Whether
or not removal of functionality is acceptable depends on the value of that
functionality. AIUI Your view (and Paul's) is that it is valueless, and
thus removing it doesn't matter. I find it hard to see how you can on the
one hand assert this, and on the other describe as off-topic those
attempting to explain to you the value they have. Functionality does not
exist in an abstract space. What people want from their protocols (what is
useful vs. useless functionality) surely drives what gets included and what
doesn't.
> For instance, by responding to this mail I accept the risk that
> someone may harvest my address and send me spam even though I don't
> want them to do that.
Yep. But I am guessing you wouldn't want psg.com as list operator
to be complicit in it.
> Going back to DNS, I doubt very much if anyone
> registering a domain name in a TLD cares or even realises that the
> whole TLD zone file might be available.
That isn't what they tell us.
> Alex> That's why we are concerned about protocol
> Alex> changes which remove our ability to do protect zonefiles.
>
> It's still not clear to me what those concerns actually are and why
> traversing the zone file is such a worry. Maybe I'm just being more
> stupid than usual. As Paul has pointed out, there are plenty of ways
> of enumerating a TLD zone today, with or without some flavour of
> DNSSEC, irrespective of whether zone transfers are possible.
Paul has asserted out that a third party can make a partial, non-shapshot,
list of TLD zonefile contents over months. I don't dispute that. If
I spent three months on it, I bet I could work out a way to steal
a substantial proportion of your possessions. That doesn't make it
either right, or legal, or desirable, for your landlord to decide that
there is thus little point in putting a lock on your door. Despite
the fact that "bad things happen", the zonefile operator does not need
to be complicit in it or make it easier.
> If the
> concern is NSEC records makes whois disclosure easier, then fix whois:
> that's where the personal data lives after all.
> If it's about copyright, the copyright holder's rights should
> still apply.
IANAL but the difference AIUI is that under the proposed protocol, one
would be publishing the compilation (in which separate copyright exists)
oneself.
However, I don't want to reduce this to a legal argument as for me, at
least, that's only one portion of the argument. The fact is (see
references) stateholders in certain ccTLDs do not wish the zonefile to be
published by the ccTLD operator.
> honey trap
Easy enough without DNSSEC.
Alex
Peter Koch
> 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
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
Peter Koch
Olaf Kolkman wrote:
> 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.
right, but if both keys are equally applicable a compromised "negative"
key (the one used for online signing) could be used to sign not only fake
negative responses but also fake DS RRs. The first can ``only'' be used
for DoS (leaving aside corner cases of DNS tree walking).
Whether this matters depends on whether one is willing to accept the risk.
Ben Laurie wrote:
> 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).
the advantage of "messing with NSEC" is that it's there while any new RR type
needs more work.
Alex Bligh
--On 21 May 2004 14:33 +0000 Paul Vixie <pa...@vix.com> wrote:
>> 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.
>
> 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
Jaap Akkerhuis
copy a directory because of that. For a zone file you can claim
this probably as well. That gives you a handle to whack people
making copies. We discussed this internally somewhat. We think
that IP-rights on a zone file is an interesting idea, but doesn't
prevent zone enumeration. It has more juridical aspects then
technical.
Back to (EU and other) pivacy concerns. Given the fact that there
are multiple ways to do data mining for domain names in a zone as
pointed out by Paul Vixie and Robert Elz, one really must take steps
to limit access to "whois data".
jaap
--
Mark Kosters
> Olaf,
>
> > If I do not see rough consensus on taking up NSEC2 as a work item by
> > June 1 I'll reject this as a work item.
>
> Thanks to the chairs for hearing the voices of those stating they have a
> deployment problem with the specification in its current form.
>
> While it is true that DNSSec has a long and painful story tracking back to
> 10 years ago, that's plainly because the protocol itself isn't so easy as
> thought in the beginning. I wouldn't like to see these kind of
> retrospective arguments bound to the future of proposals to solve the NSEC
> traversal.
I have mixed feelings about this.
Despite us having zones available to download (after signing an agreement
not to use this data in a harmful way), NSEC walking is going happen.
They will do this out of ignorance or malfeasance. Rate limiting will
be of some limited benefit but will not solve the issue.* What it does for us
is increase load on systems serving up responses that serve no purpose. Thus,
I would like to see some sort of way of reducing this behavior from occuring.
Also, registries have the convergence of protocol improvements, operational
realities, and political pressures. To that end, I sympathize with
other registries as they think about how to deploy this monster.
I hope that some of you who stomped your feet at Roy, Dave, and I over
opt-in would open your minds, listen and help solve this issue.
On the flip side, I too like to see dnssec deployed in the near future.
Unfortunately, it will not happen if the pain is worse than the gain.
Thanks,
Mark
* I think that the rate-limiting sentence should be taken out of the
intro draft - it will not work except in the most trivial cases.
--
Mark Kosters ma...@verisignlabs.com Verisign Applied Research
Alex Bligh
--On 21 May 2004 20:38 +0200 Jaap Akkerhuis <ja...@sidn.nl> wrote:
> For a zone file you can claim
> this probably as well. That gives you a handle to whack people
> making copies.
The (expensive, uncertain) legal "handle to whack people" doing something
unlawful is no substitute for stopping them doing it in the first place.
That's the same reason you have a lock on your front door despite laws
against theft, and (bring this back to a protocol level) the same reason we
promote strong encryption in protocols such as DNSSEC despite computer
crime and fraud laws. If we said in a more general case "we'll leave this
out the protocol and let them sort out the consequences in court" we might
as well not do DNSSEC, and just pay investigators and lawyers to go verify
whether DNS records are accurate and sue if not.
Whilst the legal point is interesting, my main argument is from a
functionality point of view.
Alex
Ben Laurie
>>>So why do we need to specify more than H(dx), (H(dx+1)) ???
>>
>>To increase the cost of dictionary attacks.
>
> questionable feature that will distract from the main value. Essentially all
> you are arguing for here is an expensive hash function.
>
> The valud of crypto is that you can introduce asymmetric attack
> costs. It is much harder for an attacker to break DES than it is for the
> defender to encrypt their message - 2^55.5 times as hard in fact. That is a
> real benefit.
>
> attacker and defender. That is not a core value here.
This is true, but neglects the fact that the attacker has to hash far
more things than the defender. However, an asymmetric solution would be
even nicer, I'll agree.
Cheers,
Ben.
Alex Bligh
--On 22 May 2004 13:53 +0700 Robert Elz <k...@munnari.OZ.AU> wrote:
> | Roy is stating that this issue is a showstopper for him. Your proposal
> | is in effect saying that the IETF, an organization with zero internal
> | democracy and zero accountability should override European Union law
>
> Don't be totally absurd. As Jaap already showed (after more research
> than the topic deserved), the European laws have nothing whatever to do
> with this ... Incidentally, nor does copyright, which has also
> been mentioned - in order
I'm not going to put privileged legal advice on list (drop me a note
off-list if you like) but suffice to say the old saw about ask two
different lawyers, get two different answers is all the more true in two
different jurisdictions.
For me the point, however, isn't wholly about the law. It's about what
stakeholders want. They do not want ccTLD operators publishing zonefiles.
And ccTLD operators do not want to publish zonefiles. It appears the same
might be true of VRSN. Current RFCs permit non-publication. The current
DNSsec proposal prohibits this. Whether or not all these people are unduly
worried is to an extent a moot question, though personally I agree with
Phillip Hallam-Baker's analysis that more information is revealed.
Alex
Roy Badami
Hallam-Baker,> Roy is stating that this issue is a showstopper for
Hallam-Baker,> him.
For the record, all I actually said that was that ccTLDs have raised
some concerns, and I disgreed with some of the sweeping arguments that
were being used against such possible concerns...
Though it appears now that Nominet have pretty much stated that this
is a showstopper for them...
-roy
sth...@nethelp.no
> > stakeholders want. They do not want ccTLD operators publishing zonefiles.
> > And ccTLD operators do not want to publish zonefiles. It appears the same
>
> Have any of you here looked at <http://www.isc.org/ops/ds/>, perchance?
>
> The thing that's boggling my mind at the moment is that the stakeholders,
> or ccTLD operators, or VRSN, believes that by prohibiting zone transfers
> they are preventing enumeration. It just ain't so, and while I'm still
> Paul and he's still Robert and I can't authoritatively speak for him, I
> suspect that Robert's use of the word "absurd" has to do with the general
> misconception that preventing direct enumeration at the DNS protocol level
> is actually buying anything for anybody.
With some knowledge of how the .no domain operates, I think it is fair
to say:
At least some stakeholders are fully aware of the fact that prohibiting
zone transfers does not prevent enumeration. However, they still find
it valuable to prevent zone transfers - the important point here being
the amount of work (and time) it takes to perform the enumeration: If a
domain can be enumerated in a month today, and could be enumerated in a
minute with NSEC (just to take an example), this is a dramatic reduction
in the amount of work needed - and a correspondingly lower barrier to
at least some undesirable uses of the domain data.
Steinar Haug, Nethelp consulting, sth...@nethelp.no
David Blacka
On May 22, 2004, at 11:07 AM, Paul Vixie wrote:
> The thing that's boggling my mind at the moment is that the
> stakeholders,
> or ccTLD operators, or VRSN, believes that by prohibiting zone
> transfers
> they are preventing enumeration. It just ain't so, and while I'm still
> Paul and he's still Robert and I can't authoritatively speak for him, I
> suspect that Robert's use of the word "absurd" has to do with the
> general
> misconception that preventing direct enumeration at the DNS protocol
> level
> is actually buying anything for anybody.
While I am in no way empowered to speak officially for VRSN, I will say
that VeriSign probably doesn't care terribly much about "preventing
enumeration", as you can download the zones yourself, if you care to.
From my point of view (speaking as an individual), I am more worried
about the operational impact of a bunch of knuckle-heads who decided to
suck down COM via a NSEC chain walk because either a) they don't know
they can just ftp the zone, b) they are too lazy to go through the
moderate hoops in order to do so, or c) the want to use the information
for something bad.
On the other hand, it is hard to say if this activity will result in
operational problems at all without a crystal ball.
--
David Blacka <dav...@verisignlabs.com>
Sr. Engineer Verisign Applied Research
Christian Huitema
> From my point of view (speaking as an individual), I am more worried
> about the operational impact of a bunch of knuckle-heads who decided
to
Basic rate limiting may not prevent enumeration, but it can certainly
mitigate the denial-of-service side-effect of such bone-headed behavior.
-- Christian Huitema
Hallam-Baker, Phillip
> > that more information is revealed.
>
> him. The same information is revealed, it just happens slightly
> later and is an indirect activity.
This shows why DNSEXT should transfer work on DNSSEC to the security
area.
From a security point of view more information IS revealled. The
computational difficulty of arriving at an enumeration is significantly
reduced with the DNSEXT. The alternative attack routes suggested
as equivalent are not.
Comparative security analysis is a VERY weak form of argument.
A huge number of security vulnerabilities result from faulty
comparative argument, in fact it is one of the most common causes
of security flaws. The errors in WEP were due to that type
of reasoning.
The IETF has a reputation for designing security mechanisms that
are so completely over-designed that they are undeployable, while
failing to meet security requirements considered critical by end
users. IPSEC refused to address NAT but created a negotiation
mechanism for key negotiation.
If you want anyone to use DNSSEC then you had better address the
requirements of the security community.
Phill
Hallam-Baker, Phillip
> From: owner-nam...@ops.ietf.org
> [mailto:owner-nam...@ops.ietf.org]On Behalf Of David Blacka
> While I am in no way empowered to speak officially for VRSN,
> I will say
> that VeriSign probably doesn't care terribly much about "preventing
> enumeration", as you can download the zones yourself, if you care to.
I am not speaking for VRSN here officially either.
Registry services may not have a position here.
Security Services is very likely to form one. Several proposed
anti-spam and anti-phishing measures use the DNS in a fashion
that could benefit from DNSSEC but not if doing so opened up
zone enumeration.
Hallam-Baker, Phillip
> millions. As an SLD
> holder I can tell you that I do not fear enumeration as much as I fear
> spoofing. There are a few SLD holders who hold the opposite
> view, just as
> among TLD holders you will find both views.
You are not typical of an SLD holder.
The community that has to be convinced here are the people who
operate corporate firewalls. If you do not have a firewall yet
you are not going to be interested in DNSSEC.
I speak to that communiuty on a regular basis. We actually operate
a lot of firewalls on an outsourced basis.
That community does not want to have people walk their domain
for very good reason. Dealling with attacks costs real money.
Allowing domain enumeration will cost these people real money
as it will mean that systems will be attacked which the attacker
would not otherwise have discovered.
> When the "NO RR" was evaluated by the dnsext working group,
> these opposing
> requirements were taken into account, and anti-enumeration
> lost out.
So did reality.
Agenda denial is not a very credible tactic. Demand for DNSSEC
is negligible. Give me the names of ten supporters of DNSSEC in
its current form who are influential in the security community.
Not only is the community of potential DNSSEC users not represented
in this group, any time someone does drop by to make a request
they get met with hostility and patronizing remarks.
> If the WG made the wrong choice and if DNSSEC is
> unimplementable because TLD
> holders fear enumeration and so SLD holders will have secure
> path to the
> root zone, then it appears that there's really no choice
> except to declare failure.
Ah my way or the high way eh?
> > I would suggest there is perhaps a positive correlation
> between on the
> > one hand to the IETF listening to to the requirements of those who
> > want to deploy a protocol on the one hand, and the protocol actually
> > getting deployed on the other.
>
> Many voices were heard. Primary among them were SLD holders,
> who either
> don't care about enumeration, or who fear a two-decade approach to
> DNSSEC even more, or who fear spoofing even more.
The requirement denial approach seems to be the main reason
for delay. DNSSEC would have been deployed already if OPTIN
had been accepted.
> What *I* think, since you mentioned it, is that TLD holders who fear
> enumeration think that restricting AXFR is actually preventing
The enumeration issue is going to be a much bigger issue at
the SLD level. In fact that is what the NSA guy said in a
DNSEXT meeting four years ago, for him enumeration is a real
issue.
The only reason this is taking so long is institutional. Over
a century of use has proved Roberts Rules of order to be a
much more effective way to run a meeting than the IETF has
devised. In OASIS we regularly complete specs much more
complex than DNSSEC within two years.
I suggest that the solution to this problem is to submit
a new draft that describes an OPT-IN and OBFUSCATED NXT
record as 'experimental'. The spam and phishing groups do
not care a jot over spec level issues but they do care
about deployability, the enumeration issue and who is
prepared to endorse the spec. It is also much more likely
that this application area will be a killer app for
DNSSEC than preventing spoofing. It has taken ten years
and a major spam crisis for people to realize that email
spoofing was a sufficiently bad thing that something should
be done about it.
Hallam-Baker, Phillip
> this "ostrich approach" is the one reason why I'd really like
> to see NSEC in its current form.
Nobody has yet specified an attack that has anything like the
effectiveness of zone walking.
> Zone walking/AXFR has nothing to do with end system security
> and "hiding" potential attack targets by AXFR blocks is
> dangerous at best.
You argument amounts to 'security through plain sight' which
is as discredited as security through obscurity.
The application of design arguments such as security through
obscurity and end-to-end to operations is a bad mistake. It
is even worse to turn that argument into an ideology and
attempt to ridicule those who say the ideology is false.
Please do not attempt to claim superior expertise in this area
again.
> What do these people do to make their IP adresses less
> guessable? Deploy IPv6?
Deployment of NAT for this purpose is near universal. The IETF
tried to fight that for years as well. I am aware of the
paper by Steve Bellovin on guessing IP addresses behind NAT,
as with your proposed dictionary attack it is orders of magnitude
harder and less reliable than direct observation.
> This is not what the thread was started for and this kind of
> "security" will
> distract from the real deployment issue here. The "registry
> type" zones are
> special and it's them we need a solution for.
Actually the same issue is true at the second level. Allowing
zone walking is not considered good security practice at any
level.