Discussion of Issue 72: Timestamp Trace

["Hal Lockhart" <hlockhar@bea.com>]

In general, it is axiomatic that security mechanisms should be as simple as
they can be and still meet definite requirements. Every extra feature makes
analysis more difficult and creates a potential opportunity for an attack.

We do not understand the intended Security use of TimeStampTrace. We do not
understand how to process it as a receipient and we do not understand the
advice given about signing it.

In the context of security, the only possible use we can see for this
feature is to estimate clock skew between systems with unsynchronized
clocks. If the feature is being used in an environment where clocks are not
synchronized, we do not see how to disambiguate clock skews from processing
delays.

Further, lines 1300-1301 of core 13 say: "It is also strongly RECOMMENDED
that each SOAP role sign its elements by referencing their ID, NOT by
signing the TimestampTrace header as the header is mutable."  We do not see
how this will prevent an attacker from modifying the values in order to
frustrate our efforts to estimate skew.

If it is being used in environment where clocks are synchronized, its
purpose would seem to be gathering information for performance analysis. It
would therefore seem to belong in a specification addressing instrumentation
of Web Services and provide the means to record other important performance
related data.

Based on these considerations, we propose removing this feature and perhaps
forwarding it to some group whose scope includes performance
instrumentation, such as the Web Services Distributed Management TC.

Hal