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

[Aaron Zauner <[e-mail]>]

Hi,

> On 29 Jan 2016, at 19:07, John Levine <[e-mail]> wrote:
> 
>> Compression has been removed completely from TLS v1.3, the outcome of
>> the room consensus at IETF-89.
> 
> Bummer.

No, it's a security *feature*.

> 
> Well, in that case, here's a straw man proposal.
> 
> The extension name is COMPRESS, the EHLO keyword is COMPRESS and is
> followed by a space-separated list of compression schemes, currently
> consisting only of DEFLATE (RFC 1951.)
> 
> There's one new command, COMPRESS which takes as an argument the type
> of compression to be used.  If you want to do both STARTTLS and
> COMPRESS, the results of doing COMPRESS before STARTTLS are
> aggessively undefined.
> 
> The responses to COMPRESS are:
> 
> 500 compress not supported
> 501 compression scheme unknown
> 220 go ahead

I'm strongly opposed to this.

Do you guys have any numbers on this? I.e. what the advantage and compression ratio for your average mail traffic will be? I suspect compression is helpful in SMTP but it may also introduce vulnerabilities in combination with TLS. CRIME wasn't the only attack on compression, there's also been application layer specific attacks - BREACH for example (breachattack.com). A team is currently working on improving these attacks in application layer protocols, circumvent counter-measures in clients et cetera (from a talk at RealWorldCrypto2016 - https://drive.google.com/file/d/0Bzm_4XrWnl5zMkJJdHo0Rml4bXM/view?usp=sharing).

Another problem with SMTP extensions is that mail daemons are rarely updated thus it takes quite some years to have real support on the internet.

Aaron