Re: [Hipsec] NULL encryption mode in RFC 5202-bis

[Robert Moskowitz <[e-mail]>]

On 07/08/2014 06:33 AM, Stephen Farrell wrote:
> Thanks Tom,
>
> On 08/07/14 05:54, Tom Henderson wrote:
>> Hi all,
>>
>> Apologies for cross-posting, but Stephen Farrell raised a DISCUSS
>> (seconded by Kathleen Moriarty) in the IESG evaluation of RFC 5202-bis:
>>    Using the Encapsulating Security Payload (ESP) Transport Format with
>> the Host Identity Protocol (HIP).  Stephen asked me to raise this
>> question for discussion on both the HIP and SAAG lists.
>>
>> Stephen's discuss questions the specification of "MUST to implement" for
>> the NULL encryption option of the ESP_TRANSFORM parameter:
>>
>> http://tools.ietf.org/html/draft-ietf-hip-rfc5202-bis-05#section-5.1.2
>>
>> Stephen asks why is this a MUST to implement?  The history behind this
>> that I'm aware of is that since HIP does not have an AH, only ESP, the
>> ESP with NULL encryption mode can provide authentication.  It was also
>> stated in previous drafts that this mode supports debugging.
>>
>> Null encryption was also specified as a MUST to implement in RFC5202 and
>> dates back to earlier versions of the HIP base draft (to 2003:
>> http://tools.ietf.org/html/draft-moskowitz-hip-06#section-11.3).
> Right. I guess my discuss has a generic part and a hip specific
> part.
>
> Generic: is it still considered a good plan to have null
> confidentiality suites such as these? Or for those to be
> Mandatory-To-Implement (MTI)? That clearly was the generic
> consensus as we have these in a number of protocols. The
> new reasons to move from that I think are: 1) we no longer
> need this for debugging purposes really since libraries
> and dev tools have moved on and are better now, and we
> specifically no longer need these for protocols that are
> no longer new, 2) BCP188 could be considered to argue
> against having these as they could be misused. (All the
> old arguments of course do still apply, but I think the
> above are the ones that are new.) So is that enough to
> shift the consensus away from having these or having
> them be MTI?

I should point out that I lobbied hard for CMAC and GMAC added to 5202, 
as they are better constructs for doing auth only, or so I have been told.

I seem to recall during this discussion not to add these options as we 
have NULL which we need anyway.  I argued back that for systems that 
have AES-CCM or GCM in hardware, there would be a desire for CMAC or 
GMAC over HMAC.  SO now we have 3 suites that provide auth only with 
selection based on what MACing works best for the system(s) in question.

So given this, NULL is to balance the auth only suites or what?

I should also point out that the code we have today may not be the only 
code we have tomorrow.  That NULL does provide a valuable test tool.

So finally, a best implementation practice may to caution parties to 
accepting NULL.  Perhaps NULL when it is the only offered option. Or 
NULL when the list only contains NULL, CMAC, or GMAC.

>
> Specific: is there anything specific about hip that would
> trump the general point above? Note that there could be,
> regardless of where consensus lies on the generic question.
>
> FWIW, my own answers for these are that its probably a better
> plan today to not have (or make MTI) these null confidentiality
> ciphersuites, and I don't know that hip would have any specific
> reason to diverge from that. But I'd really like to see if
> there is a modified consensus on this or not. (To be clear,
> if there's not a new consensus then the current one would
> seem to still apply here and I'll clear my discuss.)
>
> Cheers,
> S.
>
>
>
>> - Tom
> _______________________________________________
> Hipsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hipsec
>