Subject: Concerns about individual submissions process (c.f. RFC5647 AES-GCM for Secure Shell)

From: Nicolas Williams <[email-masked]>
Date: Wed, 2 Sep 2009 14:54:33 -0500

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
([email-masked]), 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
[email-masked] 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 [email-masked]
list, Cc' me, and drop the [email-masked] 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
--

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 03 Sep 2009 09:54:21 +1200

Nico,

On 2009-09-03 07:54, Nicolas Williams wrote:
...
> I do not subscribe to the IETF list
> secsh-aes-gcm

Last Calls are announced on the [email-masked] list,
which is a read-only list with relatively low volume.

The reason for that is to avoid exactly the problem you describe.
If you're not subscribed to ietf-announce, you won't see *any*
Last Calls, or other important announcements.

http://www.ietf.org/list/announcement.html

    Brian

---

From: Jari Arkko <[email-masked]>
Date: Thu, 03 Sep 2009 11:52:47 +0300

Nicolas,

As Brian notes, the formal messages go out on ietf-announce. However, I 
think all the ADs sponsoring individual documents attempt to reach the 
right audience. This includes personally reminding key contributors, 
forwarding the last call announcement to a mailing list if one is still 
known, etc. We also say so in our published procedures:

http://www.ietf.org/iesg/statement/ad-sponsoring-docs.html

> The exact nature of the review within the IETF is not specified, but 
> it is expected that documents be posted for review in the relevant WG 
> mailing lists. Often no relevant mailing list exists, in which case 
> area-specific or IETF main discussion list can be used. 
> ... work closely related to a WG but strictly outside its charter 
> should always be brought to the WG's attention during review. 

Of course, its also easy to forget to do this in the midst of all other 
things that are going on.

Jari

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 2 Sep 2009 17:00:07 -0500

On Wed, Sep 02, 2009 at 05:57:43PM -0400, Ken Raeburn wrote:
> On Sep 2, 2009, at 15:54, Nicolas Williams wrote:
> Nico, perhaps you should subscribe to the ietf-announce list.  It gets  
> LC notices, RFC publication notices, WG action notices, and a few  
> other things; it's not a discussion list.

Huh.  I thought I was.  But evidently I'm only on the RFC editor's
announcement list.  *sigh*

Thanks Ken and Brian,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 3 Sep 2009 11:12:44 -0500

> As Brian notes, the formal messages go out on ietf-announce. However, I 

Indeed.  I completely forgot about that.  I get so many IETF
announcements that I didn't realize that I was not on that particular
list.  That's my fault, and I'm embarrassed :/

> http://www.ietf.org/iesg/statement/ad-sponsoring-docs.html

Indeed.  I would not likely have missed an e-mail to the old SECSH WG.

> things that are going on.

Understood.  I've subscribed to ietf-announce, so I won't miss any such
individual I-D IETF LCs again.

Thanks for your replies!

Nico
--