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
- Re: [dnsext] DS digest downgrade Derek Atkins
- [dnsext] DS digest downgrade George Barwood
- Re: [dnsext] DS digest downgrade Mark Andrews
- Re: [dnsext] DS digest downgrade George Barwood
- Re: [dnsext] DS digest downgrade Francis Dupont
- Re: [dnsext] DS digest downgrade Edward Lewis
- Re: [dnsext] DS digest downgrade Mark Andrews
- Re: [dnsext] DS digest downgrade George Barwood
- Re: [dnsext] DS digest downgrade Wes Hardaker
- Re: [dnsext] DS digest downgrade Michael Graff
- Re: [dnsext] DS digest downgrade Wes Hardaker
- Re: [dnsext] DS digest downgrade Andrew Sullivan
- Re: [dnsext] DS digest downgrade Francis Dupont
- Re: [dnsext] DS digest downgrade Joe Abley
- Re: [dnsext] DS digest downgrade Wes Hardaker
- Re: [dnsext] DS digest downgrade Andrew Sullivan
- Re: [dnsext] DS digest downgrade Wes Hardaker
- Re: [dnsext] DS digest downgrade Matt McCutchen
- Re: [dnsext] DS digest downgrade Mark Andrews
- Re: [dnsext] DS digest downgrade Matt McCutchen
- Re: [dnsext] DS digest downgrade Mark Andrews