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? 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. 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. 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. 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. 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
