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
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec

Reply via email to