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

[Mohan Parthasarathy <[e-mail]>]

On Mon, Mar 12, 2012 at 12:41 PM, Samuel Weiler <[e-mail]> wrote:
> 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.
>
When proving that the delegation is not secure (which is what this
section is talking about), the NSEC record has to match the name that
is being looked up. If the names don't match, then it can't be a
delegation. David's response clarified this.

> The forthcoming -17 has that section somewhat reworked.  There still is no
> example in.  Let us know if you really want that.
>
This is the new text:

   Without this check, an attacker could reuse an NSEC or NSEC3 RR
   matching a non-delegation name to spoof an unsigned delegation at
   that name.  This would claim that an existing signed RRset (or set of
   signed RRsets) is below an unsigned delegation, thus not signed and
   vulnerable to further attack.

Though the text is improved, it is easy to understand if you read this
text along with the example.

-mohan

> (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
>
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext