Concerns about individual submissions process (c.f. RFC5647 AES-GCM for Secure Shell)
Nicolas Williams <Nicolas.Williams@sun.com> Wed, 02 September 2009 20:25 UTC
Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 976863A684D for <ietf@core3.amsl.com>; Wed, 2 Sep 2009 13:25:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.841
X-Spam-Level:
X-Spam-Status: No, score=-5.841 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
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 IS9JoOR9OyDC for <ietf@core3.amsl.com>; Wed, 2 Sep 2009 13:25:44 -0700 (PDT)
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id A13733A6358 for <ietf@ietf.org>; Wed, 2 Sep 2009 13:25:44 -0700 (PDT)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n82K5T0G016725 for <ietf@ietf.org>; Wed, 2 Sep 2009 20:05:29 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n82K5TTY059723 for <ietf@ietf.org>; Wed, 2 Sep 2009 14:05:29 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n82JsXdP009337; Wed, 2 Sep 2009 14:54:33 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n82JsXiU009336; Wed, 2 Sep 2009 14:54:33 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Wed, 02 Sep 2009 14:54:33 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: ietf@ietf.org
Subject: Concerns about individual submissions process (c.f. RFC5647 AES-GCM for Secure Shell)
Message-ID: <20090902195433.GR1033@Sun.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.7i
X-Mailman-Approved-At: Wed, 02 Sep 2009 14:22:52 -0700
Cc: ietf-ssh@NetBSD.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Sep 2009 20:25:45 -0000
Individual submission I-Ds that don't fall in the purview of a chartered WG do not require WGLC, only IETF Last Call, with a double-length IETF LC. Thus RFC5647 (AES-GCM for Secure Shell) was published with only IETF LC -- there was no WG in which to run a WGLC. However, there had recently (April 2009) been a lengthy thread on the old SECSH WG mailing list (Cc'ed) about this very topic. A heads-up should have been sent to that list. I do not subscribe to the IETF list (ietf@ietf.org), for the very obvious reason that its signal-to-noise ratio is too poor, thus completely missed the IETF LC of draft-igoe- secsh-aes-gcm -- but I would not have missed a heads up on the ietf-ssh@NetBSD.org list! Let's fix the IETF LC for individual submissions process. My recommendations: - Whenever there is a concluded WG [whose list remains in operation] that would have been a suitable WG for WGLC of an individual submission I-D, had that WG not been concluded, then send a heads up to that old WG's list. - Establish a separate list for IETF LC, or even one IETF LC list per-area. This will improve the signal-to-noise ratio, and will encourage wider review of individual submission I-Ds. Incidentally, only two weeks ago I was asked by a Security AD to initiate a "pseudo-WGLC" in WGs whose scope my I-D was outside. I gladly complied. The situation there was analogous to, though not exactly the same as, the situation with respect to draft-igoe-secsh-aes- gcm (now RFC5647). Why could a pseudo-WGLC in the concluded SECSH WG list not have been used? It's entirely possible that the notion of a pseudo-WGLC only just came up, that it was too late for draft-igoe-secsh-aes-gcm. But even so, a notion of "pseudo-WGLC" is too informal; we need a better solution than "hope the current ADs think of asking for a pseudo-WGLC" (no offense meant to the current ADs -- I'm worried about future cases). Comments? Please follow up the above comments on the ietf@ietf.org list, Cc' me, and drop the ietf-ssh@NetBSD.org list from the Cc list. -------------------------------------------------------------------------------- All that said, I'm reasonably happy with RFC5647, but there are several issues that I think should have been addressed prior to publication: - Nit: we don't call SSHv2 connections "tunnels". - Clarification: The initialization of the 'invocation_counter' and 'fixed' portions of the GCM nonce, and their semantics need more description. Specifically: - 'fixed' _appears_ to be the four left-most octets from the c-to-s or s-to-c "IVs" (one for each direction), while 'invocation_counter' _appears_ to be initialized to the eight right-most octets of the corresponding IV. This clarification seems obvious enough. - The 'invocation_counter' wraps around to zero, but if normalized to zero it is expected never to wrap to zero. This clarification seems obvious enough as well. - 'fixed' appears to be fixed per-_key exchange_, not for the life of the connection. This one, in particular, is a complete and utter guess on my part. These are not stated or not stated clearly. I will send e-mail to the authors and the old SECSH WG list to propose errata. - Also, a rather esoteric comment with respect to unencrypted packet lengths occurs: one could always use a variable-length encoding of packet length, padded to 32 bits with randomly generated bits. Of course, most implementations' actual TCP/IP packets would correlate with SSHv2 packet boundaries strongly enough, most of the time, that packet length would be visible regardless. And to be sure: I really don't mind the unencrypted packet lengths -- that's how SSHv2 should have been from the get-go! Being robbed of the opportunity to flog such a horrible idea at the authors is not really a problem :) I wouldn't bother with that idea, but I'd have enjoyed pointing it out! :) Please follow up to the comments on RFC5647 on the old SECSH WG list. Nico --
- Concerns about individual submissions process (c.… Nicolas Williams
- Re: Concerns about individual submissions process… Brian E Carpenter
- Re: Concerns about individual submissions process… Jari Arkko
- Re: Concerns about individual submissions process… Nicolas Williams
- Re: Concerns about individual submissions process… Nicolas Williams