On Feb 25, 2014, at 4:50 PM, Paul Wouters <[email protected]> wrote:
>>> 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. > > 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. 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. >>> 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? > > 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. >>> 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. > > 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. > >>> 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. :-) > > 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 admit that "usage guidance" and "rationale" overlap, but I think having the "please rethink 3DES" discussion twice is a positive. --Paul Hoffman _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
