On Wed, Feb 15, 2017 at 3:38 PM, Andrew Ayer <[email protected]> wrote:
> On Wed, 15 Feb 2017 12:50:12 -0800 > Richard Barnes <[email protected]> wrote: > > > > [...] > > > > Option M: Cache many STHs / static inclusion proofs > > > > [...] > > > > - [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 > > Since a client cannot distinguish between a rogue STH and a legitimate > STH that it doesn't know about yet, it has no choice but to accept the > connection if it doesn't know about an STH and audit it later. Therefore, > option M is no better than option G in this regard: both provide post-hoc > detection rather than prevention. You can't call this a "pro" for option > M while simultaneously calling it a "con" for Option G. > > > [...] > > > > Option M leads to something like a Haber-Stornetta hash chain > > of batch Merkle trees. > > Why? The only justification provided so far is that a client would > need to download 4MB of data a month, which is a "pretty big chunk of > data."[1] This is a rather extraordinary claim. Can you explain your > reasoning why 4MB a month is too much? > To be a bit glib -- the folks who manage syncing state out to Firefox balked when I mentioned it to them. Basically, that amount might not sound scary from the client side, but if you're thinking about syncing that data out to 100s of millions of clients, that's an extra few 100MBps of capacity you have to provision, and it's only kinda cacheable. > Even if 4MB/month is deemed excessive, there are other options which > avoid reliance on SCTs, but can be implemented on top of 6962bis' > current design without requiring clients to download 4MB a month. > Let's call them Options A1 and A2. > To be clear, I did not mean to imply that these were the only options. On the contrary, I would like to have some discussion about the options here so we can understand what requirements we should be holding 6962bis to. Can you explain why being implemented on top of the current system is a requirement? I can see why it's desireable, e.g., to avoid further delay. But in general, I would be inclined to change the spec to the web's needs rather than the other way around. > Option A1: Fetch consistency proofs on demand > > 1. Client gets an STH and an inclusion proof to the STH from server, > verifies the proof, and adds STH to a cache if not already present. > > 2. In the background, client audits unverified STHs in the cache > by requesting a consistency proof between the unverified STH and some > other verified STH. > > - [PRO] No need to audit SCTs. > - [PRO] Although client makes queries (consistency proofs) that are > triggered by > browsing, the queries do not reveal browsing history because many > certificates > use inclusion proofs to the same STH. > - [PRO] No need for a log proxy. > - [PRO] Client only needs to fetch consistency proofs for STHs it actually > sees. > - [PRO] Client only needs to store STHs it actually sees. > - [CON] CA needs to wait for inclusion proof if inclusion proof is > included in cert. > - [CON] Requires CA to upgrade to fetch inclusion proofs instead of / in > addition to SCTs. > > I asked you on-list two weeks ago why this wouldn't work[2], but you > have not replied. > Sorry, that's my fault. Trying to be more responsible on this thread :) I think this is better than option G, but there are still a couple of concerns. The one that's most critical to me is that you're relying on the structure of STHs for a privacy property -- if there are too few new certs under an STH, then your consistency query reveals your browsing history. That seems like a very fragile assumption to be making, especially given that we have no STH discipline / schedule in the current system. And making logs explicitly trusted for this privacy property seems counter to the idea that logs are not to be trusted. > > Option A2: Publicly-logged STH batches > > 1. Auditor pulls STHs from logs at some frequency, validates consistency. > > 2. Periodically, auditor logs batches of STHs to CT logs. > > 3. Periodically, the client obtains from the auditor: > a. Batches of STHs since the last one the client received > b. Inclusion proofs for each STH batch up to the log's latest STH > c. Consistency proof between the last STH received by the client and the > latest STH > > 4. The client verifies all proofs received from auditor, but assumes > that the STHs in the batches are legitimate. > > 5. Client caches entire history of STHs that it has received (really > just needs to store tree heads). > > 6. Client gets inclusion proof to an STH from server (either in the > certificate or in a stapled OCSP response), verifies it. > > 7. Client audits by verifying that the STH provided by the server is in > the cache. > > 8. An ecosystem of auditors monitors logs for STH batches and audits > all contained STHs by requesting consistency proofs. This saves the > client from having to verify every single STH itself. > > - [PRO] No need to audit SCTs. > - [PRO] Client never makes queries in response to browsing. > - [PRO] No need for a log proxy. > - [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 CA to upgrade to fetch inclusion proofs instead of / in > addition to SCTs. > > Option A2 is very similar to Option M, but avoids the need for clients > to do their own STH auditing (except for STHs related to the STH > batches). If you're happy with Option M you should be happy with Option > A2, even when implemented on top of the current Merkle Tree design. > What you lose in this design relative to both G and M is the clients direct assurance that the STHs it's relying on are a valid sequence, as opposed to something the auditor made up. That is, the assurance here is like if you took G or M and removed the part where the auditor sends down the consistency proofs. That's not the biggest tragedy in the world, but if that's the best we can do, we'll need to be clear about this constraint in the document ("Most clients will need to delegate consistency checking to an auditor, which means that they will be at risk of the auditor lying to them in the following ways..."). But given that there are options on the table that get us to a stranger guarantee at the cost of a spec change and some adaptation by the small number of logs that exist, I'm not sure why we should settle here. > I agree with many of your concerns about SCT auditing, but considering > that Options A1 and A2 can be implemented on top of 6962bis (plus Option > M if 4MB/month can be tolerated), I don't see why these concerns should > hold up publication. > As I've noted above, A1 and A2 aren't really meeting my requirements. (Maybe we should go through a requirements exercise here?) "It's in the document" is a reason to persist in standardizing a design, much less implementing it. If we want to keep the current design, let's get consensus that there's a plausible auditing story for it. Otherwise, let's pick another one. --Richard > > Regards, > Andrew > > [1] https://mailarchive.ietf.org/arch/msg/trans/gO_ > DFW3v9FmBCOek_hifZ6KL368 > > [2] https://mailarchive.ietf.org/arch/msg/trans/ > sA7ZrHIsuqWvIkF0B4I8dv8nKsY >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
