Comments on draft-ietf-ltans-dssc-04
1. The title of the document is: “Data Structure for Security
Suitabilities of Cryptographic
Algorithms”.
The document states that the data structure is independent of the
intended use (page 8);
therefore, it cannot be said if an algorithm is *suitable* for any
intended purpose. Note that
“Suitabilities” should always be used with the singular: Suitability.
Replace with: “Data Structure to Estimate the Validity Period of
Cryptographic Algorithms”.
2. The acronym DSSC should be changed into: DSEC (Data Structure to
Estimate
Cryptographic algorithms).
3. The start of the abstract is only related to digitally signed data.
However, the fourth use
case is about re-encryption, but such a use case is not mentioned in the
abstract. The abstract
should be extended to mention encryption.
4. This draft defines a data structure which estimates the validity
period of cryptographic
algorithms independently of the intended use. The text states in the
abstract: “This document
specifies a data structure that enables automated analysis of the
security suitabilities of
cryptographic algorithms”.
This sentence should be corrected. The document states that the data
structure is independent
of the intended use (page 8); therefore, it cannot be said if an
algorithm is *suitable* for any
intended purpose. See the comment on the security considerations section
for further
explanations.
Proposed replacement:
“This document specifies a data structure that enables an automated
estimation of the validity
period of a single cryptographic algorithm at a time. The automated
processing of a
cryptographic data structure that includes one or more cryptographic
algorithms needs to be
tailored to a specific use case and is outside the scope of this document”.
5. On page 5, the term "security suitability policy" is being used. The
data structure is a set of
rules which allows to estimate the validity period of various
cryptographic algorithms. The
wording "security suitability policy" should not be used, because the
word “suitable” implies
that the algorithm would be suitable in a specific context and there is
no such context.
Replace the term "security suitability policy” by “cryptographic
resistance policy”.
The word “suitable” should be replaced in many instances in this document.
6. In the requirements section (2.1), it is mentioned that the integrity
and authenticity of a
published "data structure" must be assured. Since the previous
requirement is source
authentication, this requirement should not be mandatory. In fact, the
document considers the
signature of the data structure as an option, which is fine.
7. In the requirements section (2.1), a requirement is missing: the date
of issue of the data
structure shall be indicated. In fact, the document considers the date
of issue as mandatory,
which is fine.
8. In the assumptions section (2.2), it is mentioned that "an algorithm
is valid if it is contained
in the current policy and the time of interest is within the validity
period". This assumption is
incorrect. The data structure should be usable to tell "until when" a
given algorithm was or
will be usable, instead of simply telling "valid".
When estimating the cryptographic resistance of an algorithm with this
data structure, the
output should not simply be "valid" or "invalid", but "valid until XXXX".
9. Section 3.12 is about the validity element. The last sentence of the
paragraph defines a
processing rule which is the following:
"If the end of the validity period is in the past, the algorithm is not
suitable".
This sentence should be replaced with:
"If the end of the validity period is in the past, the algorithm was
suitable until that date".
10. Section 5 is about "Processing".
The text states: “In the following, a process is described that can be
used to determine if an
algorithm was valid at a particular point of time”.
“Valid” is not the right word. The algorithm was resistant against
estimated attacks at a
particular point of time”.
Replace with: “In the following, a process is described that can be used
to determine if one
algorithm was resistant against real or estimated attacks at a
particular point of time”.
11. Section 5.3 states: "To determine if an algorithm is valid ...".
This sentence should be
changed into: "To determine the validity period of an algorithm...".
Similar changes need to
be made in the text that follows.
12. Section 5.5 mentions that if the algorithm is not valid, an error is
returned. It would be
more adequate to return the Evaluation elements so that a decision can
be made, which is
dependent both upon the context of use and the data structure where the
algorithm is being
used.
Both sentences from this section should be replaced by.
" If the algorithm is in the table, the Evaluation elements are returned.
Otherwise an error "algorithm unknown" is returned".
13. Section 6. This section should be expanded to warn the user that the
processing rules
described in section 5 are about *one* algorithm at a time
*independently of the use case*.
Depending upon the use case, if an algorithm is no more resistant at the
time of evaluation,
this may be no problem at all.
Let us take an example: an RSA signer's key of 900 bits is being used.
If an evaluation is
made in year 2015, this key size will probably be broken. Is the
algorithm unsuitable in 2015?
This fully depends upon the use case and upon the elements of the data
structure that are
evaluated. Example: if the signature was time-stamped with an RSA
signature key of 2048
bits, before an RSA key size of 900 bits was broken, then the data
structure is fine. If it was
not, the *data structure* is no more resistant at the time of evaluation.
Another example is the use of a MD5 hash function. If this hash function
is being used in a
data structure, but the data has been rehashed with SHA-256 before MD5
was "broken", then
the data structure is fine.
14. Section 8. The informative reference [ETSI-TS101903] is obsolete.
The last version is:
ETSI TS 101 903 V1.3.2 (2006-03).
15. Section 8. The informative reference [ETSI-TS102176-1-2005] is
obsolete. The last
version is: ETSI TS 102 176-1 V2.0.0 (2007-11).
16. Appendix A.1. It should be indicated that this appendix is informative.
17. Appendix A.1 is a specific use case. If a hash function in the inner
timestamp is no more
resistant, does it means that the whole structure is invalid ? If yes,
does ERS provides a way
to protect against this threat ? More explanations should be provided.
18. Appendix A.2. It should be indicated that this appendix is normative.
19. Appendix B. It should be indicated that this appendix is normative.
20. Appendix C. It should be indicated that this appendix is informative.
21. Appendix D. It should be indicated that this appendix is normative.
Denis