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

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 26 February 2014 01: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 D21DC1A0827 for <ipsec@ietfa.amsl.com>; Tue, 25 Feb 2014 17:17:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCpswiTsgxQ0 for <ipsec@ietfa.amsl.com>; Tue, 25 Feb 2014 17:17:39 -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 162B41A0825 for <ipsec@ietf.org>; Tue, 25 Feb 2014 17:17:39 -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 s1Q1HRIC027405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Feb 2014 18:17:28 -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.1402251938070.24298@bofh.nohats.ca>
Date: Tue, 25 Feb 2014 17:17:26 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <F228881D-B2EA-4EA2-ABE2-C9A0528F870A@vpnc.org>
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> <alpine.LFD.2.10.1402251938070.24298@bofh.nohats.ca>
To: Paul Wouters <paul@cypherpunks.ca>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/7ZrDm5rT2TlWoPJXsalumk7v7hk
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 01:17:41 -0000

On Feb 25, 2014, at 4:50 PM, Paul Wouters <paul@cypherpunks.ca> 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, AES-128-CBC, DES-CBC, HMAC-SHA1-96, NULL ?

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