Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-00.txt
Tero Kivinen <kivinen@iki.fi> Tue, 03 November 2015 00:42 UTC
Return-Path: <kivinen@iki.fi>
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 5A3411AC39E for <ipsec@ietfa.amsl.com>; Mon, 2 Nov 2015 16:42:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
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 omREAOBjBbqe for <ipsec@ietfa.amsl.com>; Mon, 2 Nov 2015 16:42:06 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 16F481AC39F for <ipsec@ietf.org>; Mon, 2 Nov 2015 16:42:05 -0800 (PST)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id tA30g1ZK007678 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Nov 2015 02:42:01 +0200 (EET)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id tA30g1fe026390; Tue, 3 Nov 2015 02:42:01 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID: <22072.729.246850.109764@fireball.acr.fi>
Date: Tue, 03 Nov 2015 02:42:01 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: John Mattsson <john.mattsson@ericsson.com>
In-Reply-To: <8E795DD4-DF63-452D-96AA-F6D7BE232530@ericsson.com>
References: <8E795DD4-DF63-452D-96AA-F6D7BE232530@ericsson.com>
X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd)
X-Edit-Time: 18 min
X-Total-Time: 25 min
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipsec/57KGFbzMDpz2Jjc-wGtIdjy6wQE>
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
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: Tue, 03 Nov 2015 00:42:08 -0000
John Mattsson writes: > - BTW, What does it mean that an algorithm like ENCR_RC5 is not > listed, does that mean “MAY”, “MUST NOT”, or “totally unspecified”? It means this document does not specify whether they should be used or not, i.e. MAY. > - 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”. This document just states the fact, the actual MUST NOT is in the RFC5282, and I do not think we should repeat that here. I.e. this text just states the fact of life based on the RFC5282, but does not make any requirements. > - 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. The IoT devices talk to each other, but also to more general purpose servers, i.e., in your home you might have some kind home area network server, where all the IoT devices connect to. In that case those bigger boxes do want to implement the same AES_CCM_8 just so that those IoT devices which didn't implement anything else can talk to them. I.e. I think it is good thing to require real systems to have SHOULD for the AES_CCM_8. Of couse if your implementation is never expected to talk to IoT devices, then that is good reason to go against the SHOULD and leave the AES_CCM_8 implementation out. > - 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+. That depends how you calculate the securities of the Diffie-Hellman groups. If you check RFC3526 that gives two strengh estimates for 2014-bit group, 110 and 160 bits. The 160 bit strength takes also account the memory prices in the calculations, the 110 assumes memory is free, and CPU cost is only thing that matters. > 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. I think we are going to replace this document several times before 2030. We actually should have replaced this already few years ago, so this update is already bit late, but I would assume we might make new version after we get those new EC groups now being defined to the implementations. On the other hand there are lots of people still running IKEv1, so getting them to implementations might get time. > Not being able to forbid 1024-bit MOPD is this draft is a failure, > let’s not repeat it. We should move it to MUST NOT in next update, and then we can also revisit the discussion of 2048-bit MODP group. -- kivinen@iki.fi
- [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis… internet-drafts
- Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc430… Sean Turner
- Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc430… John Mattsson
- Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc430… Tero Kivinen
- Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc430… John Mattsson
- Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc430… Yoav Nir
- Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc430… Paul Wouters
- Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc430… Paul Wouters
- Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc430… Tero Kivinen