[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D Action:draft-ietf-ltans-dssc-04.txt


Comments inline...

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

Cryptographic Algorithms”.
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.
2. The acronym DSSC should be changed into: DSEC (Data Structure to Estimate Cryptographic algorithms).
For the above mentioned reasons, will will keep the acronym DSSC and will only change "Suitabilities" to "Suitability".
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.

see above
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.


OK
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 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". 


OK.




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”.
In our context we use "valid" and "suitable" synonymic to each other. We will try to clarify this in the terminology.
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.




Thomas