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). _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
