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

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 <stephen.farrell@cs.tcd.ie>
wrote:

> 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
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>