[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-ipsec-icmp-fail-01.txt
> From: David A Wagner <daw@orodruin.cs.berkeley.edu>
> draft-ietf-ipsec-icmp-fail-01.txt creates a small security hole.
>
> In particular, it defines a ICMP 'decryption failed' message, which leaks a
> little information about an encrypted datagram.
>
> Let me use the standard DES-CBC transform as an example: the last encrypted
> block contains padding, padding-length, and payload-type. The padding-length
> may be as large as 255 to hide the length of the plaintext payload. I claim
> this length can be recovered by taking advantage of the ICMP failure messages.
>
Thank you for the excellent analysis.
However, in order to make network protocols work in a user environment,
we need error feedback mechanisms for the protocols.
> Delete all the ciphertext
> blocks except the last N blocks (and set the IV to be the N+1 to last
> ciphertext block),
> ...
> A fix? One fix is to never use DES-CBC without authentication, I suppose.
>
As that is the fix for several other problems, I certainly recommend it.
Indeed, it is already recommended in the RFC.
Another more specific fix is to use the 32-bit IV facility, instead of
the 64-bit. That prevents setting the IV (above). I will be
recommending this at the LA IETF meeting.
Bill.Simpson@um.cc.umich.edu
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2