Subject: [DNSOP] Another TLD intending to sign soon

From: "Joe Baptista" <[email-masked]>
Date: Tue, 26 Aug 2008 13:03:01 -0400

On Tue, Aug 26, 2008 at 11:26 AM, Paul Hoffman <[email-masked]>wrote:

> <http://www.gcn.com/online/vol1_no1/46987-1.html>
>
> >Government agencies must take new measures by January 2009 to ensure
> >the Domain Name System security extensions on top level .gov Web
> >site domains are signed, and that processes for securing sub-domains
> >are developed, according to a memorandum released today by the White
> >House Office of Management and Budget. The top level .gov domain
> >includes the registrar, registry and DNS server operations.
> >
> >In addition, agencies must develop a plan of action and milestones
> >for deploying DNS Security extensions to "all applicable information
> >systems"; and "capabilities must be operational by December 2009,"
> >the memo said.

This will be a very interesting experiment.  And finally a good test of
DNSSEC.  Great for consultants.

cheers
joe baptista

-- 
Joe Baptista
www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive, Representative &
Accountable to the Internet community @large.
----------------------------------------------------------------
Office: +1 (360) 526-6077 (extension 052)
Fax: +1 (509) 479-0084
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Joe Baptista" <[email-masked]>
Date: Tue, 26 Aug 2008 13:03:01 -0400

cheers
joe baptista

---

From: Roy Arends <[email-masked]>
Date: Tue, 26 Aug 2008 19:10:32 +0200

On Aug 26, 2008, at 7:03 PM, Joe Baptista wrote:

> On Tue, Aug 26, 2008 at 11:26 AM, Paul Hoffman  
> <[email-masked]> wrote:
> This will be a very interesting experiment.  And finally a good test  
> of DNSSEC.  Great for consultants.

Why would this be experimental or test? Why 'finally'. This implies  
DNSSEC has not been deployed or been tested 'good' before.

Regards,

Roy

---

From: Roy Arends <[email-masked]>
Date: Tue, 26 Aug 2008 19:10:32 +0200

Regards,

Roy

---

From: Dean Anderson <[email-masked]>
Date: Tue, 26 Aug 2008 16:06:09 -0400 (EDT)

> DNSSEC has not been deployed or been tested 'good' before.

Has DNSSEC been thorough tested and analyzed? If so, where? When? By
who? How could their testing and analysis be considered 'thorough' or
credible when they didn't find the very serious flaws just recently
identified on this list?

But the memo on .gov probably means those of us with DNSSEC concerns
should write a letter to the author(s) of the memo.  Contact me offlist
for drafting and to sign the letter.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Dean Anderson <[email-masked]>
Date: Tue, 26 Aug 2008 16:06:09 -0400 (EDT)

--Dean

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Aug 2008 14:53:43 -0700

On Aug 26, 2008, at 1:06 PM, Dean Anderson wrote:
> How could their testing and analysis be considered 'thorough' or

To summarize, the two "flaws" to which you refer are:

   (1) there is no cryptographic defense against an attack where the  
attacker convinces the target that a zone that does not exist at all  
does exist.
   (2) replay attacks are possible during the lifetimes of zone  
signatures, which would either convince the target that a zone that  
has been removed still exists, or that a zone that has been added does  
not exist.

These are both known limitations that are explicitly mentioned in the  
protocol document, not oversights on the part of the protocol  
developers which have just been discovered by you.

If you had a problem with (1), you should have raised this back when  
the working group made this change.   At the time it seemed like a bad  
idea to me, but there were good reasons for doing it; what this  
limitation means is that your delegations aFrom [email-masked]  Tue Aug 26 14:53:47 2008
From: Ted Lemon <[email-masked]>
To: Dean Anderson <[email-masked]>
Date: Tue, 26 Aug 2008 14:53:43 -0700
Cc: "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] Another TLD intending to sign soon
Sender: [email-masked]

On Aug 26, 2008, at 1:06 PM, Dean Anderson wrote:
> How could their testing and analysis be considered 'thorough' or

To summarize, the two "flaws" to which you refer are:

   (1) there is no cryptographic defense against an attack where the  
attacker convinces the target that a zone that does not exist at all  
does exist.
   (2) replay attacks are possible during the lifetimes of zone  
signatures, which would either convince the target that a zone that  
has been removed still exists, or that a zone that has been added does  
not exist.

