Additional XML Security Uniform Resource Identifiers (URIs)
Note: This ballot was opened for revision 09 and is now closed.
(Sean Turner) Yes
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
Comment (2013-02-26 for -09)
I agree with Adrian and further wonder why, if we need an RFC, this document does not simply update RFC4051 rather than apparently duplicating much of its material.
(Gonzalo Camarillo) No Objection
(Benoit Claise) No Objection
Comment (2013-02-28 for -09)
No really sure why the acknowledgements section is in the front? I thought that we had guidelines for section order somewhere, but I can't find them right now... So this comment is more about my own question: do we actually have requirements regarding the sections order? I'll shoot an email now to the RFC editor notes. Note: RFC 4051 had the acknowledgements section at the usual place.
(Wesley Eddy) No Objection
(Adrian Farrel) No Objection
Comment (2013-02-26 for -09)
The subject material of this document is so far from my competence that I will rely on the Security ADs to provide the necessary reviews. I have a meta question for them which is: does the publication of this document as a PS imply IETF endorsement for the use of these algorithms? And wouldn't it be easier to turn this into an IANA registry to avoid frequent updates? While reading the document, I found a few nits and questions: --- Section 1 Informational or Standards Track documents Is that s/documents/RFCs/ ? --- Section 1 All of these are now W3C Recommendations and IETF Informational or Standards Track documents. The table that follows is ambiguous since it looks like maybe [XMLENC] does not have an RFC equivalent. --- Section 1 s/[XMLENC}/[XMLENC]/ --- Section 2.1.5 NIST has recently completed a hash function competition for an alternative to the SHA family. The Keccak-f algorithm was selected [Keccak]. This section is a space holder and reservation of URIs for future information on Keccak use in XML security. I really don't understand this! It seems to say - Here are the URIs for SHA-3 - NIST says don't use SHA-3 - This document will be updated to include URIs for Keccak. That seems odd to me. Why not: - Include URIs for SHA-3 but say you expect their use to be deprecated soon - Include a separate section for Keccak - If no URIs yet exist for Keccak, then don't include them. --- 2.2.1 Although cryptographic suspicions have recently been cast on MD5 for use in signatures such as RSA-MD5 below, this does not affect use of MD5 in HMAC [RFC6151]. "suspicions" seems to rather underplay the situation, doesn't it? The last paragraph of Section 2 of RFC 6151 says it all.
(Stephen Farrell) (was Discuss) No Objection
Comment (2013-02-28 for -09)
was discuss: I don't get why RIPEMD, Whirlpool, ESIGN, PSEC-KEM and SEED are all included, I do see some were in 4051 but I don't know that any "substantial" community makes use of each of these. I think that you therefore need to include a statement something like: "Inclusion of an algorithm in this document has no implication that the authors or the IETF consider those algorithms fit for any purpose. At present, specific protocol documents specify the algorithms that are mandatory to implement for that protocol. As security considerations for algorithms are constantly developing those are also documented in relevant protocol specifications. This specification therefore simply provides the URIs and defines relevant formatting for when those URIs are used." - general: it'd be far better if you could include test vectors for more/all algorithms. - I think this document needs to be, but is not, clear as to whether its making any new RECOMMENDations regarding use or non-use of algorithms for IETF applications that make use or URIs for algorithm identifiers. If it is makeing new recommendations then more review would be needed. If its just listing the URIs and making comments in passing, then the use of 2119 terms for innovative algorithm recommendations is not appropriate and nor are qualitative assessments of algorithm strength. If you want to make new recommendations then I think we need text that says that explicitly and a new IETF LC that makes that clear. If you want to just have an inclusive list of well-defined URIs (which I think is better) then some text changes in sections listed below are needed. Note that if some existing IETF consensus document has already got 2119 terms about use of an algorithm then its perfectly fine to quote that, e.g. say that "RFC foo, section bar, says that 'MD5 is NOT RECOMMENDED for use in signatures'" etc. but I'd like all such statements to be quotes so that we know that we're not innovating here, without proper review. These are the places I spotted that need looking at based on the above: - 2.1.1 "NOT RECOMMENDED" - 2.6.3 - "the implementation of camellia is OPTIONAL" - 2.6.2 - please delete claims that camellia is "efficient and secure" or else add similar descriptions to all other sections. (Same for SEED in 2.6.5) - 2nd para of section 6 - intro: what is the definition of "substantial interest" which seems to be used as the criterion for inclusion here? I think that'd be better changed, e.g. to say that you're aiming to be inclusive here, but that that has no significance in terms of algorithm strength or suitability. - intro: refers to "Draft Standard" which doesn't exist any more. The reference is historical but maybe ought be fixed? (I don't care much, but maybe someone does.) - intro: I'd suggest you add the example that sha-256 is defined in XMLENC (5.8.2) and hence is not here. - 1.1, I think you could say here that this isn't innovating in terms of alg strength etc and that all 2119 terms on that topic are just quotes from existing RFCs. - 2.1.1 and elsewhere: when you say that the encoding of the output "shall be" something, is that intended as a 2119 term? I think it ought and would be better as SHALL (or MUST) since people do get these subtly wrong all the time. - 2.1.1 and elsewhere: you assume I know what a DigestValue element is. Maybe you ought say that camel case element names are all from either xmldsig or xmlenc (or whereever they are from). That's almost obvious enough, but you never know there might be another DigestValue definition somewhere else that'd confuse someone. - 2.1.2 - suggest adding a reference to where sha-256 is defined in XMLENC. Similarly for 2.1.3 - 2.1.5 - wouldn't it be better to make NIST's sha-3 FIPS a normative reference and add the details needed here for base64 encoding of outputs and just let this wait on the FIPS to issue before the RFC does? If not, won't someone have to do that then anyway? - 2.3.7 - the title of this section is wrong since it doesn't only define sha-1 stuff - 3.2 - I assume retrieval is via HTTP - where's that stated? Is the "Type attribute" mentioned in the last sentence meant to be a Content-Type or what? I think you ought clarify. - wouldn't section 4 be better put into an IANA registry? Why not? - references: XMLENC 1st URL gives a 404, why not just use the 2nd? h
(Brian Haberman) No Objection
(Russ Housley) (was Discuss) No Objection
Comment (2013-02-28 for -09)
The Gen-ART Review by Suresh Krishnan on 23-Feb-2013 raised two concerns about the language associated with MD5. In addition, I have a concern with the language associated with SHA-384. In Section 2.1.1, the following text is a bit misleading as it looks like this document is taking a stance on the use of MD5: > > Use of MD5 is NOT RECOMMENDED [RFC6151]. > Suresh proposed this rewording, and I agree with it: > > Please note that the use of MD5 is no longer recommended for digital > signatures [RFC6151]. In Section 2.3.1, the following text is concerning to me: > > Because it takes roughly the same amount of effort to compute a > SHA-384 message digest as a SHA-512 digest and terseness is usually > not a criteria in XML application, consideration should be given to > the use of SHA-512 as an alternative. > There are more criteria than hash size when selecting a hash algorithm. This is just one consideration, and this advice ignores all other aspects of the decision. Note that Suite B that is being advocated by NSA uses SHA-384 (not SHA-512) at the higher of the two security strengths. So, I suggest that a more complete picture be included or that this advice be removed. In the Security Considerations, this test duplicates the RFC 6151. > > Due to computer speed and cryptographic advances, the use of MD5 as > a DigestMethod or in the RSA-MD5 SignatureMethod is NOT RECOMMENDED. > The cryptographic advances concerned do not affect the security of > HMAC-MD5; however, there is little reason not to go for one of the > SHA series of algorithms. > I think that a warning might be better. For example, this text comes from RFC 2630: > > Implementers should be aware that cryptographic algorithms become > weaker with time. As new cryptoanalysis techniques are developed and > computing performance improves, the work factor to break a particular > cryptographic algorithm will reduce. Therefore, cryptographic > algorithm implementations should be modular allowing new algorithms > to be readily inserted. That is, implementers should be prepared for > the set of mandatory to implement algorithms to change over time. > Taking the ideas from this paragraph from RFC 2630 and a reference to RFC 6151 seems like a very good way to make the point about MD5 and make it clear that all algorithms age.