Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16

[Samuel Weiler <[e-mail]>]

On Fri, 27 Jan 2012, Mohan Parthasarathy wrote:

> - Section 4.4 Insecure Delegation proofs last sentence is very
> confusing. An example as to what attack this is describing would be
> helpful to the implementer.

Here's an example of the attack we're trying to avoid.  Consider a 
signed zone that contains the names:
   alfa.example.com.
and
   bravo.alfa.example.com.

alfa.example.com is NOT a delegation.  Instead, it has this NSEC 
record:

 	alfa.example.com. 86400 IN NSEC host.example.com. (
 		A MX RRSIG NSEC TYPE1234 )

The quesion is: could an attacker use this NSEC record in reply to a 
query for bravo.alfa.example.com, replying with either a spoofed 
bravo.alfa.example.com or even claiming the name doesn't exist?  Under 
the old rules, read literally, that attack would work: the NSEC does 
not have a DS or SOA bit.  It also does not have an NS bit, but the 
rules did not say to check for that.

The forthcoming -17 has that section somewhat reworked.  There still 
is no example in.  Let us know if you really want that.

(note: the error is also broken, since bravo.alfa.example.com sorts 
before host.example.com.  maybe there are multiple ways to catch this 
attack.)

> - The "Security Considerations" section says:
>
>     This document adds two cryptographic features to the core DNSSEC protocol.
>
>    Is this referring to the algorithms mentioned in section 2.2 (
> which actually lists three)  or something else ?

clarified.

-- Sam