On 15 February 2017 at 14:50, Richard Barnes <[email protected]> wrote: > 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
Neither option specifies what the client does when it finds some data suspicious or how it shared said data with an auditor. I'm not sure you can leave this unspecified while trying to decide the rest of things. For example, in Option G do you report SCTs you can't resolve inclusion proofs for after N tries? In Option M what do you do about STHs you don't have in your verified cache? I'm also unclear if the log proxy is also an auditor (it seems like it implies it is, but that doesn't seem right.) That Option M problem is an additional con I think: [CON] Client must cache or otherwise handle the situation when the inclusion proof is to a STH is doesn't know about. This could be either an attack or just a newly issued certificate. This devolves to the case of off-line verification in G. -tom _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
