Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-00.txt

John Mattsson <john.mattsson@ericsson.com> Mon, 02 November 2015 14:35 UTC

Return-Path: <john.mattsson@ericsson.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D2E1B373F for <ipsec@ietfa.amsl.com>; Mon, 2 Nov 2015 06:35:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oFKsCvRLnWP for <ipsec@ietfa.amsl.com>; Mon, 2 Nov 2015 06:35:37 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8934A1B2C94 for <ipsec@ietf.org>; Mon, 2 Nov 2015 06:35:36 -0800 (PST)
X-AuditID: c1b4fb2d-f79626d000004282-8b-563774b60f9d
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F2.87.17026.6B477365; Mon, 2 Nov 2015 15:35:34 +0100 (CET)
Received: from ESESSMB307.ericsson.se ([169.254.7.39]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Mon, 2 Nov 2015 15:35:34 +0100
From: John Mattsson <john.mattsson@ericsson.com>
To: "ipsec@ietf.org" <ipsec@ietf.org>
Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-00.txt
Thread-Index: AQHRFXu7qgXgtELg9k6Y0s/OKlhTiQ==
Date: Mon, 02 Nov 2015 14:35:33 +0000
Message-ID: <8E795DD4-DF63-452D-96AA-F6D7BE232530@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="utf-8"
Content-ID: <3895668F6FF74E419F981A44AE08DE1D@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM+Jvre62EvMwg74NRhb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoPjL9kKlolVfPg5m62B8Y5oFyMHh4SAicTkf2ldjJxAppjE hXvr2boYuTiEBI4wSlw4cBvKWcQo0XW6mR2kik3AQGLungY2EFtEQFXi1LLprCC2sICrxLee fnaIuJvEwiVTWSBsPYmpRy8wgdgsAioSbbtfMoLYvAL2Ehtf/wGrYQTa/P3UGrAaZgFxiVtP 5jNBXCQgsWTPeWYIW1Ti5eN/rBC2ksSK7ZcYQR5gFtCUWL9LH6LVWmLd2TksELaixJTuh+wQ qwQlTs58wjKBUWQWkg2zELpnIemehaR7FpLuBYysqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJL NjEC4+Hglt+6OxhXv3Y8xCjAwajEw2uQaBYmxJpYVlyZe4hRgoNZSYT3WZ55mBBvSmJlVWpR fnxRaU5q8SFGaQ4WJXHeFqYHoUIC6YklqdmpqQWpRTBZJg5OqQZGg33BC3aa6Uyttzlvl5T4 5kPNj6UyU/l3ih4PXfBz0i3V8hjJOJmlyyrlWWUOJjlWrP0kfS/rVsB0w/ySzPPdVx9O+7TQ v+Gyrf+xTTLLNONbvP2PWvRMzMt2mHtpf9e9v/EXG7h6Vud5Zpf79CvL3jhXWDP5ZvzZpWsW LQ69o3fsz70HE3YcV2Ipzkg01GIuKk4EAMyjI12DAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipsec/ebBSN4UI0jBvu-fjA0tnuuQJZJw>
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Nov 2015 14:35:38 -0000

Some comments on draft-ietf-ipsecme-rfc4307bis-00

In general, very good and very needed.


- Abstract says:
“This document defines the current set of algorithms that are mandatory to implement as part of IKEv2, as well as algorithms that should be implemented because they may be promoted to mandatory at some future time.”

The introduction also only talks about MTI and believed to be future MTI. ENCR_DES does not fit in either of these categories. I am all for specifying MUST NOT for such algorithms, but the abstract and introduction should be updated.


- BTW, What does it mean that an algorithm like ENCR_RC5 is not listed, does that mean “MAY”, “MUST NOT”, or “totally unspecified”?


- Section 3.2. says “When an AEAD algorithm (see Section 3.1) is used, no algorithm from this table needs to be used.” Shouldn’t this be “MUST NOT be used”.


- Section 3.1. I think AES_CCM_8 should somehow be restricted to IoT, as using 64 bit tags in IKE does not sound like general good advise. Also IoT implementations would probably just implement “ENCR_AES_CCM_8”, “PRF_HMAC_SHA2_256", and "256-bit random ECP group" and skip everything else. It seem to make more sense to specify an IoT profile in a separate section.


- Section 3.4. The Diffie-Hellman group table diverges heavily from the rest with only 112-bit security as MUST, and no group offering 128-bit security as even SHOULD+. This may be ok, but I think the ipsecme group should try to fulfill general recommendations on security levels (NIST, ECRYPT) and have a plan on how to make 2048-bit MOPD a MUST NOT before 2030. Not being able to forbid 1024-bit MOPD is this draft is a failure, let’s not repeat it.


- At least “AES-XCBC-PRF-128” and “256-bit random ECP group” should have references to point out which of the RFCs that are MTI.


Cheers,
John

-------------------------------------
John Mattsson
MSc Engineering Physics, MSc Business Administration and Economics
Ericsson IETF Security Coordinator 
Senior Researcher, Security