Re: potential disclaimer for the transport draft.

[Bill Sommerfeld <sommerfeld%orchard.arlington.ma.us@localhost>]

> I think this paragraph is not accurate. Specificly, the protocol itself is
> not resistant, rather it's the current implementations that are somewhat
> resistant

I'm rephrasing to:

Preliminary analysis of this attack as applied to the SSH protocol
suggests that the protocol as implemented today is actually fairly
resistant to this attack...

> the attacker does not have to inject tens of millions of
> chosen plaintexts, he just needs to cause tens of millions of packets to
> be sent, and do one chosen plaintext at the right moment.

I'll rephrase to:

.. on average, an attacker would need tens or hundreds of millions of
opportunities to inject chosen plaintexts to be encrypted with a known
IV to confirm guesses on the value of a few unknown plaintexts.

> On any particular system, it's probably not the biggest hole, but it
> quite likely is the biggest hole on *some* real-world systems.

I think you severely underestimate how many latent undiscovered
security holes are out there at the moment.. I don't think we have
*any* reason to believe that.

> Also, I think we need to say something to the effect that once the
> new modes are defined, CBC ciphers should be considered deprecated
> and no longer REQUIRED or RECOMMENDED, so that future users are not
> confronted with the choice of CBC mode.

It's premature to overconstrain the possible solutions.

We haven't decided on the fix.  If we choose to fix the problem by
introducing new ciphers, the document which specifies them can
deprecate the old ciphers.  We could investigate new ciphers,
determine we can't agree on the right ones, and fall back to fixing
the problem some other way (i.e., start each block of ciphertext with
an SSH_MSG_IGNORE).

						- Bill