Re: [ietf-smtp] [Shutup] Compressing SMTP streams

On Mon, Feb 08, 2016 at 09:50:43AM +0000, Paul Smith wrote:
> AFAICS, CRIME isn't really a issue of 'compression & encryption not
> going together', but that the nature of compression lets you infer
> information about the compressed data. It doesn't seem to attack the
> encryption at all.
Well, the idea behind CRIME is that data strings compress to smaller
strings if there is more repetition in the original string and that
encryption doesn't change the length of a plaintext. So if you're able
to make small modifications to an otherwise unknown plaintext and you
can read (the length of) the encrypted output, you can determine whether
the bit you controlled occurred elsewhere in the plaintext. CRIME uses
this to step-by-step reconstructs a cookie.

These kinds of attacks are the reason why people say that compression
and encryption don't go together, even if you are technically right that
it's all compression's fault. So perhaps it would be better to say: if
it's sensitive, don't compress it.

> If you do per-message compression, then I can't really see how
> something 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.
>
> So, to do it in SMTP message compression, you'd need to inject some
> arbitrary known text into an unknown message. I can't see how you
> could do that unless you have actually had control of the original
> message - in which case the message wouldn't be unknown... In the
> known HTTPS CRIME exploit, the HTTPS client can inject known data
> into the HTTP request which gets added to unknown content (the web
> cookies) by the web browser so you can see how they interact via the
> compression.
>
> You'd also need to do it lots of times with the same unknown
> message. Probably many more times than the HTTPS exploit because a
> typical RFC822 message is a lot bigger than a typical web cookie.
This is all true. I can't see how a CRIME-like attack on SMTP+TLS could
work either.

But cryptography tends to set itself very high standards, in which "I
can't see how" just isn't good enough. Even if you'd be absolutely
certain(*) that such attacks would never be found, I still think it's a
bad idea: implementing cryptography is hard enough as it is; people make
mistakes all the time. Teaching them bad practices should thus be
avoided, even in cases where it doesn't really matter.

Unless, of course, network connections around the world are falling over
because of all the emails. I don't run any large mail servers, so please
correct me if I'm wrong, but a back-of-the-envelope calculation suggests
that this is unlikely to be the case.

(*) and given that, as Aaron pointed out, mail servers aren't updated
often, you would really have to be absolutely certain.

Martijn.

signature.asc
Description: Digital signature

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp