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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8B4D11A0311 for <>; Tue, 25 Feb 2014 16:17:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.053
X-Spam-Status: No, score=0.053 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_COM=0.553] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0kjp4wMCqJH3 for <>; Tue, 25 Feb 2014 16:17:52 -0800 (PST)
Received: from (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by (Postfix) with ESMTP id C106D1A030E for <>; Tue, 25 Feb 2014 16:17:52 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.8/8.14.7) with ESMTP id s1Q0HgTI024482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Feb 2014 17:17:43 -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 16:17:41 -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 00:17:54 -0000

On Feb 25, 2014, at 3:09 PM, Paul Wouters <> wrote:

>> On Feb 25, 2014, at 8:48 PM, Yaron Sheffer <> wrote:
>>      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: We
>>      should have last called the draft a while ago, and I apologize for the delay.
> Section 2.2:
> It lists NULL ESP as a MUST. Wasn't this a MUST a leftover from the old
> crypto export restrictions? While I think NULL ESP is a good debugging
> tool, and a good replacement for AH in general, I don't think this is
> really a MUST item (unless you would actually advise people to migrate
> from AH to ESP NULL, in which case I'll cheer on this MUST)

It is for systems that don't implement AH. We should probably say this explicitly in section 3.

> Why is DES-CBC a SHOULD NOT+ instead of a MUST NOT? Is there any sane
> modern IKE daemon that allows 1DES (or modp768)

The WG has never voiced a MUST NOT for this before. I'm fine with making that change if no one objects.

> Section 2.3:
> This does not list anything with md5. Is there another RFC that already
> discourages this use for IPsec? If so, can it be references in this
> document. If not, shouldn't we talk about an HMAC-MD5 downgrade to

HMAC-MD5 still gives 128 bits of strength, which in fact is more than the MUST-level HMAC-SHA1-96. It was a MAY in 4835; by not listing it here, it is still "MAY".

> [ Turns out that document is RFC 4835, but only mentioned at the
>  end. Should this document not Obsolete: 4835? ]

This document should indeed obsolete 4835. Good catch.

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

> Section 2.5:
> I would put 2.5 as the introduction paragraph to 2.1.

Bike shed.

> 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?

> Should
> they be added with "-" in the Old Requirement, and their listing in the
> New Requirement?

No, this is a table of differences.

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

> 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. :-)

> Section 4.3:
> This section is the only section that mentions MD5 and SHA1. Perhaps it
> should summarize or refer to RFC 4835?

I think it is better to make this document obsolete 4835 and keep the negative text.

--Paul Hoffman