On Feb 25, 2014, at 8:48 PM, Yaron Sheffer <yaronf.i...@gmail.com> 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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
