With IPSec, compression happens on a per-packet basis; the contents of previous packets do not affect how this packet is compressed in any way. Hence, there would be a vulnerability only if the attacker can somehow create a single packet that contains both the unknown cookies, as well as his chosen text. If he can, then likely he could (with sufficient cleverness) figure out a way to exploit it. However, if his chosen packets contain only what he picked and not the cookies (or whatever else he is interested in), there's no vulnerability.
For TLS, compression is stateful; how this segment is compressed does depend on previous segments; for example, if the text of the segment appears exactly as is in a previous segment, this entire datagram may be replaced with a token that says [Insert X bytes from Y positions from the current stream]; if this entire datagram doesn't appear exactly as is, it'll be replaced with more tokens, and so it won't compress as well. That makes compression work much better (because it doesn't forget everything at the start of each segment); however, it does introduce the vulnerability that CRIME is based on. I'm not arguing for/against the idea the compression ought to be done by the application; I'm merely talking about the likelihood of CRIME being an impact of IPSec right now. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Nico Williams Sent: Thursday, September 20, 2012 12:43 PM To: Paul Wouters Cc: IPsecme WG Subject: Re: [IPsec] IPsec compression - vulnerable to CRIME-style attack or not? On Thu, Sep 20, 2012 at 11:22 AM, Paul Wouters <[email protected]> wrote: > With the TLS compression attack of CRIME hitting the news recently, I > was wondering about this attack against IPsec compression. Well, in so far as IPsec doesn't have cookies or anything like a bearer token, it's safe. However, if you were using IPsec to protect HTTP web traffic, and if the attacker can find some way to either be an IPsec peer of your client or get your client to use unsecured HTTP connections by which the attacker can inject adaptive chosen plaintext for use in HTTP secured with IPsec, then that would be vulnerable, yes. The key is: what's running on top of IPsec? My thinking is that compression of data needs to be pushed to as high a layer as possible (i.e., the application layer), where decisions about what to be compressed (e.g., bulk non-voice/non-real time, therefore bufferable data) can be left to the part of the system that can best make them (i.e., the application). Nico -- _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
