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

[thayes@xxxxxxxxxxxx (Terry Hayes)]

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

"Linn, John" wrote:

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