I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-keyprov-dskpp-10.txt
Reviewer: Brian Carpenter
Review Date: 2010-04-22
IETF LC End Date: 2010-04-26
IESG Telechat date:
Summary: Almost ready, one issue about algorithms.
--------
Note: This is a long draft and I am not a cryptography or XML expert. I do not
claim to have reviewed the draft in detail.
Major issue:
------------
"3.4.3. The DSKPP Message Hash Algorithm
When sending its last message in a protocol run, the DSKPP server
generates a MAC that is used by the client for key confirmation.
...
d. The resultant string is hashed using SHA-256 in accordance with
[FIPS180-SHA]."
I am concerned that this is rigidly bound to SHA-256. What happens when
SHA-256 goes the way of MD-5? Shouldn't this be a pluggable algorithm?
In fact there's another similar issue a few lines earlier:
"For the purposes of this document, the secret key k MUST be at least
16 octets long."
What would happen if that minimum needs to be raised?
Looking at Section 9 (Conformance Requirements), which BTW seems to be
extremely useful to implementors, I get the feeling that the point I'm
raising is a bit more general. What is the method for adding and deprecating
crypto algorithms in DSKPP? If the only method is by bumping up the DSKPP
version number, is that going to be a blocking problem in years to come?
Maybe Section 1.2 (Versions) should say something about the intent
and methodology for versioning the protocol and its range of algorithms.
(Full disclosure: I'm exercised about this as an author of
draft-iab-extension-recs, in particular because of a pertinent recent
comment that it "should specifically note that any protocol using
cryptography needs to be designed to be algorithm-independent.")
Nit:
----
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'SHOULD not' in this paragraph:
If keys generated in DSKPP will be associated with a particular...
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
