Re: [dnsext] DS digest downgrade

Wes Hardaker <wjhns1@hardakers.net> Tue, 22 March 2011 14:21 UTC

Return-Path: <wjhns1@hardakers.net>
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 5370A28C12B for <dnsext@core3.amsl.com>; Tue, 22 Mar 2011 07:21:07 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uplE4RNs9Kau for <dnsext@core3.amsl.com>; Tue, 22 Mar 2011 07:20:56 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 4200428C11D for <dnsext@ietf.org>; Tue, 22 Mar 2011 07:20:56 -0700 (PDT)
Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 5F06C21901; Tue, 22 Mar 2011 07:22:08 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: George Barwood <george.barwood@blueyonder.co.uk>
References: <AB3F9CFB9B6948139A2BE01269B399D5@local> <20110321222521.83729D084D9@drugs.dv.isc.org> <51C21B4C57014630B72B50B919271C89@local>
Date: Tue, 22 Mar 2011 07:22:02 -0700
In-Reply-To: <51C21B4C57014630B72B50B919271C89@local> (George Barwood's message of "Mon, 21 Mar 2011 23:13:00 -0000")
Message-ID: <sdr59zutf9.fsf@wjh.hardakers.net>
User-Agent: Gnus/5.110012 (No Gnus v0.12) Emacs/23.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
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: Tue, 22 Mar 2011 14:21:08 -0000

>>>>> On Mon, 21 Mar 2011 23:13:00 -0000, "George Barwood" <george.barwood@blueyonder.co.uk> said:

GB> I think that RFC 4509 could have pointed out the subtle implications
GB> for the uniform generation of DS records. There might be some risk
GB> that an administrator fails to publish a required DS record (
GB> possibly due to some parent constraint on the total size of the DS
GB> RRset ).

We deliberately stayed away from best-practices in the text because if
we went down that road it never would have been published :-/

You're right that this sort of discussion is needed somewhere, but as
others have pointed out there will/could be more and more algorthims for
more and more parts of the protocol and this situation (and transitions)
should be discussed in a single document, not in each individual one.
[though it would have been nice to refer to one]

What's worse, it takes careful coordination with your parent.

Consider the case where:

T+0: example.tld adds a new key
T+1: example.tld sends a SHA1 DS record to the parent
T+2: tld publishes the new DS
T+3: someone queries for the example.tld DS and gets a DS record set
     with the SHA1 DS for the new key.  And a TTL picked by ???
     [multiple options exist here].
T+4: example.tld sends a SHA256 DS record to the parent
T+5: tld publishes the new DS

If a parent only allows updating of a single DS record at a time, the
time between T+1 and T+5 could actually be on the order of seconds even,
but there is a time gap.  The whole process needs to document
parent/child relationships too, and the fact that the recommended
interface between the parent and child SHOULD accept multiple algorithms
simultaneously to prevent situations like the above.  So the advice to
the child gets even longer and more winded: if your parent only accepts
one record at a time, please publish the SHA256 first if you value
security.  Or SHA1 first if you value widest-interoperability (which I
actually doubt as I suspect everything? works with SHA256 now or won't
work at all in the first place, since SHA256 predates the NSEC3 records
which are now in such wide-spread use that you're chances of being
highly successful on the internet with SHA256 but no NSEC3 is unlikely).

As you can see...  it isn't a short bit of text that is needed.
-- 
Wes Hardaker
Cobham Analytic Solutions