Re: AEAD in ssh

[denis bider <ietf-ssh3%denisbider.com@localhost>]

Peter - see bottom.


Niels:

> What do you think of the way it is specified in the draft?
> Which is well defined for an arbitrary AEAD, but boils
> down to plain CTR mode for typical AEAD block cipher
> modes, and boils down to plain cacha encryption
> for chacha-poly1305?

I think the intent is good, but the description is overly clever. You seem to recognize this:

"For many AEAD algorithms, this seemingly complex procedure boils down to ..."

Also, the described mechanism does not boil down exactly to CTR mode. The counter is initialized differently. It seems to me plain CTR would be better.

It might be better to just ditch the complex description, and specify a separately-keyed instance of the underlying stream cipher. This might be either the cipher itself for ChaCha20; or a block cipher in CTR mode in the case of AES.


> should lengths conceptually be packed back to back into
> a stream to be encrypted four bytes at a time [...],
> or should we use one underlying "block" per message? 

One underlying block per packet is slightly simpler with a block cipher.

Back-to-back is more efficient - +0.25 or fewer additional block transformations per packet, instead of +1.

I'm not sure that either option is problematic in terms of a timing side channel. A decent fixed-bandwidth implementation would be sending a fixed amount of data on a fixed timer.

Back-to-back would make most sense with a stream cipher. It seems consistent to use the same with a block cipher in CTR mode.


Peter:

> encrypting the length provides no security benefit at all.
> See for example "Peek-a-Book, I Still See You: Why Efficient
> Traffic Analysis Countermeasures Fail" by Dyer, Coult,
> Ristenpart and Shrimpton.

This paper points out an inherent tradeoff between efficiency and pattern hiding. It says nothing about when efficiency does not matter, because you can maintain a fixed bandwidth.

The problem with plaintext lengths is that they don't just defeat efficient countermeasures. They defeat ALL countermeasures to traffic analysis.

In a time of always-on TV streaming, it's increasingly conceivable to maintain a fixed bandwidth for not only 10 second bursts, but for the entire connection.

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.

I can then point to AES-GCM in our help text, and say: "This algorithm is not resistant to traffic analysis. It is counter-productive to enable it in conjunction with fixed-bandwidth connection padding."