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

On 08/02/2016 18:07, Martijn Grooten wrote:
> 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. 
You can't say that...

If 'compression and encryption don't go together', then you have to stop 
people sending JPG, DOCX, ZIP, GIF etc files as well. Those are 
compressed, and they are sent over encrypted links.
Should HTTPS servers stop delivering JPEG files? Do we force people to 
download images as BMP files?
No, because it's not that 'compression and encryption don't go 
together', but that compression can be used *in a very specific way* to 
help find out the content of the encrypted data. It does not break the 
encryption, and it is not a weakness of the encryption.
(AFAICT, CRIME/etc will not help determine the content of JPG/DOCX/etc 
files. It is purely "if I send known data along with unknown data and 
can tell the compressed size, then, after lots of tries I can guess what 
the unknown data is that was sent with my known data". If I am simply 
receiving something that I have no control over (or sniffing a stream 
that I can't inject into), then I have nothing to work with, and the 
data is safe. SMTP is just "receiving something".)
As far as I can see, the CRIME method isn't really even an 'attack on 
HTTPS'. It's actually an attack on the web browser. If you write a 
standalone 'CRIME client' it'd be useless. The CRIME attack is 
attempting to determine the cookies stored in a web browser. It doesn't 
allow the attacker to determine the content downloaded from the HTTPS 
server, just the cookie content sent by the browser. It's very specific, 
and there's nothing like it, even in concept, in SMTP.
> 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.
But it is.

I "can't see how" TLS can be snooped on usefully, but that doesn't mean 
we throw it away. You can't prove a negative. Until someone has 
discovered a weakness, or at least a theoretical weakness, then you have 
to assume it's good enough.
All the documentation I've found on CRIME/etc require specific 
behaviour, which is just not there in SMTP. I may be wrong, and someone 
may have worked out a theoretical way to exploit compression in SMTP, 
but just saying 'there may be a way to break this that no one's 
discovered yet' isn't (IMHO) a good enough reason not to do something. 
Otherwise we may as well just abandon all attempts at encryption, as 
there may be ways to break those that no one has discovered yet.
Until someone comes up with an SMTP extension which lets a third party 
say to an unrelated MTA "send that last message again with this 
arbitrary data added at the start" (so it can be sniffed to try to 
determine the newly compressed message size and compare it to other 
compressed sizes of the same message with different data at the start), 
then I can't see how CRIME or anything like it could work with SMTP.
It has to be a third party telling the MTA to send again, because the 
two MTAs involved in the transaction can already see the 
uncompressed/unencrypted data, so any attempt for them to do a 
'CRIME-like' attack is totally pointless. In CRIME, there are three 
parties involved - the browser, the server and the page content/script. 
it's this third thing which does the attack. In SMTP there are 
(currently) only two, so there is no agent available to perform the attack.



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