Additional XML Security Uniform Resource Identifiers (URIs)
draft-eastlake-additional-xmlsec-uris-10

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[1600] 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.

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.

  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.

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

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.