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

From: Paul Wouters <[email-masked]>
Date: Mon, 19 Jun 2017 10:45:00 -0400 (EDT)

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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Jun 2017 08:16:51 -0700

> 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

---

From: Paul Wouters <[email-masked]>
Date: Mon, 19 Jun 2017 11:26:39 -0400 (EDT)

On Mon, 19 Jun 2017, Eric Rescorla wrote:

> It's not AEAD that's the problem here. After all, it's perfectly possible to do AEAD

Hmm, of course we only have CTR based AEAD's :P

Ok, NEW NEW last paragraph:

        If manual keying is used regardless, Counter Mode 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 Mandatory-To-Implement
        encryption algorithm suitable for Manual Keying.

Paul

---

From: <[email-masked]>
Date: Mon, 19 Jun 2017 15:40:40 +0000

> On Jun 19, 2017, at 11:16 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 

I still prefer MUST NOT.  

If we're goint to use SHOULD NOT, it needs to be accompanied by very explicit wording that directs test labs and authors of certification requirements documents that they are forbidden from having manual keying in their certification requirements.  We currently have the issue that some uninformed certification requirements documents do exactly this: force implementers to implement something we KNOW is wrong.  We end up writing stuff in the user manual along the lines of "NEVER use this option -- it exists only because of a certification requirement".  This is absurd, and it has to stop.

> ...

That's ok so far as it goes, but I don't believe it is sufficient to correc the previous agency errors.

	paul

---

From: Russ Housley <[email-masked]>
Date: Mon, 19 Jun 2017 11:35:13 -0400

> On Jun 19, 2017, at 11:26 AM, Paul Wouters <[email-masked]> wrote:
> 

The Security Considerations in RFC 3686 point out the problems with using AES-CTR with static keys, which is what I think you mean by manual in this paragraph.  I think you need to delete “AEAD” from the first sentence or explain that CCM and GCM encompass counter mode.

Russ

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Jun 2017 09:45:25 -0700

I agree with Russ.

On Mon, Jun 19, 2017 at 8:35 AM, Russ Housley <[email-masked]> wrote:

> The Security Considerations in RFC 3686 point out the problems with using
> AES-CTR with static keys, which is what I think you mean by manual in this
> paragraph.  I think you need to delete “AEAD” from the first sentence or
> explain that CCM and GCM encompass counter mode.
>
> Russ
>
>