|
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
|