Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt

Paul Hoffman <paul.hoffman@vpnc.org> Tue, 01 April 2014 21:24 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 D31251A09FB for <ipsec@ietfa.amsl.com>; Tue, 1 Apr 2014 14:24:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 LURncRKDYND0 for <ipsec@ietfa.amsl.com>; Tue, 1 Apr 2014 14:24:01 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6E65E1A09F2 for <ipsec@ietf.org>; Tue, 1 Apr 2014 14:24:01 -0700 (PDT)
Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s31LNt64023932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Apr 2014 14:23:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <alpine.LFD.2.10.1404011618560.7623@bofh.nohats.ca>
Date: Tue, 1 Apr 2014 14:23:52 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D69157CE-1CBA-4EF0-8C27-4C258A7263DA@vpnc.org>
References: <20140331224116.32271.49481.idtracker@ietfa.amsl.com> <alpine.LFD.2.10.1404011618560.7623@bofh.nohats.ca>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/1-Evewt11SBeSHyA9O5zJYYwSJQ
Cc: "ipsec@ietf.org WG" <ipsec@ietf.org>
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.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: <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: Tue, 01 Apr 2014 21:24:03 -0000

On Apr 1, 2014, at 1:46 PM, Paul Wouters <paul@nohats.ca> wrote:

> On Mon, 31 Mar 2014, internet-drafts@ietf.org wrote:
> 
>> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt
> 
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-esp-ah-reqts-03
> 
> So one of the changes is:
> 
> - SHOULD+ AES-GCM [RFC4106]
> + SHOULD+ AES-GCM with a 16 octet ICV [RFC4106]
> 
> While I'm happy with that change (I argued for it to not using the
> truncated ICV versions), the document now makes no statement about those
> other ICV variants. RFC 4106 states:
> 
> 	The ICV consists solely of the AES-GCM Authentication Tag.
> 	Implementations MUST support a full-length 16-octet ICV, and MAY
> 	support 8 or 12 octet ICVs, and MUST NOT support other ICV lengths.
> 
> Me personally, and one of the authors of 4106 (John Viega) would like to
> see those other ICV's moved to SHOULD NOT. Since these are MAY in 4106,
> and not mentioned in this draft, they would remain MAY.

That was the intention: MAY. "SHOULD NOT" somewhat indicates a belief that the crypto has degraded, and that is not the case here.


> I also wonder about:
> 
> 	"It is NOT RECOMMENDED to use ESP with NULL authentication
> 	 in conjunction with AH"
> 
> Why do we now say "NOT RECOMMENDED" instead of continuing to talk in
> RFC4835 terms? eg:
> 
> 	ESP with NULL authentication MUST NOT be used in conjunction
> 	with AH.
> 
> If we go through the effort of stating such deployments are insecure,
> which we do in the next line, we might as well clearly tell implementors
> not to do this. "not recommended" does not say "don't do this".

RFC 4835 does not say that ESP with NULL MUST NOT be used with AH. It waffles.

> language nits:
> 
> As a non-native english speaker, "efficacy" was not clear to me, and
> almost read as "efficiency". So I would change "undermines the efficacy
> of encryption". Maybe something like just "undermines the trustworthiness
> the encryption" (although that sounds a bit Colbert like :)
> 
> s/perfers/prefers

I'll make these changes in -04. It turns out I need to do a rev anyway because I forgot to list the new DES "MUST NOT" in the changes summary.

--Paul Hoffman