On Tue, 25 Feb 2014, Paul Hoffman wrote:
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.
Ahh, I'm okay with that if we can make that clarification.
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.
Good.
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.
Section 2.5:
I would put 2.5 as the introduction paragraph to 2.1.
Bike shed.
Sure :) It just seems that the 2.5 listing is the essential core of the
document. I'm fine if you prefer green.
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 ?
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"?
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.
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.
Fine with me,
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
