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

[Paul Wouters <[e-mail]>]

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

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