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

From: Yaron Sheffer <[email-masked]>
Date: Tue, 25 Feb 2014 20:48:35 +0200

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.

The changes from the existing requirements are listed in Sec. 2.5 of the 
draft, but most of this (rather short) document is new and describes the 
rationale for the choice of algorithms and requirement levels.

Please read this draft and send any comments to the WG mailing list, 
even if the comments are "I see no problems". Comments such as "I do not 
understand this part" or "this part could be explained better in this 
way" are particularly useful at this point.

Thanks,
     Yaron

---

From: Yoav Nir <[email-masked]>
Date: Tue, 25 Feb 2014 22:27:07 +0200

Hi

I think this document is ready. 

A quick glance at the tables in section two lead me to ask some questions:
Why is DES singled out, while things like HMAC-MD5 are not discouraged?
Why is there no algorithm diversity?
Why is HMAC-SHA-256 not there?

However, reading section 4 answered all of those questions, so I think it’s clear. The only nit I can find is that “+” means “in the future this will be more encouraged”, and “-“ means “in the future this will be less encouraged, except for “SHOULD NOT+”. It might be more consistent if that was called “SHOULD NOT-“. But that is nit-picking, as the text does explain what that means. 

Yoav

On Feb 25, 2014, at 8:48 PM, Yaron Sheffer <[email-masked]> 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.
> 
> The changes from the existing requirements are listed in Sec. 2.5 of the draft, but most of this (rather short) document is new and describes the rationale for the choice of algorithms and requirement levels.
> 
> Please read this draft and send any comments to the WG mailing list, even if the comments are "I see no problems". Comments such as "I do not understand this part" or "this part could be explained better in this way" are particularly useful at this point.
> 
> Thanks,
>    Yaron
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Wouters <[email-masked]>
Date: Tue, 25 Feb 2014 18:09:48 -0500 (EST)

>       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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 25 Feb 2014 16:17:41 -0800

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

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

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

>  end. Should this document not Obsolete: 4835? ]

This document should indeed obsolete 4835. Good catch.

> But in that case if AES-GCM is SHOULD+ it requires ESP auth null to be

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

No, this is a table of differences.

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

> appears twice and could be consolidated?

The second one is about DES. :-)

> 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

---

From: Paul Wouters <[email-masked]>
Date: Tue, 25 Feb 2014 19:50:38 -0500 (EST)

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

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

Good.

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

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

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

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

> 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 beca…

To me it seemed that "AH" needed to be "ESP"?

> 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 think it is better to make this document obsolete 4835 and keep the negative text.

Fine with me,

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 25 Feb 2014 17:17:26 -0800

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

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

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

>   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

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 26 Feb 2014 11:07:11 +0400

Hi Paul,

> It is for systems that don't implement AH. We should probably say this 

I don't think it is limited for those systems only.
You may implement AH, but yon cannot use it
everywhere, as it is not compatible with NATs.
And ESP-NULL with Auth is the only substitute there.
So, it must be MUST for any system.

Regards,
Valery Smyslov.

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 26 Feb 2014 10:14:59 +0200

(Hats off)

+1 on making single-DES CBC a MUST NOT.

	Yaron

---

From: Paul Wouters <[email-masked]>
Date: Wed, 26 Feb 2014 08:20:37 -0500 (EST)

> So, it must be MUST for any system.

Why did we not kill AH all together when Schneier and Ferguson told us so? :P
But you are right. Perhaps some text along the line of:

 	ESP-NULL offers the same protection as AH, but is more widely
 	accepted and functional compared to AH. AH does not work through
 	NATs and is not implemented in every IPsec stack. AH requires
 	firewall rules different from ESP causing it to get accidentally
 	filtered.  ESP-NULL is also used in performance testing as
 	a benchmark against ESP encryption algorithms. ESP-NULL should
 	never be automatically selected as part of IKE unless explicitely
 	configured as the only ESP encryption algorithm.

Paul

---

From: Stephen Kent <[email-masked]>
Date: Wed, 26 Feb 2014 10:22:22 -0500

Paul,

>> Algorithm Implementation Requirements
>> document, ending March 11. The draft is at: 
>> http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01. We
I think we do want folks to migrate from AH to ESP/NULL. That's why we
made support for AH a MAY a while ago.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 26 Feb 2014 10:24:49 -0500

Paul,
> But you are right. Perhaps some text along the line of:
perhaps because they were wrong.

ESP-NULL offers better performance than AH and so it is desirable in
most cases. But, AH has been specified by some protocols and we don't
want to undermine their choice by killing it.

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 28 Feb 2014 13:43:28 +0200

> +1 on making single-DES CBC a MUST NOT.

Agree on that. (And I still need to read the whole document, I am way
too much behind with my IPsecME WG draft reading).

-- 
[email-masked]