Subject: [Hipsec] IPCOMP support in HIP

From: Robert Moskowitz <[email-masked]>
Date: Wed, 9 Mar 2016 10:20:54 -0500

Why did we not create a parameter to negotiate IPCOMP (currently RFC 3173)?

In IKEv2 it is negotiated in NOTIFY messages, not the basic exchange and 
becomes part of the daughter SA(s).

On contrained networks, IPCOMP could well be of value.  Also if HIP is 
used to establish the SAs for SSE (draft-moskowitz-sse-02.txt) and the 
SSE payload is XML, then IPCOMP (or some variant tbd) may be a good thing.

So....

Again, why no IPCOMP parameter?

IPCOMP parameter handled like ESP parameter or like in IKEv2?

How to add an IPCOMP parameter?  If I write a draft for a Generic 
Protocol Compression, I can include a section that defines an 
IPCOMP/GPCOMP parameter.  Or I can add it to DEX (don' want to add that 
at this point, EC25519 fits, IPCOMP is expanding the protocol).

Comments?

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 10 Mar 2016 08:29:15 -0500

I have found comp in TLS, RFC 3749, so HIP's ESP is the only one missing 
compression.  How did I miss that?  It should have been included in 7402 
as an option within ESP.

I will figure out a way to get it into some RFC, but perhaps a little 
hashing out how it would work is called for first:

IPCOMP parameter is a list.  The parameter number is higher than ESP; 
something like 4111.

RFC 3173 defines the Compression Parameter Index as 2 bytes, so that 
would be the size of the values in the list.

R1 would have a list of supported IPCOMP algorithms.
I2 would have the selected algorithm, or a value of ZERO if none.
R2 would have the confirmed value.

NOTIFY could be used to set up IPCOMP (or change it) at a later time.

Comments?

On 03/09/2016 10:20 AM, Robert Moskowitz wrote:
> In IKEv2 it is negotiated in NOTIFY messages, not the basic exchange 
> and becomes part of the daughter SA(s).
>
> IPCOMP/GPCOMP parameter.  Or I can add it to DEX (don' want to add 
> that at this point, EC25519 fits, IPCOMP is expanding the protocol).
>
> Comments?
>
>
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: Miika Komu <[email-masked]>
Date: Thu, 10 Mar 2016 16:28:18 +0200

Hi,

I guess it could be a new "IPCOMP" transform similar to the ESP transform:

https://tools.ietf.org/html/rfc7402#section-5.1.2

I think R1-I2 would be enough, no need to confirm it in R2, similarly as 
with ESP transform:

https://tools.ietf.org/html/rfc7402#section-5.2.1

---

From: Derek Fawcus <[email-masked]>
Date: Thu, 10 Mar 2016 19:10:41 +0000

> compression.  How did I miss that?  It should have been included in 7402 

Hasn't use of compression with TLS largely been abandoned now?
Simply because one or more of the recently published exploits depended upon
it,  such that now one is recommended to disable compression?

So if TLS is avoiding compression,  why is normal IPsec still using it?
It is because the compositions of compression and encryption used in IPsec
are safe,  or has no simply tried (or not published) such attacks for IPsec?

DF

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 10 Mar 2016 14:18:51 -0500

Fair point.  I really cannot convert TLS specifications to packet 
content.  I suspect there are things exposed?

With IPCOMP, it is all within the EXP encrypted block.  It is known 
text, for the most part and would be open to known text attacks. But 
then there is always a fair amount of known text at the beginning of an 
ESP payload.  How would this be different?

I do suspect that TLS is different in how it does compression, and if it 
is being abandoned, so sad.  It should be fixed because....

Even 5G will not provide unlimited bandwidth, and XML tends to be very 
compressable.  Plus with DEX on constrained networks, compression is 
even more valuable.

But can you point me to a paper on the TLS compression attack?

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 10 Mar 2016 15:13:25 -0500

I have looked at both the CRIME and BREACH attacks and neither would 
work against IPCOMP within ESP.  TLS and HTTP compression are softly done...

It DOES change some of my thoughts about compression as a XML option for 
use in DOTS.  That is pretty much what CRIME is attacking. Rather you 
have to take your outer envelope that contains your XML and compress the 
whole thing.

---

From: Derek Fawcus <[email-masked]>
Date: Thu, 10 Mar 2016 20:52:22 +0000

> content.  I suspect there are things exposed?
[snip]
> is being abandoned, so sad.
quite possibly.

> But can you point me to a paper on the TLS compression attack?

I'm afraid not,  I just recall reading up on some of the TLS attacks
when they were publicised,  and seeing that some of them were related
to compression.  A bit of poking around though yielded:
    http://www.iacr.org/cryptodb/archive/2002/FSE/3091/3091.pdf
I also spotted this,  but it doesn't add much:
    https://www.cosic.esat.kuleuven.be/ecrypt/provpriv2012/abstracts/barghavan.pdf

I did avail myself of google before my prior email,  it suggested CRIME
and BREACH.   Where the latter seems to be HTTP specific,  and a chosen
plain text attack.

So all I'm suggesting is to be careful,  and do appropriate comparisions,
to see if one can ensure enabling compression does not enable an attack
mode similar to those seen with TLS.  Since I'm not sure if the lack
of attacks against ESP+IPCOMP is due to inherent robustness,  or simply
a lack of trying.

DF

---

From: Derek Fawcus <[email-masked]>
Date: Thu, 10 Mar 2016 20:55:21 +0000

On Thu, Mar 10, 2016 at 03:13:25pm -0500, Robert Moskowitz wrote:
> work against IPCOMP within ESP.

Ah,  good.

> use in DOTS.  That is pretty much what CRIME is attacking.

So my spanner wasn't totally worthless :-)

DF