Subject: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT)

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Mar 2017 18:33:17 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-ipsecme-rfc7321bis-05: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc7321bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- I agree with Christian's secdir review [1] that this
doesn't seem justified (at least on it's face): " 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.  " Can
you explain the reasoning that lead the WG to say that?

- ENCR_NULL IMO ought be MUST NOT - did the WG discuss
that explicitly?  If so, can you provide a pointer to the
archive?  If not, does it still have to be a MUST?  I do
wonder who wants to use AH via NAT but cannot, which seems
to be the justification.

[1] https://www.ietf.org/mail-archive/web/secdir/current/msg07262.html

---

From: Yoav Nir <[email-masked]>
Date: Wed, 15 Mar 2017 08:58:08 +0200

Hi.

I’d like to address the second comment.

> On 15 Mar 2017, at 3:33, Stephen Farrell <[email-masked]> wrote:

<snip/>

> wonder who wants to use AH via NAT but cannot, which seems

This was raised at some meeting, and it was claimed that people are using it. This includes other standards bodies like IEEE 1588.

Although I don’t think IEEE 1588 is ever used over NAT, we need ENCR_NULL if we are to pull AH out of implementations (and implementations have been removing AH for years. It’s practically deprecated)

Yoav

---

From: Daniel Migault <[email-masked]>
Date: Wed, 15 Mar 2017 05:57:04 -0400

Regarding the first item manual key is prevented by AES-GCM RFC4306. We do
not not such "MUST NOT" level for AES-CCM and Chacha20_poly1305. Maybe we
could relax that a little bit and be more accurate saying:

OLD:
" 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:
" If manual keying is used anyway, ENCR_AES_GCM MUST NOT be used and
ENCR_AES_CBC SHOULD be used."

NEWbis:
" If manual keying is used anyway, ENCR_AES_CBC SHOULD be used."

Yours,
Daniel

AES-GCM (RFC4306 section 2):
"""

   Because reusing an nonce/key combination destroys the security
   guarantees of AES-GCM mode, it can be difficult to use this mode
   securely when using statically configured keys.  For safety's sake,
   implementations MUST use an automated key management system, such as
   the Internet Key Exchange (IKE) [RFC2409
<https://tools.ietf.org/html/rfc2409>], to ensure that this
   requirement is met.
"""

AES-CCM (RFC4309)

"""
   To be safe, implementations MUST use fresh keys with
   AES CCM.  The Internet Key Exchange (IKE) [IKE
<https://tools.ietf.org/html/rfc4309#ref-IKE>] protocol or IKEv2
   [IKEv2 <https://tools.ietf.org/html/rfc4309#ref-IKEv2>] can be used
to establish fresh keys.
"""

Chacha20_poly1305 (RFC7539)

"""
To generate such a key pair (r,s), we will use the ChaCha20 block
   function described in Section 2.3
<https://tools.ietf.org/html/rfc7539#section-2.3>.  This assumes that
we have a
   256-bit session key for the Message Authentication Code (MAC)
   function, such as SK_ai and SK_ar in Internet Key Exchange Protocol
   version 2 (IKEv2) ([RFC7296
<https://tools.ietf.org/html/rfc7296>]), the integrity key in the
Encapsulating
   Security Payload (ESP) and Authentication Header (AH), or the
   client_write_MAC_key and server_write_MAC_key in TLS.  Any document
   that specifies the use of Poly1305 as a MAC algorithm for some
   protocol must specify that 256 bits are allocated for the integrity
   key.
"""

On Tue, Mar 14, 2017 at 9:33 PM, Stephen Farrell <[email-masked]>
wrote:

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Paul Wouters <[email-masked]>
Date: Wed, 15 Mar 2017 07:43:18 -0400 (EDT)

On Wed, 15 Mar 2017, Daniel Migault wrote:

> Regarding the first item manual key is prevented by AES-GCM RFC4306. We do not not such "MUST
> NOT" level for AES-CCM and Chacha20_poly1305. Maybe we could relax that a little bit and be more
> accurate saying:
> 
> OLD:
> " If manual keying is used anyway, ENCR_AES_GCM MUST NOT be used and ENCR_AES_CBC SHOULD be
> used."
>  
> NEWbis:

I don't think that we should relax it. Those ciphers MUST NOT be used
with manual keying due to cryptographic reasons. On top of that, people
SHOULD NOT use manual keying because it prevents Perfect Forward Secrecy
(PFS).

We can clarify that, but I don't think we should change the MUST NOT.

Paul

>    the Internet Key Exchange (IKE) [RFC2409], to ensure that this
>    requirement is met.
> """ 
> 
> AES-CCM (RFC4309)
> """
>    AES CCM.  The Internet Key Exchange (IKE) [IKE] protocol or IKEv2
>    [IKEv2] can be used to establish fresh keys.
> """
> 
>    function described in Section 2.3.  This assumes that we have a
>    version 2 (IKEv2) ([RFC7296]), the integrity key in the Encapsulating
> On Tue, Mar 14, 2017 at 9:33 PM, Stephen Farrell <[email-masked]> wrote: