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@xxxxxxxx), 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@xxxxxxxxxx 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@xxxxxxxx
list, Cc' me, and drop the ietf-ssh@xxxxxxxxxx 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
--
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf