Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts

Paul Hoffman <> Wed, 26 February 2014 01:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D21DC1A0827 for <>; Tue, 25 Feb 2014 17:17:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.347
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QCpswiTsgxQ0 for <>; Tue, 25 Feb 2014 17:17:39 -0800 (PST)
Received: from (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by (Postfix) with ESMTP id 162B41A0825 for <>; Tue, 25 Feb 2014 17:17:39 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.8/8.14.7) with ESMTP id s1Q1HRIC027405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Feb 2014 18:17:28 -0700 (MST) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Paul Hoffman <>
In-Reply-To: <>
Date: Tue, 25 Feb 2014 17:17:26 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Paul Wouters <>
X-Mailer: Apple Mail (2.1874)
Cc: ipsec <>
Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Feb 2014 01:17:41 -0000

On Feb 25, 2014, at 4:50 PM, Paul Wouters <> wrote:

>>> Why is ESP auth NULL a MAY instead of a MUST NOT? The only reason I can
>>> think of for this is when we use a combined mode algorithm like AES-GCM.
>>> But in that case if AES-GCM is SHOULD+ it requires ESP auth null to be
>>> SHOULD+ as well?
>> That's covered in Section 3. The tables are the raw list of requirements; their use is covered in Section 3.
> That still does not address my point. If AES-GCM is rated FOO, then per
> definition since it uses ESP auth NULL, that ESP auth NULL should also
> be rated FOO. Right now AES-GCM is SHOULD+ and ESP auth NULL is MAY.

This seems to be calling for a relational table that I think is beyond where we want to go. If someone implements AES-GCM and doesn't implement ESP-NULL, Section 3 covers that.

>>> I'm also confused
>>> why the entries in 2.2 and 2.3 do not appear in the 2.5 summary.
>> I just checked, and I think the table of changes is correct. Which do you think is missing?

AES-CCM is MAY in both documents
AES-128-CBC is MUST in both documents
DES-CBC is now under discussion
HMAC-SHA1-96 is MUST in both documents
NULL is MAY in both documents

So, I'm still confused.

>>> Section 3 states:
>>>  If authentication on the IP header is needed in conjunction with
>>>  confidentiality of higher-layer data, then AH SHOULD be used in
>>>  addition to the transforms recommended above.
>>> How does AH protect the confidentiality of "higher-layer data" ?
>> It does not, of course. I think this sentence was trying to be about "if the higher-layer data already has its own confidentiality, then you can add AH". I think the sentence should be removed because it assumes that the device adding authentication knows whether or not the higher-layer service is using confidentiality correctly, and it can't know this.
> To me it seemed that "AH" needed to be "ESP"?

Even then, the sentence is about "the higher-layer data already has its own confidentiality", which I think is unknowable by an ESP or AH implementation. I think the sentence can safely be removed.

>>> Seciont 4:
>>> The text about "The Triple Data Encryption Standard (TDES) is obsolete"
>>> appears twice and could be consolidated?
>> The second one is about DES. :-)
> No higher up :)
> Section 3:
>   Triple-DES SHOULD NOT be used in any scenario in which multiple
>   gigabytes of data will be encrypted with a single key.  As a 64-bit
>   block cipher, it leaks information about plaintexts above that
>   "birthday bound" [M13].  Triple-DES CBC is listed as a MAY implement
>   for the sake of backwards compatibility, but its use is discouraged.
> Seciont 4.2:
>   The Triple Data Encryption Standard (TDES) is obsolete because of its
>   small block size; as with all 64-bit block ciphers, it SHOULD NOT be
>   used to encrypt more than one gigabyte of data with a single key
>   [M13].  Its key size is smaller than that of the Advanced Encryption
>   Standard (AES), while at the same time its performance and efficiency
>   is worse.  Thus, its use in new implementations is discouraged.

I admit that "usage guidance" and "rationale" overlap, but I think having the "please rethink 3DES" discussion twice is a positive.

--Paul Hoffman