Subject: [Gen-art] Gen-ART review of draft-ietf-ltans-ers-13.txt

From: Brian E Carpenter <[email-masked]>
Date: Mon, 21 May 2007 11:46:11 +0200

NEW: Preferred email for non-IBM matters: [email-masked]

Sorry, forgot to copy Tim the first time...

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-ltans-ers-13.txt
Reviewer: Brian Carpenter
Review Date:  21 May 2007
IESG Telechat date: 24 May 2007

Summary: This draft is basically ready for publication, but the reviewer has three questions.

Comments:

Substantive:
------------

The General AD is certainly more qualified than this reviewer for
this topic, and I have not verified the ASN.1. The document is clear
and seems ready except for three points:

At the end of section 4.2:

   The data (e.g. certificates, CRLs or OCSP-Responses) needed to verify
   the timestamp SHOULD be stored in the timestamp itself or MUST be
   preserved otherwise.

I find this insufficiently clear. When would it be acceptable not to
store these data in the timestamp, and if not done so, how would the
retriever know where to look?

Just before section 5.1:

   After the renewal, always only the last, i.e. most recent
   ArchiveTimeStamp and the algorithms and timestamps used by it must be
   watched regarding expiration and loss of security.

This raises a general question - maybe this is well understood in LTANS,
but RFC 4810 didn't clarify it for me. When a hash or crypto algorithm
becomes "insecure" is not a well-defined moment. What is the triggering
event for a Time Stamping Authority to decide to switch to a new algorithm,
for example? What is the significance of the rather under-defined data
stored in cryptoInfos (section 3.1)? If it says "SHA1 valid until 2010"
does that means it is or isn't OK to use SHA1 to generate timestamps
in December 2009? Maybe all this is documented elswehere?

Finally, I'm surprised that the redundancy mentioned in the Security 
Considerations is only a recommendation. To my taste, it would
be a MUST, since we are discussing the *really* long term here.
 
Editorial:
----------

  == Unused Reference: 'I-D.ietf-ltans-ltap' is defined on line 1117, but no
     explicit reference was found in the text

  == Unused Reference: 'RFC3029' is defined on line 1144, but no explicit
     reference was found in the text

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Tobias Gondrom" <[email-masked]>
Date: Mon, 21 May 2007 20:01:36 +0200

Hello Brian, 

thank you very much for your review. 
Answering to your questions: 

> 1. At the end of section 4.2:
> 

[tg]: There are three main reasons why we did intentionally write this
up in this level of detail: 
At first, most of the verification of a RFC3161-timestamp has been
documented very well in the timestamp and CMS specifications. Second,
ERS is open for other timestamps as well (e.g. ISO-18014-x) and they may
(and do) require other verification data than RFC3161, plus these other
formats may not be able to store all the necessary information for
verification inside their data structures. 
And third, as some of the verification data may be dependent on the use
case and country where it is verified, the WG works on the I-D
http://www.ietf.org/internet-drafts/draft-ietf-ltans-validate-01.txt to
describe the verification and the required data in more detail. 

> 2. Just before section 5.1:
> 
> event for a Time Stamping Authority to decide to switch to a new 
> algorithm, for example? What is the significance of the rather under-
> defined data stored in cryptoInfos (section 3.1)? If it says "SHA1
valid 
> until 2010" does that means it is or isn't OK to use SHA1 to generate 
> timestamps in December 2009? Maybe all this is documented elswehere?

[tg]: In general the cryptographer community has defined criteria when
an algorithm is "insecure". (E.g. one would be "when it no longer
fulfils its defined protection profile".) 
The exact time (day, hour and second) when an algorithm becomes insecure
may not be 100% defined. E.g. the time span when algorithms are
officially accepted as secure may differ by country. E.g. some countries
may name a specific official end-date (e.g. 31.12.2008) after which the
algorithm is no longer accepted as secure although it has not been
broken by then. These dates may deviate from country to country.
These local differences can not be resolved by the standard. 
The ID draft-ietf-ltans-validate-01.txt shall also provide guidance on
this. 

As further explanation: Generally there are two ways to look at this:
a) Retrospectively from the point of view of the verification party in
the future: At a future point in time a verification party will verify
the Evidence Record and in the process will compare the time until when
the algorithms and certificates have been used with the times they where
considered secure by them, by their government or policies of other
regulating bodies accepted by the verification entity. 
The mentioned instance of the cryptoInfos (i.e. the "SHA1 valid until
2010") can be a helpful hint, allowing a more efficient run of the
verification routine. 
b) Thinking forward from the point of view of the Long-term archive
service protecting its data:
The service must continually monitor the cryptographic developments
around the algorithms used by its hashtree and timestamps. This can also
be achieved by watching government bodies like NIST or e.g. the German
"Bundesnetzagentur" and others who publish information on the security
of algorithms. If these bodies indicate that some of the algorithms will
be broken soon, the LTA service must apply the according
timestamp-renewal or hashtree-renewal with new stronger algorithms. 

> 3. Finally, I'm surprised that the redundancy mentioned in the
Security 
> be a MUST, since we are discussing the *really* long term here.

[tg]: "MUST" is not appropriate here:
The unbroken chain of one Evidence Record clearly proofs the integrity
of the data. Of course as we wrote in the Security Considerations it's
recommended to keep a redundant ER to counter the risk of retrospective
loss of security of some of the used algorithms. And you might even
consider triple redundancy where possible. 
But, some systems may not be able to offer this redundancy, e.g. if they
do not implement additional redundant algorithms or even if there is
only one secure algorithm available to them (note: e.g. many timestamp
servers tend to use the same one algorithm and many systems e.g. only
implemented SHA-1). 
And if the used algorithms in the non-redundant systems are not broken
before they will have been renewed, their Evidence Records are
absolutely trustworthy and MUST be verified with "ok", although they did
not run with redundant other algorithms. 
So, basically, the level of redundancy is a quality of the Long-term
archive service. 
(And last but not least: ERS is defining a syntax/data structure, not
the system.) 
To summarize: It would not be fair to exclude smaller providers/services
by raising this bar to "MUST", plus it MUST NOT be necessary to verify
that a second redundant Evidence Record exists just to verify the first
one, and there may even be situations where only one secure algorithm is
available. 

> Editorial:

[tg]: We thought we should leave them in as Informational references as
they provide information about the context of the draft. 

Best wishes, 

Tobias

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Monday, May 21, 2007 11:46 AM
> To: General Area Review Team
> Cc: [email-masked]; [email-masked];
> [email-masked];
[email-masked];
> Tim Polk
> Subject: Gen-ART review of draft-ietf-ltans-ers-13.txt
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 21 May 2007 14:38:04 -0400

The RFC editor does not allow documents to be listed as references 
that are not referred to in the text.

Russ