Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-imp-status-04.txt

Andrew Sullivan <ajs@anvilwalrusden.com> Tue, 12 March 2013 14:20 UTC

Return-Path: <ajs@anvilwalrusden.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 580FF21F8B4C for <dnsext@ietfa.amsl.com>; Tue, 12 Mar 2013 07:20:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.807
X-Spam-Level:
X-Spam-Status: No, score=-0.807 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311]
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 zcvgsgK21RoJ for <dnsext@ietfa.amsl.com>; Tue, 12 Mar 2013 07:20:57 -0700 (PDT)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB7221F8B4A for <dnsext@ietf.org>; Tue, 12 Mar 2013 07:20:56 -0700 (PDT)
Received: from mx1.yitter.info (dhcp-2430.meeting.ietf.org [130.129.36.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id DDD188A031 for <dnsext@ietf.org>; Tue, 12 Mar 2013 14:20:55 +0000 (UTC)
Date: Tue, 12 Mar 2013 10:20:44 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsext@ietf.org
Message-ID: <20130312142044.GE39133@mx1.yitter.info>
References: <20130311152035.4888.59295.idtracker@ietfa.amsl.com> <20130311191607.GF38303@crankycanuck.ca> <E99C99C9-73E1-43F8-B09E-B28CA138F526@hopcount.ca> <20130311194317.GA38441@crankycanuck.ca> <FBCCECBD-43DC-46F1-911F-B06ED43E10C3@hopcount.ca> <20130311201201.GD38441@mx1.yitter.info> <20130312132705.GA39133@mx1.yitter.info> <C2325C79-C3E7-42EC-93E3-5CDB586C7C51@hopcount.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <C2325C79-C3E7-42EC-93E3-5CDB586C7C51@hopcount.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-imp-status-04.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>
X-List-Received-Date: Tue, 12 Mar 2013 14:20:58 -0000

On Tue, Mar 12, 2013 at 09:47:58AM -0400, Joe Abley wrote:
> 
> The only practical difference between ECDSA and GOST-ECC is where they were developed and standardised, and (once again) I think it'd be unfortunate if there was the perception that the GOST-specified algorithm was being under-promoted purely for geopolitical reasons.
> 

I'm not sure that's the reason.  I actually have no idea what the
reason was, but the WG previously had already reached consensus on
this issue, so I'm trying to figure out whether the problem is merely
the description of why the ECDSA algorithms might find more pick-up,
or whether the document has a fundamental mistake in it.

I also cannot help but observe that this issue has cropped up now
after multiple WGLC events on this basic issue, and nobody ever
mentioned it before.  The only reason the document is back before the
WG is to ensure that the changes in response to the AD's DISCUSS have
not changed the substance of the document.  

This is not to discourage late observations, but to ask about the
quality of review that we did in the past, and also to ask whether, if
we reopen this, whether we'll get adequate review in the next round of
discussion.  There is no question that moving ECC-GOST from Optional
to some other status is a substantive change to the document, and
would need another WGLC and, IMO, IETF LC.  I would not be even
remotely surprised if that LC failed for want of responses.

Best,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com