Hi, > On 29 Jan 2016, at 19:07, John Levine <[email protected]> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Shutup mailing list [email protected] https://www.ietf.org/mailman/listinfo/shutup
