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

["Blacka, David" <[e-mail]>]

On Mar 12, 2012, at 3:41 PM, Samuel Weiler 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.

Actually, the question is: could an attacker use this NSEC record to spoof away actual signed records for alfa.example.com.  The attacker could return:

  ANSWER:
  AUTHORITY:
     alfa.example.com IN NS my.bad.server.
     alfa.example.com IN NS my.other.bad.server.
     alfa.example.com IN NSEC bravo.alfa.example.com A MX RRSIG NSEC TYPE1234
     alfa.example.com IN RRSIG NSEC …
  ADDITIONAL:
     ...

This looks superficially like a normal insecure delegation.  The NSEC record verifies and proves that there is no DS RRset.  The attacker then, on my.bad.server, can return whatever it likes for alfa.example.com A, or other types.

Thus, 4.4 says that you MUST check that the NS bit is set.

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

--
David Blacka                          <[e-mail]> 
Principal               Verisign Infrastructure Engineering

_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext