Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT)

[Eric Rescorla <[e-mail]>]

On Mon, Jun 19, 2017 at 7:45 AM, Paul Wouters <[e-mail]> wrote:

> On Thu, 23 Mar 2017, Tero Kivinen wrote:
>
> Paul Wouters writes:
>>
>>> -3: I wonder why "... is not to be used..." is not "... MUST NOT be
>>>> used...". But the section goes on to say if you do it anyway, you MUST
>>>> NOT use certain cryptosuites. So, does "... is not to be used..." mean
>>>> "SHOULD NOT"? Or is this one of those "MUST NOT BUT WE KNOW YOU WILL"
>>>> sort of requirements?
>>>>
>>>
>>> It is indeed. I think a SHOULD NOT would actually be appropriate ?
>>>
>>
>> We do not want to make the implementation of the manual keying MUST
>> NOT, as it is still useful in testing and similar situations, but we
>> do not want anybody using it in any real world use cases. As this
>> document is mostly about the implementation and tries to stay out from
>> the issues about what should be used (as explained in the 2nd
>> paragraph of the section 1.3).
>>
>> On the other hand section 1.3 is really about the use of the manual
>> keying, not about the implementation of manual keying, so that
>> confuses things (we do have some other cases were we say things DES
>> MUST NOT be used).
>>
>> I think the text needs to be clarified about this bit more, especially
>> we do not want to say that ENCR_AES_CBC MUST be used, as there are
>> other algorithms which can also be used (MUST be used would indicate
>> no other algorithm is possible).
>>
>
> Here is a suggestion:
>
> OLD text:
>
> 3.  Manual Keying
>
>    Manual Keying is not to be used as it is inherently dangerous.
>    Without any keying protocol, it does not offer Perfect Forward
>    Secrecy ("PFS") protection.  Deployments tend to never be
>    reconfigured with fresh session keys.  It also fails to scale and
>    keeping SPI's unique amongst many servers is impractical.  This
>    document was written for deploying ESP/AH using IKE ([RFC7296]) and
>    assumes that keying happens using IKEv2.
>
>    If manual keying is used anyway, ENCR_AES_CBC MUST be used, and
>    ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT be
>    used as these algorithms require IKE.
>
> NEW text:
>
> 3.  Manual Keying
>
> Manual Keying SHOULD NOT be used as it is inherently dangerous.
> Without any keying protocol, it does not offer Perfect Forward
> Secrecy ("PFS") protection. Without IKE, another entity needs to
> ensure refreshing of session keys, tracking SPI uniqueness and
> ensuring nonces or IVs are not used more then once. This document
> was written for deploying ESP/AH using IKE ([RFC7296]) and assumes
> that keying happens using IKE version 2 or higher.
>
> If manual keying is used anyway, AEAD algorithms MUST NOT be used,
> as these algorithms require additional input provided by IKE and
> are compromised if a counter is accidentally re-used, such as when
> a counter overflows, or when a device reboots without remembering
> the previously used counters. As of publication of this document,
> ENCR_AES_CBC is the only non-AEAD Mandatory-To-Implement encryption
> algorithm suitable for Manual Keying.


It's not AEAD that's the problem here. After all, it's perfectly possible
to do AEAD
with CBC-HMAC. Rather, it's CTR mode.

-Ekr


>
>
> - Table in section 6:
>>>> I'm boggled by the first entry being labeled "MUST/MUST NOT". I don't
>>>> see
>>>> anything in the text to explain the "MUST" part--did I miss something?
>>>>
>>>
>>>
>>> First paragraph under the table:
>>>
>>>     AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT.  The
>>>     only reason NULL is acceptable is when authenticated encryption
>>>     algorithms are selected from Section 5.  In all other cases, NULL
>>>     MUST NOT be selected.
>>>
>>
>> It does not make it easier that there is typo in that paragraph, and
>> it talks about NULL, when it should be talking about AUTH_NONE...
>>
>
> Queued up (NULL -> AUTH_NONE)
>
> Paul
>
>