On Thu, Sep 20, 2012 at 11:48 AM, Paul Wouters <[email protected]> wrote: > On Thu, 20 Sep 2012, Nico Williams wrote: >> 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.
For HTTP (with cookies) the use of compression at *any* lower layer [that provides session cryptographic protection] creates this vulnerability. >> 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. I didn't say otherwise. I said that compression should happen at a layer (the application layer) that is higher than the transport protection layer (TLS, ESP, SSH, whatever). I did not imply that the alternative is to try to compress at a layer below that where encryption takes place. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
