[dnsext] DS digest downgrade

"George Barwood" <george.barwood@blueyonder.co.uk> Mon, 21 March 2011 21:23 UTC

Return-Path: <george.barwood@blueyonder.co.uk>
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 8EDCB3A68D7 for <dnsext@core3.amsl.com>; Mon, 21 Mar 2011 14:23:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.873
X-Spam-Level: *
X-Spam-Status: No, score=1.873 tagged_above=-999 required=5 tests=[AWL=-1.136, BAYES_40=-0.185, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753]
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 SRLeHlYqbfJi for <dnsext@core3.amsl.com>; Mon, 21 Mar 2011 14:23:43 -0700 (PDT)
Received: from smtp-out4.blueyonder.co.uk (smtp-out4.blueyonder.co.uk [195.188.213.7]) by core3.amsl.com (Postfix) with ESMTP id B6AC33A68D6 for <dnsext@ietf.org>; Mon, 21 Mar 2011 14:23:43 -0700 (PDT)
Received: from [172.23.170.136] (helo=anti-virus01-07) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1Q1mbD-0000G1-8q for dnsext@ietf.org; Mon, 21 Mar 2011 21:25:15 +0000
Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out3.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from <george.barwood@blueyonder.co.uk>) id 1Q1mb2-0008SV-Rq for dnsext@ietf.org; Mon, 21 Mar 2011 21:25:04 +0000
Message-ID: <AB3F9CFB9B6948139A2BE01269B399D5@local>
From: George Barwood <george.barwood@blueyonder.co.uk>
To: dnsext@ietf.org
Date: Mon, 21 Mar 2011 21:25:28 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994
Subject: [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: Mon, 21 Mar 2011 21:23:44 -0000

Via the dane group, I just realised that if DS records are provided for both SHA1 and SHA256, no extra security is obtained over using just SHA1.

That's because the SHA256 DS record could be for an unpublished DNSKEY in the child that happens to have the same Key Tag, so the verifier has to try the SHA1 digest if the SHA256 verification fails.

This seems unfortunate. You could have a rule that states that if SHA256 is used, it must be used "uniformly" ( or at least for all keys with the same algorithm and Key Tag ).

The alternative is to just not use SHA1 I suppose.

But this does seem like a design flaw, it's an obstacle for upgrading to better digest algorithms (SHA3?) if/when the current ones prove weak.

Was this ever discussed?

George