[IPsec] WGLC comments: draft-ietf-ipsecme-esp-ah-reqts

"Black, David" <david.black@emc.com> Sat, 08 March 2014 13:37 UTC

Return-Path: <david.black@emc.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id D12691A0236 for <ipsec@ietfa.amsl.com>; Sat, 8 Mar 2014 05:37:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.548
X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jLmf8skRhK_m for <ipsec@ietfa.amsl.com>; Sat, 8 Mar 2014 05:37:54 -0800 (PST)
Received: from mailuogwhop.emc.com (mailuogwhop.emc.com []) by ietfa.amsl.com (Postfix) with ESMTP id AAE071A0233 for <ipsec@ietf.org>; Sat, 8 Mar 2014 05:37:54 -0800 (PST)
Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com []) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s28DbnEH010876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ipsec@ietf.org>; Sat, 8 Mar 2014 08:37:49 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s28DbnEH010876
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1394285869; bh=9UZgHV08jc+Nl+Elt2UGO1QNpUw=; h=From:To:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=v5/X2yeAsFdp8lhytXxDBBcWE/IKric9JZSdQMY2hdb5JIULHsr+XRyOe9OYybQR1 BM3cigo5FG07nbv69GKr26AHz/xL2cKcsb6j2TVkYuSIe29Ez308AtsjNVBAGwdAaX JocgJjoKryQJMfS27hb1k9C6Dy77hQZxVnav86ms=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s28DbnEH010876
Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com []) by maildlpprd02.lss.emc.com (RSA Interceptor) for <ipsec@ietf.org>; Sat, 8 Mar 2014 08:37:35 -0500
Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com []) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s28DbZeA024900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <ipsec@ietf.org>; Sat, 8 Mar 2014 08:37:35 -0500
Received: from mx15a.corp.emc.com ([]) by mxhub06.corp.emc.com ([]) with mapi; Sat, 8 Mar 2014 08:37:34 -0500
From: "Black, David" <david.black@emc.com>
To: ipsec <ipsec@ietf.org>
Date: Sat, 8 Mar 2014 08:37:32 -0500
Thread-Topic: WGLC comments: draft-ietf-ipsecme-esp-ah-reqts
Thread-Index: Ac86047BjkDfaOGDRaOWLC9jA1GuYg==
Message-ID: <8D3D17ACE214DC429325B2B98F3AE71206CF439363@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com
X-RSA-Classifications: public
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Rx7YNc8N1ZcLRhODbWbrEcFPbXk
Subject: [IPsec] WGLC comments: draft-ietf-ipsecme-esp-ah-reqts
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: <http://www.ietf.org/mail-archive/web/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: Sat, 08 Mar 2014 13:37:57 -0000

The draft looks very good.  Aside from my previous comment on 256-bit
AES keys, I want to +1 three things I've seen in this discussion:

	- DES should be "MUST NOT"
	- "SHOULD NOT-" is a better keyword than "SHOULD NOT+"
	- NULL authentication for use with AES GCM should be at
		least "SHOULD+" because AES GCM is "SHOULD+".

If the intent is to cover the latter (NULL authentication) in
Section 3, then I suggest adding text to section 2.3 to point this out.

I have no strong opinion on ICV size for GCM and GMAC, but I am interested
in the outcome as an author of the Block Storage IPsec profile update
(draft-ietf-storm-ipsec-ips-update-04).  That draft does not currently
express requirements on ICV length.  That draft's in Authors 48 hours at
the moment as part of the entire iSCSI draft cluster, and it could be held
to apply the ICV length outcome determined here if that were deemed important.

> -----Original Message-----
> From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer
> Sent: Tuesday, February 25, 2014 1:49 PM
> To: ipsec
> Subject: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
> Hi, this is to start a 2-week working group last call on the revised
> Algorithm Implementation Requirements document, ending March 11. The
> draft is at:
> http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01. We should
> have last called the draft a while ago, and I apologize for the delay.
> The changes from the existing requirements are listed in Sec. 2.5 of the
> draft, but most of this (rather short) document is new and describes the
> rationale for the choice of algorithms and requirement levels.
> Please read this draft and send any comments to the WG mailing list,
> even if the comments are "I see no problems". Comments such as "I do not
> understand this part" or "this part could be explained better in this
> way" are particularly useful at this point.
> Thanks,
>      Yaron
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec