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

Paul Wouters <paul@cypherpunks.ca> Wed, 26 February 2014 00:50 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 8DFBC1A01D5 for <ipsec@ietfa.amsl.com>; Tue, 25 Feb 2014 16:50:55 -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 1IC4OpY9_ONL for <ipsec@ietfa.amsl.com>; Tue, 25 Feb 2014 16:50:51 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB2B1A0347 for <ipsec@ietf.org>; Tue, 25 Feb 2014 16:50:51 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8D0D980D6D; Tue, 25 Feb 2014 19:50:49 -0500 (EST)
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s1Q0ocZe011720; Tue, 25 Feb 2014 19:50:49 -0500
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Tue, 25 Feb 2014 19:50:38 -0500 (EST)
From: Paul Wouters <paul@cypherpunks.ca>
X-X-Sender: paul@bofh.nohats.ca
To: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <7722BB5C-67E3-4A26-B767-D31FA122ABFB@vpnc.org>
Message-ID: <alpine.LFD.2.10.1402251938070.24298@bofh.nohats.ca>
References: <530CE583.6030801@gmail.com> <C1A9B4B9-FABA-4EAB-B325-88DCB3F3D9CB@gmail.com> <alpine.LFD.2.10.1402251615220.21879@bofh.nohats.ca> <7722BB5C-67E3-4A26-B767-D31FA122ABFB@vpnc.org>
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/cnrmL01FTeI6HYIQlzSrBJD3CVo
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:50:55 -0000

On Tue, 25 Feb 2014, Paul Hoffman wrote:

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

Ahh, I'm okay with that if we can make that clarification.

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

Good.

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

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

Sure :) It just seems that the 2.5 listing is the essential core of the
document. I'm fine if you prefer green.

>> 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, AES-128-CBC, DES-CBC, HMAC-SHA1-96, NULL ?

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

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



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

Fine with me,

Paul