On Mon, Feb 8, 2016 at 3:44 PM, Aaron Zauner <azet(_at_)azet(_dot_)org> wrote:
* Russ Allbery <eagle(_at_)eyrie(_dot_)org> [08/02/2016 17:56:37] wrote:
Paul Smith <paul(_at_)pscs(_dot_)co(_dot_)uk> writes:
If you do per-message compression, then I can't really see how
like CRIME could possibly work. CRIME seems to work by using the same
compression stream over known and unknown data, so by seeing how it
compresses, you can infer something about the unknown data because you
know the known data and how the compressor works. Also, it's a 'divide
and conquer' system, so needs lots of transactions - possibly
exponentially more the bigger the compressed data is.
The potential for an attack like this on per-message encryption comes
the fact that the leading data in email messages is fairly predictable
(the same few headers, and a given client is likely to generate them in
roughly the same order). That's where you get the known data from.
Previous posters to the SHUTUP mailing list (maybe also this one?
just joined) suggested only compressing the message data, that would
improve security there by a bit.
I've done implementations of CRIME on custom protocols a few years
back, to be effective an attacker must be able to alter parts of the
response ciphertext in order to guess using compression for the
attack. This isn't easy in SMTP as other people pointed out in the
Of course, this is way worse with the full SMTP dialog, since the various
SMTP-level commands are even more predictable. But at least in theory
might be able to derive some information about the contents of messages
using the known text in the message headers. (In practice, I think this
would be substantially harder than CRIME.)
Most certainly. But I'm still unsure what the added value of
compression in SMTP is there. Ideally I'd like to see some
measurements, these days most messages are rather short.
Your message, as received by me:
Small messages compress great!
But I'm guessing that's not the question you're asking.
As pointed out upthread, for historical reasons, most binary attachments
are base64 encoded, which increases their size of 4/3rds, and with
compression you get nearly all of that back... and that's with original
data which is relatively uncompressible (jpeg/mp4).
And, for many providers, their email streams are a relatively small
fraction of their bandwidth, certainly here at Google we spend a lot more
bandwidth on video. That said, our bandwidth isn't free, and we have
enough mail volume where reducing that by 25% would mean real savings.
Will we ever reach that level? I don't know. We never will if we don't at
least start the discussion.
I think the MSA case, especially for mobile devices, may be even more
interesting. I know that when we added support for COMPRESS for IMAP,
mobile clients adopted it almost immediately.
As for the security implications, I won't pretend that I know enough there
to be a good judge, though it's also not clear to me that we should
immediately shy away from this since there may be dragons there.
ietf-smtp mailing list