Subject: Re: Ben Harris's individual submissions: arcfour-fixes and rsa-kex

From: der Mouse <[email-masked]>
Date: Sat, 2 Apr 2005 21:09:48 -0500 (EST)

>>> 	http://www.ietf.org/internet-drafts/draft-harris-ssh-arcfour-fixes-00.txt
>>> 	http://www.ietf.org/internet-drafts/draft-harris-ssh-rsa-kex-01.txt
>> I haven't implemented this yet, but I certainly intend to.
> I've got client and server implementations of the -00 version in
> OpenSSH, and Simon's done an independent client implementation of it
> for PuTTY.  I don't think either of us has yet updated for -01.

Well, I have what I think is an implementation of both kex methods from
rsa-kex-01 now too.  My code interoperates with itself, of course, but
I'd like to do interop testing with others' implementations of any of
these algorithms.  Anyone game?

>>> rsa-kex is a weaker kex
>> Well, it's weaker in some respects,
> [D]iscussions of SHA-1 have convinced me that there's a slight
> weakness here that I should perhaps guard against.  Because the
> client can see all the other input to the exchange hash before it
> generates K, if it's got a working collision attack against HASH it
> can create two sessions with the same session ID.

I'm not sure this buys you anything of significance.  Even granting all
the above, what can go wrong if a client (or two clients in collusion,
which amounts to the same thing) gets two sessions with the same
session ID?

It allows the client to get the server to sign the same data twice,
which could be a weakness if the host key algorithm involves random
elements in signing, and is weak against such an attack.  ssh-rsa does
not involve any random element, so the same data signed by the same key
gives the same signature and, perforce, no new information.  ssh-dsa
does involve random data in signing; I haven't looked at it enough to
have more than a wild guess whether it leaks information if the same
data is signed twice with the same key.  (If forced to guess, I would
guess it does not; the designers of DSA had plenty of competence on tap
to build something strong against that if they wanted to, and it's an
obvious potential attack.)

If the session ID *and the shared secret* are the same, so will all the
derived keys and IVs, which means that for some ciphers, like arcfour,
the resulting connection is insecure against passive attackers (since
it then involves encrypting different data with the same keystream).
But as I pointed out earlier, a client that wants to leak session data
to a passive listener has lots of easier methods available.  Even if it
doesn't want to leak it directly, the protocol makes no effort to
prevent covert channels from either endpoint to passive snoopers - and
such a client could just leak the keys and IVs directly, thus letting
the snooper read the traffic without taking the risk of alerting the
server that arranging two connections with the same session ID does.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Ben Harris <[email-masked]>
Date: Tue, 05 Apr 2005 13:36:14 +0100

>which amounts to the same thing) gets two sessions with the same

Nothing that I can think of, but SSH is an extensible protocol, which means
we need to allow for possible future developments.  At the moment, I think
that duplicate session IDs are only a problem if the client in one session
colludes with (or is) the server in another, in which case they can MITM a
session from the other client to the other server.  I think this is only by
chance, though, and I can't be sure that future extensions won't assume the
uniqueness of session IDs in other ways.

Imagine, for instance, a backwards version of my RSA KEX, in which the
client generates a key and the server encrypts the secret under it.  This
might be useful if your server is particularly short of CPU.  Given a
client, A, which supports this imaginary KEX method, a server, B, which
supports my KEX method, and an adversary, M, which can generate collisions
in SHA-1, M can MITM a connection between A and B despite the fact that
neither A nor B supports both protocols.

This is all getting a bit silly really.  I'm arguing that my protocol is
insecure despite the fact that I think it's secure enough (cracking the RSA
keys should be about as hard as generating hash collisions, and is a lot
more dangerous since it can be done off-line).

-- 
Ben Harris