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

Edward Lewis <Ed.Lewis@neustar.biz> Wed, 11 May 2011 13:57 UTC

Return-Path: <Ed.Lewis@neustar.biz>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E90AE0685 for <dnsext@ietfa.amsl.com>; Wed, 11 May 2011 06:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmEwZi9Aqlpw for <dnsext@ietfa.amsl.com>; Wed, 11 May 2011 06:57:45 -0700 (PDT)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 48D19E0725 for <dnsext@ietf.org>; Wed, 11 May 2011 06:57:38 -0700 (PDT)
Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p4BDvZKI090889; Wed, 11 May 2011 09:57:35 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz)
Received: from [10.31.203.215] by Work-Laptop-2.local (PGP Universal service); Wed, 11 May 2011 09:57:36 -0400
X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 11 May 2011 09:57:36 -0400
Mime-Version: 1.0
Message-Id: <a06240801c9f04404083f@[10.31.203.215]>
In-Reply-To: <20110511080159.GA13132@nic.fr>
References: <20110511080159.GA13132@nic.fr>
Date: Wed, 11 May 2011 09:57:32 -0400
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
From: Edward Lewis <Ed.Lewis@neustar.biz>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4
Cc: dnsext@ietf.org
Subject: Re: [dnsext] DNSSEC, robustness, and several DS records
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 May 2011 13:57:46 -0000

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 +1-571-434-5468

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