Dear TRANS, We had a call between a group of us last week that was helpful in clarifying my thinking here. I wanted to follow up to the list with some more detailed thoughts.
At base, in order to meet this group’s charter deliverables, what we want to be assured of is that the mechanisms in 6962-bis that are intended to enable public verifiability can actually do so in practice. That is, we need to establish that there is at least one plausible story for how some substantial fraction of the statements logs provide to clients end up getting audited. Part of the issue here is that we don’t have a full story anywhere in the documents for how auditing works at scale, and there are a couple of incomplete models floating around that lead to different design requirements for the public verifiability parts of CT, i.e., the part that is now the Merkle tree. So let’s consider two straw-man models and look at the differences they lead to. Call them “Option G” and “Option M” :) In the below, we assume: - "STH" is a general term for an object that: 1. represents the state of a log at a given time 2. is signed by the log 3. can be verified to fit into a linear sequence with other STHs - Server cannot be relied upon to take action, so any CT information needs to come to the client from the CA Option G: Cache one STH / dynamic inclusion proofs 1. Auditor pulls STHs from logs at some frequency, validates consistency 2. Periodically, the client obtains from the auditor: a. The latest validated STH b. A proof of consistency from the last STH the client received 3. Client is configured to talk to a log proxy over DNS (for privacy) 4. Client gets SCT from server 5. Client audits by fetching inclusion proof to current STH from log proxy over DNS - [PRO] CA can issue immediately due to use of SCTs - [PRO] Client only has to keep latest SCT - [PRO] Compatible with existing CA practices w.r.t. SCTs - [CON] Client has to reveal browsing history to log proxy in queries - [CON] Audit failure from DNS failure indistinguishable from log malfeasance - [CON] Someone needs to operate a log proxy - [CON] Requirement for audit-time fetches effectively forces audits to be off-line w.r.t. certificate verification / TLS connection time Option M: Cache many STHs / static inclusion proofs 1. Auditor pulls STHs from logs at some frequency, validates consistency 2. Periodically, the client obtains from the auditor: a. A list of all STHs since the last one the client received b. Proofs of consistency along this chain 3. Client caches entire history of STHs that it has received (really just needs to store tree heads) 4. Client gets inclusion proof to an STH from server (either in the certificate or in a stapled OCSP response), verifies it 5. Client audits by verifying that the STH provided by the server is in the validated cache - [PRO] Client never makes queries that are dependent on browsing history - [PRO] Auditing can only fail if client state is stale (no live queries) - [PRO] No need for a log proxy - [PRO] If inclusion proof is provided at connection / validation time, then auditing can be done immediately for certificates that are old enough for their STHs to have propagated - [CON] CA needs to wait for inclusion proof if inclusion proof is included in cert - [CON] Client needs to store entire history of STHs - [CON] Requires CAs to upgrade to fetch inclusion proofs instead of / in addition to SCTs # Requirements for STHs / log structure Option G requires: - STHs can be issued relatively infrequently (say daily) - Inclusion proofs need to be log depth to any STH Option M requires: - STHs need to be issued relatively frequently (say ~5-10min) - Inclusion proofs need to be log depth only to the proximal STH Option G leads naturally to the current design, with a global Merkle tree. Option M leads to something like a Haber-Stornetta hash chain of batch Merkle trees. And conversely, each of these log structures is unfriendly to the other operational model. In general, whatever structure is assigned to the log in 6962-bis will encode assumptions about the operation of the overall system. So we need to discuss the overall system before we decide on the log structure. # What this means for 6962bis Whatever we specify in 6962bis will enable some models for auditing and make other models infeasible. It’s important that whichever models 6962bis enables not have other features that make them infeasible to deploy. It seems to me that the two models above stake out roughly the two ends of the design space. I believe Option G is pretty much what Google is planning to deploy right now, though of course I might be mistaken about that. Personally, between the two, I find Option M much more appealing, largely because the failings of Option G seem much more intractable. Log proxies seem like a significant addition to the required infrastructure here, and the analysis required to separate mundane failures in queries to the log proxy from attacks on auditing seems likely to go awry. And I have a lot of difficulty imagining any mechanism for client queries that I would be comfortable with from a privacy point of view. Option M is not without problems. We’ll need to find some way to address the issuance delay problem, whether that entails some OCSP magic to bridge the gap or just getting the merge delays down to where the delay is acceptable to CAs. We’ll need to work out some migration question about how But in any case, we need to get more alignment among the stakeholders here on what models for auditing are acceptable before we finalize the public verification mechanisms in 6962bis. Obviously, the countersignature-related parts of the document are not tied up in this discussion at all, so if someone wants to pull those out into a separate document, I would have no problem advancing that to PS straight away. —Richard
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
