RE: AEAD in ssh

[Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost>]

denis bider <ietf-ssh3%denisbider.com@localhost> writes:

>I'm tempted to implement fixed-bandwidth SSH_MSG_IGNORE padding, just so I 
>can point to an existing client and server which thwart traffic analysis, 
>and need encrypted lengths.

You'd need to point to actual analysis (of the kind done in Peek-a-boo) to
show that it works.  That's the problem with SSH's encrypted lengths, twenty
years ago Tatu decided it was a good idea to use CRC32 as an ICV, RC4 as a
cipher, and encrypted lengths.  Since then we've had attacks on CRC32, RC4,
and encrypted lengths.  The response was to drop CRC32, drop RC4, and keep 
using encrypted lengths even though the only thing they've demonstrably given
us so far is security vulnerabilities.

The current discussion with AEAD is trying to perpetuate this cargo-cult 
protocol design with increasingly awkward Rube-Goldberg hacks to try and 
keep using something that was probably a mistake to begin with.  Sure, it 
was a well-intentioned mistake, but it doesn't do what people think it does 
while at the same time creating real security vulnerabilities.

>If my implementation consistently sends one ethernet frame (say 1450 bytes) 
>every 10 ms, this defeats traffic analysis at a cost of ~ 1.1 Mbps of fixed 
>bandwidth.

So maybe we could do a profile for a special allegedly traffic-analysis 
resistant SSH, let's called it Data-oriented SSH or DoSSH, where you flood a 
network link with unnecessary traffic.  So if you wanted to DoSSH someone's
network you'd use that version, and everyone else could use standard SSH.

Peter.