Re: [dnsext] DNSSEC, robustness, and several DS records

[Edward Lewis <[e-mail]>]

At 10:01 +0200 5/11/11, Stephane Bortzmeyer wrote:

>But it seems there is an "exception". RFC 4509, section 3, says that
>DS hashed with SHA-1 must be ignored when there is a DS for the same
>key hashed with SHA-2. This is to avoid downgrade attacks.
...
>I question this rule: SHA-1 (as it is used for DNSSEC) is not broken
>and the risk of downgrade attacks is ridiculous when you compare, both
>to the other attacks on DNSSEC, and to the risk of creating an
>error. Isn't it a case of excess security, which will turn people away
>from DNSSEC (too much risk of breakage)?

I gave this rule some thought too in the past couple of days, for the 
same reason.  I was never a fan of the rule but paid it no mind.  Now 
I think it is yet another example of a kink in the pipes that might 
eventually come back to haunt us.

The overriding policy is still "local policy rules."  It is fine for 
the document to say to implementers and deployers that if there is a 
choice between SHA-1 and SHA-2, prefer the latter because it is 
generally better.  "Generally" means that it is possible an operator 
could mess up the SHA-2 record (not the hash, the record).

Looking at other examples of this kind of preference, IPv6 over Ipv4, 
we see that sometimes promoting a new technology over an old can 
backfire in the transition phase.  More and more I think it is a 
mistake to bias a standard to one approach over another, instead, 
just inform the interested parties in the trade-offs.  If the 
underlying code is neutral, then we can adjust operations around 
changes in conventional wisdom.  Once we cement in a particular 
choice we are stuck.

Another set of principles I'd repeat - DNSSEC is a first line of 
defense, not a last line, meaning it's in the infrastructure and not 
the application.  DNSSEC has to be liberal because the impacts of a 
false positive are large and hidden under layers of code and GUIs. 
DNSSEC is to protect the cache and it is up to the cache operator to 
decide how to protect itself.  And the crypto-problem we are tackling 
is a subset of the general problem, a lot of the attacks (like 
downgrades) are just not all that realistic in the confines of DNS. 
DNS isn't immune, but the opportunities for a successful attack are 
limited.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at [phone]

Now, don't say I'm always complaining.
Wait, that's a complaint, isn't it?