On Feb 25, 2014, at 3:09 PM, Paul Wouters <[email protected]> wrote:
>> On Feb 25, 2014, at 8:48 PM, Yaron Sheffer <[email protected]> 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 _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
