Hi Paul,
Can you please clarify why the HMAC mitigates this attack? As far as I
understand the attack, everything takes place inside the protected
tunnel, so the HMAC is always correct.
What could mitigate it of course is Traffic Flow Confidentiality (TFC).
In cases where compression is highly effective, maybe it makes sense to
sacrifice a few bytes for extra padding.
Thanks,
Yaron
On 09/20/2012 07:22 PM, Paul Wouters wrote:
Hi,
With the TLS compression attack of CRIME hitting the news recently, I
was wondering about this attack against IPsec compression.
While I think the attack is much harder, due to the HMAC, if I
understand it correctly it could still be tried once per user http
request. So if the attacker can trigger the user into connecting
multiple times to some http/https side through the ipsec tunnel, it
could attempt the same one octet replacement.
The Linux *swan implementations do not request compression per default,
but will always do it when the other end requests this, as it was
considered harmless to comply. I want to ensure this train of thought
is still valid, or whether this behaviour should be modified in "no
means no".
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
