RE: Binary packet protocol rethink (was: Re: ChaCha20-Poly1305 for SSH)

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

Simon Tatham <anakin%pobox.com@localhost> writes:

>Is there any possible way - and would people be interested in pursuing it if
>there were - to invent a replacement binary packet protocol for SSH which
>decouples the unit of encryption and the unit of protocol semantics into
>completely separate layers?

I've asked for this in the past too.  SSL/TLS have used unencrypted lengths
for twenty years without there being any (known) attack or weakness based on
this.  OTOH SSH has used encrypted lengths for nearly the same period, and
there have been several attacks/weaknesses based on that.  Security-wise, it
has the opposite effect of the one intended, it makes the protocol weaker, not
stronger.

My real issue with it though is that, as you've pointed out, it makes it
impossible to create an efficient streaming implementation.  With TLS you read
the length at the start, stream the rest into the target memory location, and
decrypt in place.  With SSH you have to read a single block, decrypt it, make
sure you're not providing an oracle for the attacker, copy what's left around,
read more encrypted data onto the end, decrypt the remainder, ugh.

I would really like to see a protocol that:

1) Doesn't encrypt the length so you can create an efficient streaming
   implementation.

2) Uses encrypt-then-MAC for security rather than MAC-then-encrypt.

This would solve several problems with the current format all at once.

Peter.