Re: latest drafts

[Chris Lonvick <clonvick%cisco.com@localhost>]

Hi,

On Sun, 20 Mar 2005, der Mouse wrote:

> 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.)

Suggestions from anyone?

>
> 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.

This text appeared in [ARCH]-11:

   When displaying text, such as error or debug messages to the user,
   the client software SHOULD replace any control characters (except
   tab, carriage return and newline) with safe sequences to avoid
   attacks by sending terminal control characters.

There were three paragraphs in the Security Considerations section.

This text appeared in [ARCH]-12:

   When displaying text, such as error or debug messages to the user,
   the client software SHOULD replace any control characters (except
   tab, carriage return and newline) with safe sequences to avoid
   attacks by sending terminal control characters.

There were 4 paragraphs then.  After that, the WG revised the Security
Considerations section so that the security considerations of all other
documents were incorporated into the Security Considerations section of
[ARCH].  Such text does not seem to appear in any of the IDs at this time.
Should it be restored in the general Security Considerations section like
the section on "Pseudo-Random Number Generation", or should it be restored
within a particular section (Transport, Connection, User Auth)?

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

The spellchecker in kate doesn't object to it.  Nontheless, I'll change
it.

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

OK.


>
> 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.

Does Ben's note cover this?

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

Yuck.  I'll fix it.

>
> 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".

Which do you want;
   The 'address to bind' and 'port number to bind' specify the IP
   address or domain name and port to which the socket to be listened to
   is bound.  Some strings used for the 'address to bind' have
   special-case semantics.
-or-
   The 'address to bind' and 'port number to bind' specify the IP
   address or domain name and port to which the socket is to be bound.
   Some strings used for the 'address to bind' have special-case
   semantics.

> (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.)

If we can get some quick consensus we can probably squeeze it in.

>
> 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.

Does Ben's note address this?

Thanks,
Chris