Re: AEAD in ssh

Peter Gutmann <[email protected]> writes:

> They actually leak nothing, in that 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. Their analysis, of TLS traffic with unencrypted lengths, completely
> ignores TLS' plaintext length fields because they're irrelevant.

I've read that paper. It's good work, but I don't think it applies to all
uses of ssh, and it doesn't apply at all to high-overhead padding.

My understanding of that paper, as appliad to ssh, is that if you use
ssh to download files (e.g., using tcp forwarding of browser traffic),
the amount of data and the speed reveal a lot of what your downloading
and from where. But that's only one of many ssh use cases. I'm more
concerned about interactive use, in which case it may also be reasonable
to use high-overhead padding).

I agree completely that it's hard to defend against traffic analysis.
But I disgree with your judgment that encrypted lenghts are totally
useless period.

I would also like to say that the intention of my draft is to leave this
aspect of the protocol unchanged, because I think that's a decision
orthogonal to AEAD support. Conversely, if I wanted to add encrypted
length fields to TLS, I'd write a draft doing just that, not bundle that
change with standardization of some other new features.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.