These are both known limitations that are explicitly mentioned in the  
protocol document, not oversights on the part of the protocol  
developers which have just been discovered by you.

If you had a problem with (1), you should have raised this back when  
the working group made this change.   At the time it seemed like a bad  
idea to me, but there were good reasons for doing it; what this  
limitation means is that your delegations arere not signed for free - if  
you want any security at all out of DNSSEC, you must sign your zone.

I don't see any way around (2), but would be interested in hearing any  
proposals you have.   Replay attacks are a problem in protocols with  
long-lived signatures, and this is one variable to take into account  
when choosing a zone signature lifetime.

Also, of course, if I have mischaracterized the limitations to which  
you refer, I would be interested in being corrected - are there any  
additional lies that can be told using the second flaw, for example?

 not signed for free - if  
you want any security at all out of DNSSEC, you must sign your zone.

I don't see any way around (2), but would be interested in hearing any  
proposals you have.   Replay attacks are a problem in protocols with  
long-lived signatures, and this is one variable to take into account  
when choosing a zone signature lifetime.

Also, of course, if I have mischaracterized the limitations to which  
you refer, I would be interested in being corrected - are there any  
additional lies that can be told using the second flaw, for example?

---

From: "Joe Baptista" <[email-masked]>
Date: Tue, 26 Aug 2008 23:13:55 -0400

On Tue, Aug 26, 2008 at 1:10 PM, Roy Arends <[email-masked]> wrote:

> Why would this be experimental or test? Why 'finally'. This implies DNSSEC
> has not been deployed or been tested 'good' before.

It hasn't.  And anyone who thinks it has is living in la la land.  I think
it will be a good test because .gov domain holders will be forced to give it
a try.  There is no other TLD operator with the power to enforce a
transition to DNSSEC of all domains like this will.  I wish them luck and
look forward to the results of this modest experiment.

regards
joe baptista

Joe Baptista
www.publicroot.org
PublicRoot Consortium

---

From: "Joe Baptista" <[email-masked]>
Date: Tue, 26 Aug 2008 23:13:55 -0400

regards
joe baptista

Joe Baptista
www.publicroot.org
PublicRoot Consortium

---

From: Dean Anderson <[email-masked]>
Date: Wed, 27 Aug 2008 18:45:26 -0400 (EDT)

> To summarize, the two "flaws" to which you refer are:

I'm not sure I agree with your summary of the NSEC/NSEC3 issues. I'll
mostly ignore your summary for now and just note that there are a number
of other serious flaws.

3. Ordinary cache poisoning still possible in DNSSEC-aware non-verifying
caches, resulting in a DOS.

4. Crypto-overload DOS attack on verifying caches.

5. New, hard to mitigate, DDOS attack using forged DNSSEC queries to
roots, TLDs, large domains with an amplification factor near 100:1.

I'm still looking into the private key recovery issue. I'll try to 
finish that up tonight.

Some comments on incorrect assertions on the NSEC/NSEC3 attacks.

> (1) [...] what this  
> limitation means is that your delegations are not signed for free - if  

One cannot sign zones that don't exist. The NSEC/NSEC3 exploit allows 
one to create zones that don't exist. The end-user can't dFrom [email-masked]  Wed Aug 27 15:46:22 2008
Date: Wed, 27 Aug 2008 18:45:26 -0400 (EDT)
From: Dean Anderson <[email-masked]>
To: Ted Lemon <[email-masked]>
Cc: "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] Another TLD intending to sign soon
Sender: [email-masked]

> To summarize, the two "flaws" to which you refer are:

I'm not sure I agree with your summary of the NSEC/NSEC3 issues. I'll
mostly ignore your summary for now and just note that there are a number
of other serious flaws.

3. Ordinary cache poisoning still possible in DNSSEC-aware non-verifying
caches, resulting in a DOS.

4. Crypto-overload DOS attack on verifying caches.

5. New, hard to mitigate, DDOS attack using forged DNSSEC queries to
roots, TLDs, large domains with an amplification factor near 100:1.

I'm still looking into the private key recovery issue. I'll try to 
finish that up tonight.

Some comments on incorrect assertions on the NSEC/NSEC3 attacks.

> (1) [...] what this  
> limitation means is that your delegations are not signed for free - if  

One cannot sign zones that don't exist. The NSEC/NSEC3 exploit allows 
one to create zones that don't exist. The end-user can't determine that 
they don't really exist.

> when choosing a zone signature lifetime.

