MMD Violations in Absence of SCT Signature

[Andrew Ayer]

I recently found entries in a pending log whose timestamps implied an MMD violation <https://issues.chromium.org/issues/41383535#comment89>. In the transparency-dev Slack <https://app.slack.com/client/T060L0SP1UY/C08RH556HRB>, the log operator claimed that no SCTs for these entries were returned to submitters. This raised the question if this was still an MMD violation.

Chrome's CT Log policy is pretty clear that SCTs have to be issued for it to be an MMD violation:

"Log operators must... Incorporate a certificate for which an SCT has been issued by the log within the MMD."

So the question is whether SCTs were issued or not. In CT, we don't trust the word of log operators; we trust cryptographic proof. It's true that I had not obtained any SCT signatures, but I had obtained an STH signature covering log entries implying an MMD violation.

So the real question is whether an SCT signature is required to prove an MMD violation or if an STH signature suffices.

I believe an STH signature does suffice, and must suffice.

First, RFC 6962 Section 3.4 is quite clear that timestamped entries correspond to SCTs (the phrase "corresponding [to an] SCT" is used four times). Therefore, when a log signs an STH incorporating a TimestampedEntry, it's asserting that a corresponding SCT also exists. It's just as good as an SCT signature for proving the existence of an SCT.

Second, requiring an SCT signature to prove MMD violations would make it very difficult to detect backdated SCT timestamps. This is important, because Chrome relies on the earliest SCT timestamp to enforce SCTNotAfter constraints on untrustworthy CAs. Right now, SCTs which are backdated by more than the MMD can be easily detected by examining log entries. (In fact, Chrome's introduction of SCTNotAfter is the reason I started auditing timestamps.) If we had to rely on SCT signatures instead, we'd probably never get the signatures necessary to prove that a log operator was colluding with a CA to circumvent SCTNotAfter - the log need not return the same SCT to normal submitters. (There may be other ways to detect backdating, like cross-referencing entries with other logs, but they're harder to implement, don't always work, and produce controvertible evidence.)

Not all MMD violations lead to log removal. In this case, the MMD violation was short and the log operator has already made changes to reduce the likelihood of a recurrence. Therefore, I do not believe it warrants a denial of the log's inclusion. However, I do not want to establish the precedent that log entry timestamps can't be used to incontrovertibly prove MMD violations.

Regards,
Andrew

[Philippe Boneff]

Hi Andrew,

Thanks for the writeup! I think you raised a very interesting point, and I'm happy this can be discussed openly.

I agree that examining the entry timestamps and indexes raises suspicions about whether an MMD violation occurred—well spotted. These logs do not issue SCTs without incorporating the corresponding certificates first. This means that whenever an SCT is observed, the corresponding entry is already available in the log, and a Merkle audit proof can be fetched (barring any other read availability issues with the log). I'm sure a lot of folks are aware that not all logs behave the same way: Trillian+CTFE-based logs didn't, nor do TesseraCT logs with the publication awaiter turned off.

With this in mind, I think that MMD means something different for these two types of logs. If an entry cannot be obtained after an SCT has been issued for it from a synchronous log, this is akin to a log read availability issue rather than an "MMD violation" in the RFC 6962 sense. Should policies reflect this difference? I'd be very careful about saying we can scrape MMD for synchronous logs because ensuring immediate availability globally is hard, but I'm sure this could be worded in a mindful way.

Therefore, when a log signs an STH incorporating a TimestampedEntry, it's asserting that a corresponding SCT also exists.  It's just as good as an SCT signature for proving the existence of an SCT.

I agree. An STH of size X asserts the log's ability to issue SCTs for all entries whose index is smaller than X. With my current understanding, the same reasoning does not apply to timestamps. In that instance, did you obtain an STH whose size was larger than the index of the problematic entry, and without that entry being available?

My understanding so far is that the following was observed:

• An STH covering entry 58472861 and entry 58472862.

• timestamp(entry_58472862) + MMD < timestamp(entry_58472861), thus suggesting that the add- request corresponding to entry 58472862 landed on the server more than MMD before the one corresponding to entry 58472861, yet entry 58472862 was sequenced after entry 58472861.

Did I miss something?

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/20260514114746.d92b6bf8f29046e2b0c2ff59%40andrewayer.name.