Re: latest drafts

[Ben Harris <bjh21%bjh21.me.uk@localhost>]

In article <200503210212.VAA11526%Sparkle.Rodents.Montreal.QC.CA@localhost> you write:
>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.

It looks like it got lost when the Security Considerations section was
rewritten in architecture-14 (2003-07-14).  Before that, it said:

   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.

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

The protocol is designed to make this kind of attack impossible.  publickey
signatures are over (amongst other things) the session ID.  For a server to
MITM a publickey authentication, it would have to get the session IDs for
the two connections to be the same, which would mean getting two hashes with
partially different inputs (since some input in each case is the other
side's KEXINIT cookie) to have the same output.  This is at least as hard as
finding a collision in the hash, which is assumed to be sufficiently
difficult.  If it isn't sufficiently difficult, you need a stronger exchange
hash.

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

I think the simple answer is that you can't use such a cipher with SSH,
which seems fine to me.

-- 
Ben Harris