Re: [dnsext] draft-ietf-dnsext-dnssec-algo-signal-07.txt

Paul Hoffman <paul.hoffman@vpnc.org> Tue, 17 July 2012 17:10 UTC

Return-Path: <dnsext-bounces@ietf.org>
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0DD21F86A7; Tue, 17 Jul 2012 10:10:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342545027; bh=w4X8Vin/rk243OK1r4OrrXe+O4hXuFKgmNfY/IrC5Wc=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=Go/fygwvu8mTMDRapxGsItZc/jI86uPXFMpW1tyYGn65xVG198oaGln3Mt7Fqmb91 Ix2cermEKXbl/qMW7AscIl6NBSBnnqyJ0wRcC1Fh/+eE+HJviV6LJ7USBPceBodKLD JrUx6kHzGW7+JAwsS1NoSrT0wdsLcVyrd3bMxh+A=
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 3571C21F86BB for <dnsext@ietfa.amsl.com>; Tue, 17 Jul 2012 10:10:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.577
X-Spam-Level:
X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6oB+qfWp1ip for <dnsext@ietfa.amsl.com>; Tue, 17 Jul 2012 10:10:20 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 19C7221F86A7 for <dnsext@ietf.org>; Tue, 17 Jul 2012 10:10:20 -0700 (PDT)
Received: from [10.20.30.102] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q6HGP4g9084057 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Jul 2012 09:25:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <5A201A57-A13E-4021-A012-CEA37DA5DBED@shinkuro.com>
Date: Tue, 17 Jul 2012 10:11:03 -0700
Message-Id: <C9946CED-F26A-4BF3-9DF4-E910655270D7@vpnc.org>
References: <6EC11B57-B164-4214-AADE-E552D9B21753@frobbit.se> <85D2BE55-4028-468E-A07B-4F3B7406B68A@vpnc.org> <5A201A57-A13E-4021-A012-CEA37DA5DBED@shinkuro.com>
To: Steve Crocker <steve@shinkuro.com>
X-Mailer: Apple Mail (2.1278)
Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <patrik@frobbit.se>, dnsext@ietf.org
Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-signal-07.txt
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

On Jul 17, 2012, at 10:00 AM, Steve Crocker wrote:

> There is a subtle point that may be helpful to recall.  The primary purpose of advertisement of which algorithms are understood by the resolver is to provide a measure of the adoption of new algorithms.  In the broad, slow cycle of introduction of new algorithms and the presumed phasing out of old algorithms, operators on the signing side of the equation will be choosing when to sign with a new algorithm and when to stop signing with an old algorithm.  They can sign with a new algorithm whenever they feel ready to do so, but they cannot rationally stop signing with the old algorithm until they have evidence that essentially all of the resolvers understand the new algorithm.  

Fully agree with all that.

> Thus, as I said, the primary purpose of this protocol extension is to provide measurable assessment of the uptake of a new algorithm.  From this perspective, the order of the algorithms within the resolver's advertisement is irrelevant.

And that too, of course.

> Subordinate to this primary purpose is the potential for also advertising a preference.  Whether the responding system pays attention to the order is up to the responding system.  Also, as you suggest, the querying system may or may not have a real preference.  

Nowhere in this document or any other DNSSEC RFC do we give any advice on why a resolver should have a preference. And that's a good thing.

> I don't think we have enough information to say one way or the other,

We disagree, strongly. Until you can show that more than a small fraction of the users of this will have a preference, saying that all of them need to have a preference in order to express it in a list adds a layer of complexity that you cannot show has any value.

> and the perfect is the enemy of the good.  

Thats a convenient way of saying "I don't know, but I liked this feature before, so let's leave it in". Some of us prefer not to add superfluous features and would use different trite saying to back our opinions.

> Let's move this forward and revisit your concern when there is some implementation and deployment experience to examine.  

Errr, how? Under what criteria could that evaluation be made? I propose that there are none possible.

> I hope is that this is the worst issue we will have to deal with.

Fully agree.

--Paul Hoffman

_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext