Hi,
On 07/02/2014 05:26 PM, Miika Komu wrote:
Hi,
On 06/30/2014 08:46 PM, Tom Taylor wrote:
3) Section 5.2.18: given the strict ordering of HIP parameters, the
initial
plaintext for the Encrypted content (type and length of initial
parameter) may be fairly easily guessed. This opens up the minor
possibility of a known plaintext attack. [Comment to be reviewed after
further examination.] [Upon review: I1 packets have fixed type but
variable length due to varying lengths of DH-GROUP-LISTS. The set of
such lengths is limited, however, so it is worth considering whether
known plain-text attacks offer any real threat.]
Discussion: I don't know how/whether to handle this, or whether other
similar vulnerabilities in other security protocols are addressed.
Changes to address this would likely complicate things or increase the
packet sizes.
[PTT] I have to leave it to people more knowledgeable in security to
judge whether this is a realistic attack. One point of approach is to
find out what sample size is needed for known plain-text attacks for
specific algorithms, compare that with the rate at which an attacker
could collect encrypted messages in specific scenarios, and decide
whether there is a real threat. Mitigation presumably might be through
adjustment of the rate of key rollover.
do we actually need the encrypted parameter for something really
critical (i.e. some extensions rely on it)? If not, we could just remove
it. Usually the encrypted parameter just contains the HOST_ID of the
Initiator which does not really offer any real privacy since the HIT is
in plaintext and actually can interfere with middleboxes (as already
mentioned in the draft).
If the encrypted parameter is critical, here's a straw-man proposal that
avoids increasing packet size: XOR the contents of the encrypted
parameter by iterating through it block-by-block using the encryption
key. Then, encrypt it with the same key.
If packet size is not a problem, we could include an extra, fixed size
key for XORing within the encrypted parameter. Or perhaps just encrypt
the plaintext twice with the encryption key.
(My solutions are presented in chronologically in the order of my
personal preference)
on second thought, do we actually have a real problem here? Let us consider:
* The encryption key is different for each base exchange, so the roll
over is actually occurring every time, so that observing multiple base
exchanges does not benefit the attacker
* To derive the encryption key, you need a very expensive brute for
search, and the award is (usually) just the public key of the initiator
* If the parameter contains something else in addition to the public
key, the brute force search is still very expensive (exponential)
* The default algo (AES) is resistant against linear and differential
cryptanalysis
So, I am not convinced that the current mechanism should be changed.
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
