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

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 26 February 2014 00:17 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 8B4D11A0311 for <ipsec@ietfa.amsl.com>; Tue, 25 Feb 2014 16:17:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.053
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kjp4wMCqJH3 for <ipsec@ietfa.amsl.com>; Tue, 25 Feb 2014 16:17:52 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C106D1A030E for <ipsec@ietf.org>; Tue, 25 Feb 2014 16:17:52 -0800 (PST)
Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (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 paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] 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.1402251615220.21879@bofh.nohats.ca>
Date: Tue, 25 Feb 2014 16:17:41 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <7722BB5C-67E3-4A26-B767-D31FA122ABFB@vpnc.org>
References: <530CE583.6030801@gmail.com> <C1A9B4B9-FABA-4EAB-B325-88DCB3F3D9CB@gmail.com> <alpine.LFD.2.10.1402251615220.21879@bofh.nohats.ca>
To: Paul Wouters <paul@cypherpunks.ca>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/1CRi0XOYwZ8fXL6EUhF5RLiVJLs
Cc: ipsec <ipsec@ietf.org>
Subject: Re: [IPsec] Working Group Last Call: 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: Wed, 26 Feb 2014 00:17:54 -0000

On Feb 25, 2014, at 3:09 PM, Paul Wouters <paul@cypherpunks.ca> wrote:

>> On Feb 25, 2014, at 8:48 PM, Yaron Sheffer <yaronf.ietf@gmail.com> 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: 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.
> 
> 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
> SHOULD NOT+ ?

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