Re:New TLS Padding Oracles
by tialaramex on Wednesday February 27, 2019 @12:01PM
(#19264640)
> At least with TLS1.3 and QUIC we can pad encrypted data and get a measure of length-hiding back; enough to at least raise costs for passive fingerprinting attacks (and raise those costs more than CBC ever could on its own).
I have to say this feels like both the more actionable and more insightful output of your... heresy.
We are not going back to CBC. You say that some CBC attacks don't seem practical. The trouble with the Web is it's like some lunatic deliberately designed a system to be attacked. Oh you have a chosen plaintext attack that needs 1 million repetitions? Impractical. Wait, Javascript exists. OK, but even with Javascript who'd ever have a system that terminates HTTPS for completely unrelated parties on the same physical hardware - there's no way we'll get to exploit that? Oh, bulk hosting exists. OK. Still nobody would build a crypto system in which one party is just completely anonymous all the... oh wait, that's exactly how Tim's system was designed. Eric Rescorla has some great slides about this.
Whereas "Hey, let's pad every message to hit the path MTU size for packets" totally feels like something vendors could do next week and make a huge impact with no real cost. A lot of network devices can't hit their target speeds for small packets anyway, so the impact may be not merely negligible but literally non-existent.
I have to say though, I'm not actually clear on why we couldn't pad TLS 1.2's AEAD modes to the same effect?
The TLS 1.3 padding is _clever_ but what does it do here that makes it more important for your passive fingerprinting attack than the older padding scheme (with an AEAD cipher)?
I have to say this feels like both the more actionable and more insightful output of your... heresy.
We are not going back to CBC. You say that some CBC attacks don't seem practical. The trouble with the Web is it's like some lunatic deliberately designed a system to be attacked. Oh you have a chosen plaintext attack that needs 1 million repetitions? Impractical. Wait, Javascript exists. OK, but even with Javascript who'd ever have a system that terminates HTTPS for completely unrelated parties on the same physical hardware - there's no way we'll get to exploit that? Oh, bulk hosting exists. OK. Still nobody would build a crypto system in which one party is just completely anonymous all the... oh wait, that's exactly how Tim's system was designed. Eric Rescorla has some great slides about this.
Whereas "Hey, let's pad every message to hit the path MTU size for packets" totally feels like something vendors could do next week and make a huge impact with no real cost. A lot of network devices can't hit their target speeds for small packets anyway, so the impact may be not merely negligible but literally non-existent.
I have to say though, I'm not actually clear on why we couldn't pad TLS 1.2's AEAD modes to the same effect?
The TLS 1.3 padding is _clever_ but what does it do here that makes it more important for your passive fingerprinting attack than the older padding scheme (with an AEAD cipher)?