The first thing is to quit telling people that DNSSEC is secure. It
isn't.  One merely does different things (set the DO bit, craft a
response with DNSSEC RRs, etc) to obtain the same objectives as before.

I also propose to obsolete RFC4033, 4034, 4035 and remove the type codes
for DNSKEY, DS, RRSIG, NSEC RR types.

> additional lies that can be told using the second flaw, for example?

The sky is the limit.  Since the zone appears not to exist by (2), it
can be made to exist using (1).  That's also cache poisoning by any 
other name.

		--Dean

etermine that 
they don't really exist.

> when choosing a zone signature lifetime.

The first thing is to quit telling people that DNSSEC is secure. It
isn't.  One merely does different things (set the DO bit, craft a
response with DNSSEC RRs, etc) to obtain the same objectives as before.

I also propose to obsolete RFC4033, 4034, 4035 and remove the type codes
for DNSKEY, DS, RRSIG, NSEC RR types.

> additional lies that can be told using the second flaw, for example?

The sky is the limit.  Since the zone appears not to exist by (2), it
can be made to exist using (1).  That's also cache poisoning by any 
other name.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 27 Aug 2008 19:14:48 -0400 (EDT)

On Tue, 26 Aug 2008, Ted Lemon wrote:

> the working group made this change.   

The above criticism is an entirely disingenuous comment. Mr Lemon has
previously been made aware that critics of DNSSEC were silenced on
DNSEXT WG on false and fictitious pretenses that were made in bad faith
and with undisclosed conflict of interest; the purpose and result were
deception of the Working Group and the public.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 27 Aug 2008 19:14:48 -0400 (EDT)

--Dean

---

From: Ted Lemon <[email-masked]>
Date: Wed, 27 Aug 2008 17:46:44 -0700

> mostly ignore your summary for now and just note that there are a  

It's hard to take a statement like this seriously when it's not backed  
up by some clarity as to what's being said.   If there are other  
serious flaws, let's hear about them.

> caches, resulting in a DOS.

Right, we know about that, and what to do about it.

> 4. Crypto-overload DOS attack on verifying caches.

We know about this also, and know what to do about it.

> roots, TLDs, large domains with an amplification factor near 100:1.

Details?   Are you referring to the fact that a DNSSEC lookup looks up  
more RRsets than a PODS lookup?   Is there a situation where all these  
lookups hit the same server?

_______________________________________________
DNSOP mailing list
[email-masked]
https:From [email-masked]  Wed Aug 27 17:47:10 2008
From: Ted Lemon <[email-masked]>
To: Dean Anderson <[email-masked]>
Date: Wed, 27 Aug 2008 17:46:44 -0700
Cc: "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] Another TLD intending to sign soon
Sender: [email-masked]

> mostly ignore your summary for now and just note that there are a  

It's hard to take a statement like this seriously when it's not backed  
up by some clarity as to what's being said.   If there are other  
serious flaws, let's hear about them.

> caches, resulting in a DOS.

Right, we know about that, and what to do about it.

> 4. Crypto-overload DOS attack on verifying caches.

We know about this also, and know what to do about it.

> roots, TLDs, large domains with an amplification factor near 100:1.

Details?   Are you referring to the fact that a DNSSEC lookup looks up  
more RRsets than a PODS lookup?   Is there a situation where all these  
lookups hit the same server?

_______________________________________________
DNSOP mailing list
[email-masked]
https:////www.ietf.org/mailman/listinfo/dnsop

www.ietf.org/mailman/listinfo/dnsop

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Aug 2008 10:54:16 +1000

> > attacker convinces the target that a zone that does not exist at all  

	It is not possible to do this with NSEC.  Names either exist
	or they don't exist.

	It is a risk you accept when you choose to use NSEC3 and
	results from a collision of SHA1 hashes.  However for it
	to be effective the original delegation would also have to
	be a insecure delegation.

	A secure delegation has a DS RRset and for that to be
	effective you also need to find a DNSKEY who's SHA1 matches
	a DS record at the delegation.

	For delegation centric zones like COM you are unlikely to
	find a insecure delegation as they will be using OPTOUT
	to skip all insecure delegations.

	For end user sites trying to prevent zone working finding
	all the names in the zone you are unlikly to find a insecure
	delegation.

	Now if you believe in infinite improbability drives then
	you need to worry.  Otherwise there really isn't a practical
	attack here.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Aug 2008 10:54:16 +1000