[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D Action:draft-ietf-ltans-dssc-04.txt
Denis Pinkas schrieb:
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
We don't agree with your suggested title. The data structure is used to
express policies which are *not* independent of the intended use (see
the definition in the terminology). For this reason, the data structure
contains the "Usage" element. The data structure itself can be used in
different use cases. But one policy doesn't necessarily express that an
algorithm is suitable for any intended purpose.
We will try to clarify this issue in the draft.
For the above mentioned reasons, will will keep the acronym DSSC and
will only change "Suitabilities" to "Suitability".
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.
OK, we will try to include this in the abstract.
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.
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.
Good point, we will add this requirement.
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".
We think the assumption is correct. An algorithm is valid or suitable if
it is contained in the current policy and the time of interest
is within the validity period. Of course the data structure is able to
tell until when an algorithm was or will be valid, but this has nothing
to do with this assumption.
In the "processing" section, we give the time of interest as input (i.e.
we ask if an algorithm is or was valid at this point of time; we don't
ask until when an algorithm was or will be valid).
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
This sentence should be replaced with:
"If the end of the validity period is in the past, the algorithm was
suitable until that date".
In our context we use "valid" and "suitable" synonymic to each other. We
will try to clarify this in the terminology.
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”.
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.
We don't see the need for this warning. The data structure is solely
about evaluating algorithms, not about evaluating data structures which
use these algorithms. To take your example, the data structure is used
to verify if RSA with 900 bit was valid at the point of time when the
signature was time-stamped with 2048 bit key.
We think the document sufficiently illustrate this issue.