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

From: Tony Finch <[email-masked]>
Date: Mon, 1 Feb 2016 12:47:12 +0000

Carl S. Gutekunst <[email-masked]> wrote:
>
> We assume that binary MIME (ala RFC 3030) is dead.

BURL is designed to work with BDAT, so that you can submit a message in
chunks with verbatim parts (BDAT) and out-of-line attachments (BURL).

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fair Isle, Faeroes, Southeast Iceland: Cyclonic gale 8 to storm 10, decreasing
5 to 7 at times. Very rough or high, becoming very high for a time. Rain or
squally showers. Poor, occasionally good.

---

From: Aaron Zauner <[email-masked]>
Date: Sat, 6 Feb 2016 11:15:54 +0100

Hi,

> On 29 Jan 2016, at 19:07, John Levine <[email-masked]> 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

---

From: Martijn Grooten <[email-masked]>
Date: Sat, 6 Feb 2016 11:32:26 +0000

On Sat, Feb 06, 2016 at 11:15:54AM +0100, Aaron Zauner wrote:
> 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).                                                                                                                                                                          

I think it's fair to say (as others have done already) that none of
these attacks work against SMTP as they all require the attacker to
force the client to make specific requests to the target.

But these attacks also show that compression and encryption don't go
well together. And crypto is hard and provides plenty of opportunities
to mess up. For that reason, I would suggest following TLS 1.3 and not
combine the two, as it would teach people bad habits.

Martijn.

---

From: Aaron Zauner <[email-masked]>
Date: Sat, 6 Feb 2016 12:40:21 +0100

> On 06 Feb 2016, at 12:32, Martijn Grooten <[email-masked]> wrote:
> 

Well, yes. You just can't do JavaScript via SMTP (yet) :)

> combine the two, as it would teach people bad habits.

There aren't that many people looking into this, with renewed research efforts I fear that these attacks may improve significantly. The authors of mentioned work on improving these attacks explicitly mentioned other application layer protocols than HTTP(S) in the Q/A after the talk. They will also be presenting new attacks at upcoming conferences. As I see it - adding compression might reduce traffic load for some providers but at the same time may introduce new vulnerabilities in the future to already poorly-secured protocols like SMTP.

Aaron