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

["TS Glassey" <tglassey@xxxxxxxxxxxxx>]

Guys
----- Original Message ----- 
From: "Thomas Kunz" <thomas.kunz@xxxxxxxxxxxxxxxxx>
To: <denis.pinkas@xxxxxxxx>
Cc: "IETF LTANS" <ietf-ltans@xxxxxxx>
Sent: Wednesday, October 29, 2008 3:37 AM
Subject: 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.

I love the title it means that there is a likelyhood that Deni's masterpiece 
is already covered by my Patent issuance. However I also suggest changing 
it.

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

Agreed

> The data structure itself can be used in
> different use cases.

As a policy control object - with a reliable source of information relative 
to time and location - that for sure is covered under our patent.

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

OK.

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

No folks... ABSOLUTELY NO... From an "evidentiary perspecitve" the interior 
content (i.e. the Crypto-payload) cannot be resigned except in the form of 
newly included encapsulation or it will break every digital evidence 
standard on this planet. Simply put the resigning of the content unless it 
is a layered encapsulation will IMHO destroy the provable Chain of Custody 
such that the content's anti-spoliation controls would be meaningless before 
a Court with any attorney's that get it.

If however you had a "Ceremony in Software" that would allow that data to 
be 'de-signed' and reduced to its original state there might be a process 
for this but that is included in my new amendment to the existing patent so 
it also is protected.


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

that's actually supposed to be a MUST not a 'must'.


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

Which again destroys the integrity of the CHAIN OF CUSTODY making the 
evidence produced hear-say at best.

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

Depending on what the DATE control is used for there are a number other 
issues including of all things McNeil's and my patent.

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

This is an issue - there is an ASSUMPTION here which should not be. NOTHING 
about EVIDENCE and its protection can be assumed. Proof for each assertion 
MUST be part of the control process.

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

Uh - expired time-stamps and ALG Identifiers are ONLY persuant to how an 
individual record was 'stored' - the expiry of this is worthless unless 
something actually happens. So what is it that this expiry is setup for?

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


--------------------------------------------------------------------------------



No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.175 / Virus Database: 270.8.4/1754 - Release Date: 10/29/2008 
7:45 AM