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

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 11 May 2011 14:28 UTC

Return-Path: <brian.peter.dickson@gmail.com>
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 EB5CBE07B6 for <dnsext@ietfa.amsl.com>; Wed, 11 May 2011 07:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 t1y8hZgxbwkj for <dnsext@ietfa.amsl.com>; Wed, 11 May 2011 07:28:36 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id A4AB6E0703 for <dnsext@ietf.org>; Wed, 11 May 2011 07:28:35 -0700 (PDT)
Received: by fxm15 with SMTP id 15so494197fxm.31 for <dnsext@ietf.org>; Wed, 11 May 2011 07:28:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0Q/4eTeVQ0UnbVORur8TAQVRw3QuzKaLKYB9d8qBI7A=; b=LqXn39d+nWB6O+Ui/cOn99OAE+/oPPoVwgq/WM3c3GEH3VTQilV5pKa+FVNKZi4r0D 4sCI21WD9mPCiZhVCsuhd6Zv95aRMfYvl2evC5yS9PZHU0tzM1V2XFtBbNm0Z8jRnq1K U1WDUlOeAQPVRfTwWVhLm/weXScpvW2/787CQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wbQfgIwDxUwoO9R+e8t6nUQFCTN/KfsN01Ja5nRWn9NLQ0sKahl2JxiVjnNid+GHVI hcCGwib+DIEat0/zkZFbocdk8DyFGgfZV+MOHk+fvpNBBS2A4u//HH41/5lmBGeyxzDR TzSAta2hmd1A4B78DXK7LeP5LZ1i/G1pixCd0=
MIME-Version: 1.0
Received: by 10.223.29.132 with SMTP id q4mr728569fac.17.1305124113058; Wed, 11 May 2011 07:28:33 -0700 (PDT)
Received: by 10.223.120.133 with HTTP; Wed, 11 May 2011 07:28:33 -0700 (PDT)
In-Reply-To: <20110511080159.GA13132@nic.fr>
References: <20110511080159.GA13132@nic.fr>
Date: Wed, 11 May 2011 10:28:33 -0400
Message-ID: <BANLkTi=akoM6k+fsY-uM7m46L-ihA2JggA@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Content-Type: multipart/alternative; boundary=001517478f04258f3d04a300e3c6
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 14:28:37 -0000

Here's my take on it:

The attack for which the order matters (SHA-256 vs SHA-1) is a forged
DNSKEY, if I understand things correctly.
The DS records are signed as a single RRSET, so it is in theory impossible
to downgrade by blocking one of the DS records, unless you can forge an
RRSIG, in which case you're dead in the water anyway.

And, the "forged DNSKEY" attack can only succeed if the DS for SHA-1 is
used. By "forged", we mean a hash-colliding DNSKEY whose private keys we
know. Hash-colliding is hash-specific, so only one DS can be spoofed at a
time.

If DS records using SHA-256 and SHA-1 are both present and valid, using
SHA-256 makes the attack fail.

If only SHA-1 is present, the attack will succeed.

(Again, this is mostly hypothetical, as I understand it, i.e. that a forged
SHA-1 has not been demonstrated, as far as I know, which may not be very
far. ;-))

I would interpret the rule of (SHA-256 over SHA-1) as using the following
method:
(1) Take all your DS records, in whatever order they were returned or in
whatever order your local policy says to prefer them.
(2) If SHA-1 occurs before SHA-256 in the list, move SHA-1 or SHA-256 so
that their relative position in the list is swapped, i.e. that SHA-256
occurs before SHA-1.
(3) Go down the list, and attempt to validate the DNSKEY. Stop when you
succeed. If you fail all (fall through the end of the list), mark the zone
as (whatever is correct for this condition - bogus?)

While it is potentially susceptible to attack, it is still technically
secure.

Given that the data is likely to be present on all authoritative servers for
the zone, SERVFAIL is definitely not a good answer, IMHO.

And, if both SHA-256 and SHA-1 are present *and valid*, the downgrade is
prevented.

Brian

On Wed, May 11, 2011 at 4:01 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr>wrote;wrote:

> A recent incident lead me to re-study the question of "what a
> validating resolver must/should do when there are several DS and some
> are invalid in some way?" AFAIK (I would be glad to be corrected
> here), the best common practice is to be lax ("DNSSEC is hard enough,
> accept any DS"), following RFC 4035, section 2.4 and 5.3.1.
>
> 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.
>
> In the incident I was talking about, there were two DS for the same
> KSK key, one hashed with SHA-1 and one with SHA-256 and the second one
> was invalid, because of a bug (wrong Algorithm field). As a result,
> both BIND and Unbound, following RFC 4509, returned a SERVFAIL, while
> there was another and perfectly valid DS record.
>
> 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)?
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext
>