Chrome's next stage of SCT auditing

[Joe DeBlasio]

Hi ct-policy@,

Since Chrome 90, users enrolled in Enhanced Safe Browsing have shared a sample of SCTs encountered with Google. We are now looking to expand to all users who have not opted-out of all Safe Browsing protections via a more (but not perfectly) privacy-preserving reporting mechanism.

An initial design of this feature is now complete, and we welcome your thoughts and feedback.

[Tom Ritter]

"If the client receives a response with a non-OK response_status, or a
log_status that does not contain the SCT's log, or a hash_suffix field
containing the SCT, the client should not report the SCT."

If it's a non-OK status, why not retry the request later? (The other
two scenarios make sense.) But an error condition could indicate an
attacker attempting to temporarily DOS Google go submissions from the
target fails, no?

"In consultation with cryptographers far smarter than this author, we
have determined that we only need a total hash length of 12 bytes to
ensure that the risk of hash collisions is below 2^32."

This works in a random world, but we aren't in a random world, I don't
think. The goal of this is to detect a SCT (via the hash of the SCT)
that the attacker does not want us to detect. The SCT contains a
signature by an ECDSA key; which is computed using an unknown k. An
attacker can therefore generate SCTs until they get an SCT whose hash
collides with another SCT. The collision rate should make that
generation process sufficiently hard, not guard against the chances of
a random collision.

-tom

> --
> 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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CAFZs0S69sjKgfsgHED9o908e2xgcJb7NH-GchvpNo49n%3DVmuLw%40mail.gmail.com.

[Andrew Ayer]

On Wed, 9 Jun 2021 10:33:03 -0700
Joe DeBlasio <jdeb...@chromium.org> wrote:

> An initial design
> <https://docs.google.com/document/d/16G-Q7iN3kB46GSW5b-sfH5MO3nKSYyEb77YsM7TMZGE/edit>

> of this feature is now complete, and we welcome your thoughts and
> feedback.

Hi Joe,

It's great to see work being done to expand SCT auditing to more users!

The doc says:

"In this protocol, the hash used is the SHA256 hash of 0x00 || x, where
x is the LogEntry corresponding to the SCT. This exactly matches the
leaf hash definition in rfc6962."

I assume x is really the MerkleTreeLeaf, rather than the LogEntry?
Also, "leaf hash definition" links to an RFC6962-bis draft, not RFC6962.

Earlier in the doc it says clients query "a hash of the SCT." Perhaps
it should say "a hash of the SCT's corresponding MerkleTreeLeaf"?

Regards,
Andrew

[Joe DeBlasio]

Thanks Andrew -- you're right on all counts, and the doc has been updated accordingly.

[Joe DeBlasio]

On Wed, Jun 9, 2021 at 1:22 PM Tom Ritter <t...@ritter.vg> wrote:

"If the client receives a response with a non-OK response_status, or a
log_status that does not contain the SCT's log, or a hash_suffix field
containing the SCT, the client should not report the SCT."

If it's a non-OK status, why not retry the request later?  (The other
two scenarios make sense.)  But an error condition could indicate an
attacker attempting to temporarily DOS Google go submissions from the
target fails, no?

Good question. Our expectation is that we will use response_status in only exceptional circumstances as a means of telling the browser that SCT auditing is turned off.

DoS mitigations will occur via a non-HTTP 200 response. I'll clarify the expectations around client retry behavior for these cases in a future update.

 

"In consultation with cryptographers far smarter than this author, we
have determined that we only need a total hash length of 12 bytes to
ensure that the risk of hash collisions is below 2^32."

This works in a random world, but we aren't in a random world, I don't
think. The goal of this is to detect a SCT (via the hash of the SCT)
that the attacker does not want us to detect. The SCT contains a
signature by an ECDSA key; which is computed using an unknown k. An
attacker can therefore generate SCTs until they get an SCT whose hash
collides with another SCT. The collision rate should make that
generation process sufficiently hard, not guard against the chances of
a random collision.

The precise number of bits to be included is still an active conversation on our end, and I suspect you're right that we'll end up higher than where we are now. I'll follow up once that's settled a bit.

-Joe