Re: a more detailed analysis of "known IV" vulnerability.

[daw%mozart.cs.berkeley.edu@localhost (David Wagner)]

Bill Sommerfeld  wrote:
>[folks, please look this over and let me know if I missed anything..]

Ahh.  Thanks for the detailed analysis.

I must admit I'm not 100% convinced by your numbers, though they seemed
like a good start.  It looked to me like a better estimate is that
around four blocks of plaintext might leak in an average 1 GB session,
assuming circumstances most favorable to the attacker.

However, that's still not so bad.  If all those assumptions on the
upper layers hold, then the leakage is still not very severe, I guess.
(Of course, we're relying heavily on these assumptions about the upper
layers, so it is crucial that the upper layers not be re-designed --
e.g., by allowing provisions for fragmentation in the upper layers.)

Bottom line: the exposure is quite limited, and I think it's reasonable to
conclude that this attack will not be easiest way to break SSH sessions.
If this is the best attack on SSH, that's a pretty good place to be at.
So I think I agree with the decision to defer these changes in order to
encourage SSH deployment as soon as possible.  I withdraw any objections
I may have had.  Thanks for the explanations.

I believe this rationale should be carefully explained in the SSH RFC.
Otherwise, some readers might get the wrong impression.  Also, it will
help inform those who might re-use the SSH encoding transform without
also maintaining the upper layers that they are in a danger zone.