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

[Paul Wouters <[e-mail]>]

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.

>>> - 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