Re: [Hipsec] IPCOMP support in HIP
On Thu, Mar 10, 2016 at 02:18:51pm -0500, Robert Moskowitz wrote: > Fair point. I really cannot convert TLS specifications to packet > content. I suspect there are things exposed? [snip] > I do suspect that TLS is different in how it does compression, and if it > 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 ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] IPCOMP support in HIP
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. On 03/10/2016 02:10 PM, Derek Fawcus wrote: On Thu, Mar 10, 2016 at 08:29:15AM -0500, Robert Moskowitz wrote: 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. 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 ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] IPCOMP support in HIP
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? On 03/10/2016 02:10 PM, Derek Fawcus wrote: On Thu, Mar 10, 2016 at 08:29:15AM -0500, Robert Moskowitz wrote: 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. 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 ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] IPCOMP support in HIP
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 On 03/10/2016 03:29 PM, Robert Moskowitz wrote: 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: 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? ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec smime.p7s Description: S/MIME Cryptographic Signature ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] IPCOMP support in HIP
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: 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? ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
