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

[Paul Hoffman <[e-mail]>]

On Feb 25, 2014, at 3:09 PM, Paul Wouters <[e-mail]> wrote:

>> On Feb 25, 2014, at 8:48 PM, Yaron Sheffer <[e-mail]> 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