Subject: RE: LAST CALL:draft-ietf-pkix-time-stamp-05.txt

From: "Linn, John" <[email-masked]>
Date: Fri, 4 Feb 2000 09:20:27 -0500

Denis wrote, excerpting:

> Let us address the three technical points raised by John first:
> 
> JL1: "If different entities obtain timestamps on the same data
> object using the same hash algorithm, or a single entity obtains
> multiple timestamps on the same object, the generated timestamp
> tokens will include identical message imprints; as a result, an
> observer could determine that the timestamps refer to the same
> underlying data.  It might be worth a note in Security
> Considerations stating that, in contexts where this potential
> exposure is a concern, some unique value could be generated by the
> requester and combined with a data object before hashing the
> combination in order to produce MessageImprint's hashedMessage."
> 
> An observer could indeed determine that the timestamps refer to the
> same underlying data. However, this is not a big concern since the
> observer will neither know the actual content nor the intended
> usage. The way that is proposed to address this issue might lead to
> the definition of another standardized binding technique so that the
> receiver of the TSP can know how to verify the linkage. I am not in
> favor of defining such a new linkage structure under the reason that
> I do not find the problem sufficiently important to be corrected. I
> would rather prefer to address the concern in a different way: if
> the requester really cares about this problem, he should rather use
> a protected channel with data confidentiality to access the TSA. If
> you wish to provide some text along these lines, I would be willing
> to consider it for inclusion in the security consideration section.
> 

I don't think that a confidentiality-protected channel to the TSA solves the
issue I was envisioning.  I expect that some uses of timestamps will require
that their recipients present or post them (selectively or generally) for
examination after they're obtained, and that such timestamps could
potentially be correlated by third parties.  I might be interested, e.g., to
observe a timestamp obtained by someone else with a hash which matches that
of a confidential document of mine. I'm not committed to proposing a
particular mechanism; I suggest, however, slightly adapting text above into
an advisory note for Security Considerations: "If different entities obtain
timestamps on the same data object using the same hash algorithm, or a
single entity obtains multiple timestamps on the same object, the generated
timestamp tokens will include identical message imprints; as a result, an
observer with access to those timestamp tokens could infer that the
timestamps may refer to the same underlying data."

--jl

---

From: Joerg Seidel <[email-masked]>
Date: Fri, 04 Feb 2000 15:53:08 +0100

"Linn, John" schrieb:
> of a confidential document of mine.
I don't think that this really matters in pratical life, since a timestamp
without the corresponding document wouldn't proof anything. I can not imagine
an application which makes it necessary to send a timestamp without the
document. But if you are transmitting/publishing the document together with
the timestamp, the third party would be looking for the document not the hash
since it can even recognize it when small changes were made.

> I'm not committed to proposing a
As stated above I do not believe this to be necessary, but I don't have an
objection either.

Jörg Seidel

-- 
timeproof                               phone  +49-40-76629-1911
Development                             fax    +49-40-76629-551
Harburger Schloßstraße 6-12             mailto:[email-masked]
D-21079 Hamburg                         http://www.timeproof.de

     + + + timeproof CeBIT 2000 Hall 23 Stand A22/14 + + +

---

From: Paul Koning <[email-masked]>
Date: Fri, 4 Feb 2000 10:42:14 -0500

>>>>> "Linn," == Linn, John <[email-masked]> writes:

 Linn,> I don't think that a confidentiality-protected channel to the
 Linn,> TSA solves the issue I was envisioning.  I expect that some
 Linn,> uses of timestamps will require that their recipients present
 Linn,> or post them (selectively or generally) for examination after
 Linn,> they're obtained, and that such timestamps could potentially
 Linn,> be correlated by third parties.  I might be interested, e.g.,
 Linn,> to observe a timestamp obtained by someone else with a hash
 Linn,> which matches that of a confidential document of mine. I'm not
 Linn,> committed to proposing a particular mechanism; I suggest,
 Linn,> however, slightly adapting text above into an advisory note
 Linn,> for Security Considerations: "If different entities obtain
 Linn,> timestamps on the same data object using the same hash
 Linn,> algorithm, or a single entity obtains multiple timestamps on
 Linn,> the same object, the generated timestamp tokens will include
 Linn,> identical message imprints; as a result, an observer with
 Linn,> access to those timestamp tokens could infer that the
 Linn,> timestamps may refer to the same underlying data."

I support John's reasoning.  The proposed note sounds good.  (I'd
suggest dropping "may" from the last line, since the hash is supposed
to have low probability of collisions.)

	paul

---

From: Paul Koning <[email-masked]>
Date: Fri, 4 Feb 2000 10:48:21 -0500

>>>>> "Joerg" == Joerg Seidel <[email-masked]> writes:

 Joerg> "Linn, John" schrieb:
 >> I don't think that a confidentiality-protected channel to the TSA
 >> solves the issue I was envisioning.  I expect that some uses of
 >> timestamps will require that their recipients present or post them
 >> (selectively or generally) for examination after they're obtained,
 >> and that such timestamps could potentially be correlated by third
 >> parties.  I might be interested, e.g., to observe a timestamp
 >> obtained by someone else with a hash which matches that of a
 >> confidential document of mine.
 Joerg> I don't think that this really matters in pratical life, since
 Joerg> a timestamp without the corresponding document wouldn't proof
 Joerg> anything. I can not imagine an application which makes it
 Joerg> necessary to send a timestamp without the document.

I suppose it isn't entirely obvious what sort of hazards are created
by the scenarion John mentioned.  On the other hand, it is clear that
what John described is accurate: if you have two timestamps with the
same imprint, the conclusion that they are for the same document
follows automatically.

Consider the analogy of ECB encryption -- this is considered unwise
because of the property that the occurrence of the same cipher block
means the same plaintext was encrypted.  Does that matter?  Often, it
doesn't.  Sometimes it might.  Since it's trivially avoided (by using
any other mode), ECB is considered a thing to avoid.

While one might argue about the importance of adding the note John
asked for, is there harm in adding it?  Does it mislead?  I don't see
that it does.  It provides information that may only matter to a very
few, but since it does, let's add it.

	paul

---

From: [email-masked] (Terry Hayes)
Date: Fri, 04 Feb 2000 09:17:57 -0800

Reguarding the security concerns around identical MessageImprint values:

I agree that text describing this issue would be useful.  While the problem will
not be a concern for many who use this protocol, describing the it in the
Security Considerations section will keep at least one implementor from creating
an application that does not provide the desired security.

You might also consider suggesting a way to address the problem in particular
applications.  Creating the MessageImprint from data that contains a salt value,
and the original document nicely avoids this problem.  This type of solution can
be implemented by applications that require it.  There is no need to add it to
the timestamping protocol.

Terry

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 07 Feb 2000 09:06:06 +0100

John, 

Your text addition is fine and I have no problem to add it to the
Security considerations section.

"If different entities obtain timestamps on the same data object
using the same hash algorithm, or a single entity obtains multiple
timestamps on the same object, the generated timestamp tokens will
include identical message imprints; as a result, an observer with
access to those timestamp tokens could infer that the timestamps may
refer to the same underlying data."

Denis