Reviewer: Yaron Sheffer
Review result: Has Nits
This is a well written draft, with just the right amount/level of detail for
(what I would imagine is) the target audience.
- "There are also applications where future checks on past authenticity play a
role, such as long-lived digital signatures on legal documents." I'm not sure
this is a good motivation here, since such infrastructure should already
support crypto agility, such as transition from RSA-1024 to RSA-2048 (e.g. by
providing manual services to update signatures). However this may be a good
place to discuss long-term signatures that are at the heart of PKI, namely
intermediate PKI certs that often have long validity, sometimes as long as 10
years. (The comment also applies to Sec. 1.2.2).
- "It is intended as a resource for designers and implementers of hybrid
signature schemes" - I'm not sure we have the requisite consensus, but I would
have liked to see here something about IETF process. For example, "We expect
the IETF to standardize particular hybrid signature schemes for some of its
protocols." Creating hybrid schemes is difficult and we don't want a plethora
of them.
- "are one reason for to consider" - redundant "for"?
- Definition of stripping attack: you explain the mechanics of the attack, but
not the semantics, i.e. why is this an attack. In many cases if Alice signs M
("I owe Bob $10") with two different algorithms, a stripping attack will result
in the same message, signed by the same entity, and completely valid (assuming
for example the verifier trusts one of the component signatures). Edit: an
explanation is provided later but would be more useful at this point.
- "it is more likely that vulnerabilities will represent a weakening of
security than a full "break"." - I'm not sure this follows from the existence
of intensive analysis. This statement needs further clarification or past
examples to support it.
- "Note that unlike EUF-CMA security, SUF-CMA security of the hybrid scheme may
rely on SUF-CMA security of both component schemes achieving SUF-CMA, depending
on the hybridization approach." - something is not quite right with this
sentence.
- Terminology: the acronyms EUF-CMA, SUF-CMA need to be explained or a
reference given to their definitions. Similarly "functional transition" and
"security transition".
- The term "backward(s) compatibility" appears to be used in a very specific,
technical sense, but again is used before it is defined. Ironically "backwards
compatibility" needs a forward reference.
- "Backwards compatibility may be further decomposed to subcategories where
component key provenance is either separate or hybrid so as to support
implementations that cannot recognize (and/or process) hybrid signatures or
keys" - I find this categorization strange, since legacy verifiers by
definition can only process component signatures (and keys) that are separate.
- Notation: in the Terminology section commas are used in the regular manner to
denote function parameters, "Verify(pk, sig, m)", but later on commas are used
to denote concatenation, "Sigma_1.Sign(hybridAlgID, m)". A more standard
notation would have been friendlier, "Sigma_1.Sign(hybridAlgID || m)".
- The "need for approval" section is very strange in an IETF document,
especially since none of the authors is (as far as I can tell) authorized to
speak for NIST. It would be a lot more useful if NIST provided official
clarifications about the points that were identified as open.
- "This vulnerability is particularly an issue among concatenated or nested
hybrid signature schemes when component verification." - this sentence is
incomplete.
- "It should be noted that weak non-separability is insufficient for mitigating
risks of component forgeries." - please add a section number to the reference
to the Composite draft.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
