Re: [Trans] Write-up of the "Strict CT" variant

[Filippo Valsorda <[e-mail]>]

A couple observations on what we can and can't achieve with strict CT.

First, I think that for a scheme to be deployable it has to enable and
not rollback the HTTPS automation trend. We can't tell Caddy (which
recently affirmed that it rather not start than start with an expired
certificate) to just wait a MMD or two at startup. We can't afford 24h
delays in signups at Cloudflare.

So any scheme that requires linking to out-of-band distributed blessed
STHs needs an asynchronous verification fallback, at least for young
certificates.

I heard suggestions that the requirement might be enforced per-CA. I
think that would cause pretty twisted incentives, and eventually die
the way of HPKP:

* A CA opting into "Strict CT"---which should be incentivized as more
secure/privacy-preserving---would be exposing its customers to the 24h
delays, a strong dis-incentive. LE would never opt-in, Cloudflare
couldn't use such a CA.
* For it to be effective against attackers that compromise a
non-strict CA, the site would have to pin to the strict CA(s). But
then losing the certificate private key means a MMD of downtime, which
is effectively the same operational risk of leaf-pinning HPKP.

Moreover, as Ryan pointed out, clients can be out of sync for
significant periods, for causes indistinguishable from maliciousness,
so there's no "safe amount of time" a website can wait, while a UA
can't stop working after 24h failing to phone home.

A zero-MMD log that immediately produces a STH doesn't help, because
you face the exact same problems proving that the STH is not forked.

It's hard-fail/soft-fail all over again, except we can meaningfully
verify asynchronously---there's a CT log to hold accountable.

Once you accept the need for an asynchronous verification method it
becomes clear that we can't improve upon it in terms of:

* complexity, since we still need to implement an asynchronous
verification method
* security against a colluding CA-log-MitM, since the attacker will
keep generating young certificates
* privacy against a malicious log, for the same reason

All we can do is limit how often the asynchronous verification method
is invoked in normal operation.

I think the best possible outcome would be:

* codify at which period STHs are issued, so each SCT has a known next
STH (-bis basically requires a log to have a full and minimal history
of STHs already, respectively because there are "existing and not"
STHs, and for privacy; let's go the whole way and expose and codify
it)
* distribute off-band the whole history of STHs (~150 bytes * 2 STH
per day * 365 days * 2 years window * 12 logs = 2.6MB)
* optionally staple inclusion proofs to SCTs, which are now unique
since they only need to link to the next canonical STH
* offer an asynchronous method to fetch inclusion proofs for a SCT,
which are now easy to cache in DNS because unique
* if the UA does not yet have the STH for the SCT, it will defer
verification; if it doesn't have the inclusion proof, it will fetch
it; but in most cases it will have the STH and will use the stapled
inclusion proof to verify the SCT

It's compatible with all three distribution methods, still benefits
from mandatory SCT (and if possible inclusion proof) in OCSP, and a CA
and website willing to wait can also include the inclusion proof
directly in the certificate.

It would also have the excellent side-effect of making logs endpoints
cacheable, as the number of artifacts would now be O(number of
certificates).