[Top] [All Lists]

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

2016-02-06 10:43:03

On 29 Jan 2016, at 19:07, John Levine <johnl(_at_)taugh(_dot_)com> wrote:

Compression has been removed completely from TLS v1.3, the outcome of
the room consensus at IETF-89.


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 ( 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 -

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.


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

ietf-smtp mailing list