Subject: [IPsec] draft-mglt-ipsecme-rfc7321bis-03

From: Paul Wouters <[email-masked]>
Date: Thu, 1 Sep 2016 22:49:48 -0400 (EDT)

I just published draft-mglt-ipsecme-rfc7321bis-03 (well and -02)

(ietf announcement of these seems delayed?)

https://tools.ietf.org/html/draft-mglt-ipsecme-rfc7321bis-03

The changes are:

- Update 256-bit key sizes to MUST (except IoT) - similar to 4307bis
- Add Security Section from RFC7321
- Removed MAY algorithms (RC5, CAST, IDEA, ENCR_AES_CCM_16)
- Added note on ENCR_BLOWFISH
- Removed notes on removed MAY list entries (CCM & GCM flavours, GMAC, CMAC))
- Removed non-ipsec entries and added note to introduction on these
- Removed no longer used RFC-4595 reference

I think this document is now ready for a call for adoption.

Paul

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 2 Sep 2016 11:55:00 +0300

Can we make all the compression algorithms SHOULD NOT instead of MAY? 
TLS got rid of compression altogether, there are numerous attacks on 
compressed traffic, and even the document states that these algorithms 
are not widely implemented.

Thanks,
	Yaron

On 02/09/16 05:49, Paul Wouters wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 2 Sep 2016 14:18:09 +0300

Hi Yaron,

> are not widely implemented.

What attacks do you mean? Those that I'm aware of (CRIME, BREACH)
are specific to HTTP and cannot be directly used with ESP (ESP has a 
mandatory padding and an optional TFC padding that make those attacks
impractical).

Are there any new or more applicable attacks that I've missed?

I see no reason to downgrade compression to SHOULD NOT unless
we have an indication that it is really dangerous in the context of ESP.

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 2 Sep 2016 07:25:12 -0400

> On Sep 2, 2016, at 4:55 AM, Yaron Sheffer <[email-masked]> wrote:
> 

I would love too (to remove the added complexity) but it is really out of scope for the algorithm update document.

Paul

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 2 Sep 2016 15:30:40 +0300

Valery, here's what I could find:

* https://www.cs.jhu.edu/~cwright/oakland08.pdf
* http://www.techeye.net/security/skypes-encryption-destroyed-by-phonemes

And another attack was published recently, but I cannot find it.

So this is for voice, and the better known TLS attack are for HTTP.

Paul, why is this out of scope?

Thanks,
	Yaron

---

From: Paul Wouters <[email-masked]>
Date: Fri, 2 Sep 2016 09:06:49 -0400 (EDT)

> Paul, why is this out of scope?

Because we want to only update the algorithms, and not change the core
7296 RFC. It's one thing to promote or demote certain compression
schemes. It is quite a difference to obsolete the compression type
alltogether.

And again, just for the record, I'm all for it. But I think perhaps
a seperate document that just obsoletes all compression would be
better. (Also AH :)

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 2 Sep 2016 16:32:20 +0300

Yaron, 

I don't think these attacks are relevant to ESP compression.
As far as I understand, they rely on statistical analysis 
of the frame lengthes when phonems are encoded with a 
lossy compression algorithm. I don't see how it affects 
losless compression used in ESP.

Regards,
Valery.

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 2 Sep 2016 19:59:27 +0300

Hi Valery,

Yes, these are lossy algorithms, but the TLS/HTTP attacks are all with 
lossless algorithms. And as far as I know, they are applicable to any 
situation where here is an attacker that can force traffic on the wire, 
mixed with other, non-attacker controlled traffic. So IMO they are not 
restricted to just HTTP.

Thanks,
	Yaron

On 02/09/16 16:32, Valery Smyslov wrote:
> As far as I understand, they rely on statistical analysis of the frame
> lengthes when phonems are encoded with a lossy compression algorithm. I
> don't see how it affects losless compression used in ESP.
>
> Regards,
> Valery.
>
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 2 Sep 2016 21:45:40 +0300

> mixed with other, non-attacker controlled traffic. So IMO they are not 

The attacks using compression known to me (e.g. CRIME) rely on the ability
for an attacker to observe the difference in the length of messages (caused by applying 
compression) after each attempt. However, in case of ESP there are obstacles for doing that. 
First, ESP has a mandatory padding that is applied even in case of stream ciphers
(in this case the packet is aligned to a 4 bytes boundary). This makes it more
difficult for an attacker to catch a difference in lengthes. Then, ESP includes
an optional TFC padding feature that makes the above attack infeasable, because each
ESP packet will have either the same size or randomly adjusted size.
And ESP compression could help applying TFC padding without consuming
considerable anount of additional bandwidth.

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 2 Sep 2016 14:55:47 -0400 (EDT)

> considerable anount of additional bandwidth.

You mean TFC pad to something that's not the MTU ?

Not sure I see how compression + TFC makes smaller packets, unless your
TFC padding is very small or zero, which presumably means the attaker
can get it to become 0 for some cases?

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 2 Sep 2016 22:18:53 +0300

> You mean TFC pad to something that's not the MTU ?

Probably, but not necessary.

> can get it to become 0 for some cases?

It depends on the goal of TFC padding. To defend against CRIME-like
attack it is enough to add some small (up to dozen or two) random number of bytes to each packet.
Using compression helps not to earn (much) additional bandwidth in this case.

Of course, if your goal is a full TFC, than you need to make each
packet equal in size (and even better if you emit them at equal intervals).

Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 5 Sep 2016 17:39:12 +0300

> mixed with other, non-attacker controlled traffic. So IMO they are not 

There is big difference in the TLS and ESP that in the TLS the
compression is statefull, so if I send text "foobarzappa" earlier, and
then later in the session send the same string, that string will get
compressed. In the ESP this will only happen if you send it inside the
same packet. I.e., i.e., you can use the compression to check the
lengths if you can make one end to send packet where parts of the
packet comes from the attacker, and parts of it comes from somewhere
else, and attacker wants to verify whether his guess on the text on
the other parts are correct.

There are ways to use those attacks also against ESP, but I think they
are harder than against TLS, and also the main reason they worked for
the TLS, was because TLS allowed attackers to run code on the target
machine (javascript), which was then used to send trial stuff over the
same compressed link.

Anyways, I do not think compression is that widely used, and having it
as MAY is fine. We could add some note warning about the risks of
using compression. I.e., using compression, might leak out information
about the data transmitted over the ESP, and it might be good idea not
to enable compression if full confidentiality is required.

On the other hand on some IoT or similar environments, where every
byte counts, it might be useful to have compression. Also in some of
those environments authentication and authorization is much more
important than confidentiality.
-- 
[email-masked]