On Wed, Feb 15, 2017 at 2:35 PM, Tom Ritter <[email protected]> wrote: > 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.) >
I agree that this is important, but I don't really see a connection to log structure. In either case, at this stage, the client has in hand the data it needs to claim a violation; the only question is how it get reported. > 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. > It's true that if you get a proof to an STH you don't have, then you have to cache it and see if you get one in a reasonable amount of time. I didn't count this as a CON for M because it's the same as G -- the point of the PRO there was that M can do immediate validation in many cases, but G never can. --Richard > -tom >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
