[secdir] secdir review of draft-ietf-ipsecme-rfc7321bis-05

Christian Huitema <huitema@huitema.net> Wed, 15 March 2017 00:54 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4D14813176A for <secdir@ietfa.amsl.com>; Tue, 14 Mar 2017 17:54:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id OHsDbNk4uAh7 for <secdir@ietfa.amsl.com>; Tue, 14 Mar 2017 17:54:46 -0700 (PDT)
Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A7FF131766 for <secdir@ietf.org>; Tue, 14 Mar 2017 17:54:46 -0700 (PDT)
Received: from xsmtp12.mail2web.com ([]) by mx36.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.86) (envelope-from <huitema@huitema.net>) id 1cnxDA-0000eW-N7 for secdir@ietf.org; Wed, 15 Mar 2017 01:54:45 +0100
Received: from internal.xmail03.myhosting.com ([] helo=xmail03.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <huitema@huitema.net>) id 1cnxD9-00021V-6G for secdir@ietf.org; Tue, 14 Mar 2017 20:54:44 -0400
Received: (qmail 23767 invoked from network); 15 Mar 2017 00:54:42 -0000
Received: from unknown (HELO []) (Authenticated-user:_huitema@huitema.net@[]) (envelope-sender <huitema@huitema.net>) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for <draft-ietf-ipsecme-rfc7321bis.all@ietf.org>; 15 Mar 2017 00:54:41 -0000
From: Christian Huitema <huitema@huitema.net>
To: The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-ipsecme-rfc7321bis.all@ietf.org
Message-ID: <2927d78d-7293-ba53-4aa3-0351e0a6e7b2@huitema.net>
Date: Tue, 14 Mar 2017 17:54:39 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------60F4C3F8F1706AE1B463A015"
X-SpamExperts-Domain: xsmtpout.mail2web.com
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.14)
X-Recommended-Action: accept
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49L/N1imVzxQGuMdyq1ILpVFTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXoHYbDgNOedI2ngcqbsFM2eRcOb18WfxGyg6Om6u4YYm+QyIeXTCPs5oMtU Fzks8ig5hjoyEb9Oq0NWpyO3vrfYNrJwCbVSZviV1vzVlxiUlT3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBe34TY+s3lj/RgDQoaICKQ3TFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0CCRf8dnm s7AEHX18dEIK27bRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmjLzCyMdOETT xDqixVDal2Zqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgAg eNjxIyqtWcsHzPElnaBFglzR8EKamCCPLRQqfIrw/hvxLqd67w5ZW6bZsK3PVhKokBKK3jt6GcQw FAZLjDEKGyoCJJa3e874rwXXGPuEmSKg33smtlc64dR/aNUnR+kcQlvCYTspYJdGl64rm9ixxYJS vH1uwzGpXypuXzvU+ePe1gM7ipZJnJOKSsr7OvUQxK4Q6pnz1PG2i0Jcu7De
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/w9k58rDSlTGpQfYrgh3jXf8xqJA>
Subject: [secdir] secdir review of draft-ietf-ipsecme-rfc7321bis-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Mar 2017 00:54:48 -0000

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

The document revises RFC 7321. It updates the Cryptographic Algorithm 
Implementation Requirements for ESP and AH. The new recommendations
emphasize using authenticated encryption, support for 256 bit keys,
and modern algorithms. The recommendations appear sound, even if there
are some compromises made, in particular in the name of IoT.

This document is ready for publication as a Proposed Standard, with some nits.

My first set of nits concerns the keywords "SHOULD+", "SHOULD-" and "MUST-" that the 
draft is defining. These keywords would make an interesting update to RFC 6919. I 
understand that "SHOULD+" and "MUST-" are already defined and used in RFC 7321, and 
that you have at places to say "RFC 7321 said SHOULD+, but we change that to MUST". 
So maybe you should just note that "RFC 7321 defines these additional keywords".
Also, you never use SHOULD- in the text, so there is no need to define it. You
only MUST- once, to downgrade "AUTH_HMAC_SHA1_96" from MUST to MUST-. You could save 
space in the document by just adding a footnote for the SHA1 entry in the table,
stating that "this MUST means REALLY SHOULD NOT." Or maybe you really want to
update RFC 6919.

The second set of nits contains manual keying. According to the draft, anyone using 
manual keying is punished for doing so, and will only be able to use ENCR_AES_CBC. I 
assume that there is WG consensus on that, but the justification that other algorithms
really require IKEv2 is a bit weak. If there is an API to configure encryption with the
results of an IKEv2 negotiation, it could just as well be used with the results of a
manual configuration. Not sure that the definition of algorithms is the best place to
deprecate manual configuration, even if there are some pretty good reasons to do that.

My last set of nits concerns the relation between this draft and the IANA registry of 
Internet Key Exchange Version 2 (IKEv2) Parameters. I understand that we have five states 
of specification or recommendation:
* MUST implement and MAY use algorithms such as ENCR_AES_GCM_16;
* SHOULD implement and MAY use algorithms such as ENCR_CHACHA20_POLY1305;
* SHOULD implement and MAY use but only for IoT devices, e.g. ENCR_AES_CCM_8;
* SHOULD NOT implement and MUST NOT use, e.g. ENCR_DES; Presumably, the code 
  has to be yanked from existing implementations.
* and then MAY implement and MAY use, e.g. ENCR_CAMELLIA_CBC.
But the fifth category is only specified by default, as "those algorithms that
are listed in the IANA registry but not referenced in the draft." I wonder whether there
is a way to express that clearly in the draft.

-- Christian Huitema