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

Paul Wouters <paul@nohats.ca> Tue, 01 April 2014 20:46 UTC

Return-Path: <paul@nohats.ca>
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 433D11A08C2 for <ipsec@ietfa.amsl.com>; Tue, 1 Apr 2014 13:46:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 LLD4KrwYzYeD for <ipsec@ietfa.amsl.com>; Tue, 1 Apr 2014 13:46:22 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id B220E1A08C1 for <ipsec@ietf.org>; Tue, 1 Apr 2014 13:46:22 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1C01D813B5 for <ipsec@ietf.org>; Tue, 1 Apr 2014 16:46:18 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1396385178; bh=ers04TDAHb8W839OVipq/nHejR3458KJuC/l05fIR8o=; h=Date:From:To:Subject:In-Reply-To:References; b=Ppd5rrAvTRUmXibDswP3A9KEAQQhSiqQfvXKDMp0KwWY+4Ct3IzNHd9/Dgz+lzViG +PqCEZRRnkXAqk+PxcoWPWmMGKLnqwAkqTZiLo/+yBlDAxALVV59vz7QJFeuMQhaVA Lk0o/75c+5ThMPRyfLEl5eZYzR+oA1rZWt42sxw0=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s31KkFVu020384 for <ipsec@ietf.org>; Tue, 1 Apr 2014 16:46:17 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Tue, 01 Apr 2014 16:46:15 -0400
From: Paul Wouters <paul@nohats.ca>
To: "ipsec@ietf.org WG" <ipsec@ietf.org>
In-Reply-To: <20140331224116.32271.49481.idtracker@ietfa.amsl.com>
Message-ID: <alpine.LFD.2.10.1404011618560.7623@bofh.nohats.ca>
References: <20140331224116.32271.49481.idtracker@ietfa.amsl.com>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/soB2QBkIc6GweLp_Ov-Zd2JXGWY
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 20:46:25 -0000

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.

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".


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

Paul