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

Wes Hardaker <wjhns1@hardakers.net> Wed, 11 May 2011 14:14 UTC

Return-Path: <wjhns1@hardakers.net>
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 6C903E069E for <dnsext@ietfa.amsl.com>; Wed, 11 May 2011 07:14:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 sDzgMne+6+02 for <dnsext@ietfa.amsl.com>; Wed, 11 May 2011 07:14:02 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id B4217E0685 for <dnsext@ietf.org>; Wed, 11 May 2011 07:14:02 -0700 (PDT)
Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id D56AD273; Wed, 11 May 2011 07:13:30 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
References: <20110511080159.GA13132@nic.fr>
Date: Wed, 11 May 2011 07:13:30 -0700
In-Reply-To: <20110511080159.GA13132@nic.fr> (Stephane Bortzmeyer's message of "Wed, 11 May 2011 10:01:59 +0200")
Message-ID: <sdfwolcol1.fsf@wjh.hardakers.net>
User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Cc: dnsext@ietf.org
Subject: Re: [dnsext] dnsextDNSSEC, 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:14:03 -0000

>>>>> On Wed, 11 May 2011 10:01:59 +0200, Stephane Bortzmeyer <bortzmeyer@nic.fr> said:

SB> But it seems there is an "exception". RFC 4509, section 3, says that
SB> DS hashed with SHA-1 must be ignored when there is a DS for the same
SB> key hashed with SHA-2. This is to avoid downgrade attacks.

Well, the reasons the WG decided to go that route at the time was there
is no way to ensure better security if you want better security and your
client is capable of it.  That last part of the sentence is the key (ha
ha) to understanding the real problem.

There is no signaling bit, from the publisher, to say that you want
people to only use the SHA256 record.  Thus, the RFC specifies this
policy as the default: "Validator implementations SHOULD ignore DS RRs
containing SHA-1 digests if DS RRs with SHA-256 digests are present in
the DS RRset."  Because there is no signaling bit, we end up in three
cases:

1) The zone publisher doesn't care which record is used.  Currently this isn't
   possible.

   * A SHA1 record exists
   * A SHA256 record exists

   Right now, the above SHOULD indicates you should only use the SHA256
   if you understand the SHA256.

2) The zone publisher *wants* everyone to upgrade, but cares about the clients
   that don't understand a SHA256 DS yet.

   * A SHA1 record exists
   * A SHA256 record exists

   This is the case the WG deemed more important than case 1.  Thus, the
   document STRONGLY ENCOURAGES people to only use the SHA256 record if
   they can understand it.

3) The zone publisher *requires* everyone to upgrade, but cares about
   the clients that don't understand a SHA256 DS yet.

   * A SHA256 record exists

   That's really the only bit that zone publishers can control: publish
   the SHA1 record or not?

If there was a way to publish the SHA1 record *and* a bit that said "use
anything you understand" this would be easier.  But there isn't a way to
do that.

So we need to pick, in the document, between which is more important: #1
or #2.  We picked #2.
-- 
Wes Hardaker
Cobham Analytic Solutions