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

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

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@localhost), 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@localhost 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@localhost
list, Cc' me, and drop the ietf-ssh%NetBSD.org@localhost 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
--