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

Paul Wouters <paul@cypherpunks.ca> Tue, 25 February 2014 23:09 UTC

Return-Path: <paul@cypherpunks.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 336241A02F3 for <ipsec@ietfa.amsl.com>; Tue, 25 Feb 2014 15:09:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 RzBUIB-Pk6Pr for <ipsec@ietfa.amsl.com>; Tue, 25 Feb 2014 15:09:51 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1689D1A00C2 for <ipsec@ietf.org>; Tue, 25 Feb 2014 15:09:51 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0C56680D6D; Tue, 25 Feb 2014 18:09:49 -0500 (EST)
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s1PN9mEK028543; Tue, 25 Feb 2014 18:09:48 -0500
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Tue, 25 Feb 2014 18:09:48 -0500 (EST)
From: Paul Wouters <paul@cypherpunks.ca>
X-X-Sender: paul@bofh.nohats.ca
To: Yaron Sheffer <yaronf.ietf@gmail.com>
In-Reply-To: <C1A9B4B9-FABA-4EAB-B325-88DCB3F3D9CB@gmail.com>
Message-ID: <alpine.LFD.2.10.1402251615220.21879@bofh.nohats.ca>
References: <530CE583.6030801@gmail.com> <C1A9B4B9-FABA-4EAB-B325-88DCB3F3D9CB@gmail.com>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/eKItQry1RdNNzcgHeLG67-1JeW8
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: Tue, 25 Feb 2014 23:09:54 -0000

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

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

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

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

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?

Section 2.5:

I would put 2.5 as the introduction paragraph to 2.1. I'm also confused
why the entries in 2.2 and 2.3 do not appear in the 2.5 summary. Should
they be added with "-" in the Old Requirement, and their listing in the
New Requirement?

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

Seciont 4:

The text about "The Triple Data Encryption Standard (TDES) is obsolete"
appears twice and could be consolidated?

Section 4.3:

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

Paul