Re: [dnsext] DS digest downgrade

Mark Andrews <marka@isc.org> Thu, 24 March 2011 03:50 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 564823A67E1 for <dnsext@core3.amsl.com>; Wed, 23 Mar 2011 20:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIUajC3KnI27 for <dnsext@core3.amsl.com>; Wed, 23 Mar 2011 20:50:06 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 2482A3A67DF for <dnsext@ietf.org>; Wed, 23 Mar 2011 20:50:06 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 7665CC9423; Thu, 24 Mar 2011 03:51:33 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id ED058216C22; Thu, 24 Mar 2011 03:51:32 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 50B9AD2F6ED; Thu, 24 Mar 2011 14:51:28 +1100 (EST)
To: Matt McCutchen <matt@mattmccutchen.net>
From: Mark Andrews <marka@isc.org>
References: <1300934885.2117.219.camel@localhost>
In-reply-to: Your message of "Wed, 23 Mar 2011 22:48:05 EDT." <1300934885.2117.219.camel@localhost>
Date: Thu, 24 Mar 2011 14:51:28 +1100
Message-Id: <20110324035128.50B9AD2F6ED@drugs.dv.isc.org>
Cc: dnsext@ietf.org
Subject: Re: [dnsext] DS digest downgrade
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 24 Mar 2011 03:50:16 -0000

In message <1300934885.2117.219.camel@localhost>, Matt McCutchen writes:
> [Note, I made the initial allegation of this issue in the dane/keyassure
> group.]
> 
> On Mon, 2011-23-21 at 23:13 -0000, George Barwood wrote:
> > Ok, I see it now, section 3
> > 
> >    Validator implementations SHOULD ignore DS RRs containing SHA-1
> >    digests if DS RRs with SHA-256 digests are present in the DS RRset.
> 
> I wasn't aware of this.  I did not think to check the specifications of
> individual algorithms; I would have expected a specification that
> modifies the validation requirements like this to update RFC 4035.  I
> have submitted an erratum to this effect.
> 
> Ad-hoc SHOULD-level statements for validators are no way to achieve a
> fundamental security property, and leaving the implications for the DNS
> administrator as an exercise to the reader is no way to achieve
> interoperability.  In my view, the issue cannot be considered resolved
> until there is a single document that states the uniformity requirement
> for DS records and a MUST-level requirement for validators in an
> algorithm-general way.

The time you get a failure is if there are differing DS algorithm
sets for the same DNSKEY algorithm and you are pre-publishing DS
and the pre-published DS has a SHA256 DS when the current DS for
that algorithm doesn't have a SHA256 DS but has a SHA1 DS.  This
will leave you with a SHA256 DS pointing to a non-existing DNSKEY.

If one is not pre-publishing DS records I don't see a failure case.
Treating the zone as insecure is not a failure.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org