On Thu, 20 Sep 2012, Nico Williams wrote:
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.
This is not about breaking the IPsec layer, but guessing the session
cookie of an http/https session protected by an IPsec layer.
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.
But would they be _more_ vulnerable with compression? If not, then there
is nothing we can do. If compresion does make these attacks easier, I
want to change the default of always allowing it.
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).
Yes, compression needs to happen at the plaintext layer, otherwise it
wouldn't compress that much to begin with.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
