[secdir] Secdir telechat review of draft-ietf-cose-tsa-tst-header-parameter-05

[Stefan Santesson via Datatracker <[e-mail]>]

Reviewer: Stefan Santesson
Review result: Serious Issues

I honestly hate to give bad feedback, but as I'm assigned the SecDir reviewer
of this document. I do feel obligated to share my concerns which to the most
part repeat the concerns of my last review. My motivation for providing this
feedback is genuine concern that the current document may unintentionally lead
to vulnerable implementations.

Logic reversal causing confusion:
The proposed TTC (Timestamp Then COSE) option introduces reversed logic
compared to established cryptographic timestamping practices (RFC 3161
timestamps from a TSA), as seen in CMS, XML signatures, JOSE, and ETSI
standards (XAdES, CAdES, PAdES, JAdES). Traditionally, timestamps from a TSA
are applied over the signature data to clearly establish proof that the
signature existed at or before the stated time. In contrast, placing a
timestamp that only covers the payload and not any signature data is a clear
deviation from practice. The fact that this timestamp still appears in a
signature header, despite having nothing to do with the signature, may trigger
false assumptions that it is semantically bound to the signature itself.
Although the semantics are clearly stated, this deviation from traditional
timestamping practice may cause significant confusion and lead implementers to
make incorrect assumptions based on their prior experience with signature
timestamps.

Threat scenario:
This is the scenario that worries me:Consider the following scenario with two
different developers contributing to different parts of the validation logic:

Developer A parses and validates COSE signatures but intentionally does not
handle certificate path validation. This is a quite common approach as most
validation scenarios involves pre-trusted keys rather than certificate path
validation. This developer outputs parsed data objects, easy to be consumed by
a calling application layer that handles key or certificate validation. This
includes data about the different timestamps, correctly validated and tagged by
their header identifier.

Developer B, responsible for certificate validation based on RFC 5280 and RFC
3161 timestamps, consumes the correctly pared signature data provided by
Developer A. Developer B, unfamiliar with the novel TTC timestamp semantics,
erroneously assumes that the payload-only timestamp represents a signature
creation time. Consequently, Developer B incorrectly validates a signature
created after a signing key was compromised and its certificate revoked,
relying on a pre-compromise payload timestamp, leading to successful validation.

This vulnerability is serious but is of a kind that likely will not be caught
by unit tests or integration tests unless the tester is very creative. When
everyone does the right thing, everything works.

I do have to say that I can see reasonable benefits with TTC. But I would
personally like to prioritize security over the benefits in this case. My
primary recommendation would be to align with other signature standards and not
include TTC at all and pursue other alternatives for this need (such as
solutions inside the payload). But as I fear that this will not be the selected
path. I would then at least give the TTC header a name that clearly makes an
implementer think twice. Such as "non-signature-timestamp" or
"payload-only-timestamp" or similar. "3161-ttc" is not informative enough and
the second developer may not react appropriately to the important semantical
difference from "3161-ctt" as this developer is not a COSE expert and therefore
commonly only reads the details of this RFC if he has to.

Security Considerations update proposal:

The Security Considerations section has been improved, but I think the current
text is inadequate. If the TTC functionality remains in the specification, the
Security Considerations section should explicitly highlight this risk. I
propose adding something like:

"Implementers MUST clearly differentiate between RFC 3161 TSA timestamps
proving the existence of payload data at an earlier point in time and
timestamps explicitly providing evidence of the existence of the cryptographic
signature. Failure to clearly distinguish between these timestamp semantics
could result in vulnerabilities, such as incorrectly accepting signatures
created after key revocation based on older payload-only timestamps. Validators
MUST NOT interpret protected-header payload timestamps as proof of signature
creation time and SHOULD rely exclusively on RFC 3161 TSA timestamps explicitly
covering signature data for determining signature validity timing."

Thank you for considering this feedback aimed to enhance clarity and security.