Re: [IPsec] Two questions aboutdraft-ietf-ipsecme-chacha20-poly1305-00

Hi,

>> On Mar 30, 2015, at 5:39 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
>>
>> Hi,
>>
>> There is two questions I would like guidance from the group about.
>>
>> First is the nonce/IV question: In the current draft, there is a 64-bit 
>> IV with guidance not to repeat them (so use a counter or LFSR). The 
>> function itself accepts a 96-bit input nonce, so the nonce is constructed 
>> from the 64-bit IV and 32 zero bits. The reason for doing this is so the 
>> algorithm could be used in a multi-sender case such as GDOI, where the 
>> 32-bit zero can be replaced by a sender ID. Alternatively, we could 
>> generate a 32-bit salt value from the key material, but I don’t see a 
>> reason why we’d want that. Another thing we could do is what some people 
>> are advocating for TLS: Since a counter is a fine IV (no need for 
>> secrecy), we don’t need a 64-bit IV that has the exact same value as the 
>> replay counter. We might as well save 8 bytes per packet and just feed 
>> the replay counter to the function.  The argument against this is that 
>> some crypto modules may have the API set up in such a way that the IVs 
>> are generated within the module and could be something other than a 
>> counter (like an LFSR). The proposal will break such APIs.

First, the third option is absolutely inappropriate.
The draft suggests using Chacha+Poly for both ESP and IKE and
in case of IKE there are no replay counter that is unique in the context of 
IKE SA.
Message ID in IKE header _is_not_ unique - it can be repeated at least in 
two cases:
RFC6311 and RFC7383. So, the IKE Message ID is allowed to repeat and these
repetitions would be fatal for security.

Among the first two options I prefer the AES-GCM-like approach -
taking the needed 32 bits from the keying material.

>> Second issue is about UI advice. Some implementations (yes, mine is 
>> included) allow the user to configure encryption algorithm, MAC 
>> algorithm, and D-H group. There is no setting for PRF since such UIs date 
>> back to IKEv1. The PRF is usually just taken from the setting for MAC 
>> algorithm. This works fine as long as all supported MAC algorithms are 
>> HMAC, XCBC, and CMAC. AES-GCM would have the same issue, but RFC 5282 
>> makes no mention of this issue. I’m wondering if we should recommend to 
>> pair this algorithm in IKE with PRF_HMAC_SHA2_256.

I think UI issues are out of scope of this draft. The draft should make no 
recommendations of what PRF
should be used  (at least it should not make such recommendations with 
RFC2119 keywords).

Regards,
Valery.

>>
>> Thanks
>>
>> Yoav
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
> 