Re: [Hipsec] processing review comments on RFC 5201-bis

[Robert Moskowitz <[e-mail]>]

On 07/02/2014 11:32 AM, Miika Komu wrote:
> 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.

Also there is an assumption of what the first type value is?  Other uses 
of it may not contain the Host_ID, but something else.  And thus the 
length would be different according to that something else type.

I might point out that HIP DEX uses ENCRYPT parameter.  I am sure there 
are others.