latest drafts

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

I just finished reading over the latest set of drafts.  I seem to have
missed a set before the latest; all my comparisons were to two drafts
back (eg, userauth-27 is compared to userauth-25, not -26).  Here's the
latest round of things I notice.

userauth-27 says, of SSH_MSG_USERAUTH_BANNER messages, that "[t]he
message may consist of multiple lines", but gives no indication how
line breaks are to be encoded.  Most notably, it's not clear whether
CRLF or bare NL should be used, nor whether there are other
possibilities that implementations should be prepared for.  (Note that
transport-24's description of SSH_MSG_DEBUG explicitly says to use
CRLF.)

Various places speak of doing control character filtering as discussed
in [SSH-ARCH].  I've been unable to find the referenced discussion in
architecture-22.  Searching for "filter" returns no hits; searching for
"control" returns only false positives.  I even went so far as to read
the whole document through, and while I could have missed something, I
feel confident in saying that at the very least the discussion is
hidden excessively well.

architecture-22 section 8 says "which may be superceded in the future";
the word is actually spelled "superseded".

architecture-22 has a line
   the subject are [SCHNEIER] and [KAUFMAN,PERLMAN,SPECINER] Both of
which is missing a sentence-end period.

architecture-22 9.3.5 says that publickey makes no server security
assumptions.  But this is not quite true; a compromised server may be
able to use a publickey authentication attempt to play MitM to
authenticate to another host as if it held a public key it does not in
fact hold.  I'm not sure how feasible this is, because public-key
signatures are over data blobs including session-specific portions, but
it's certainly not obvious to me that it's impossible.

connect-25 6.10 has a message description with a "o" bullet for each
line; the rest of the message descriptions look different.

conenct-25 7.1 sez
   address or domain name and port to which the socket to be listened is
[page break]
   bound.
I'd prefer to see "is to be bound"; there also seems to be a "to"
missing after "listened".  (I'm not entirely sure I like to see
"socket" here, since there is no requirement that the TCP interface in
question be sockets.  I'm not sure this is worth fixing.)

Various specifications in transport-24 break rather badly if the cipher
in use has a block size that is less than 8 bytes but which does not
divide evenly into 8 bytes.  The spec for per-packet padding is perhaps
the most obvious, but by no means the only, such; I can go through and
extract a full list if desired.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B