Hi,
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.
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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp