On 7 November 2016 at 11:25, Ryan Sleevi <r...@sleevi.com> wrote: > On Monday, November 7, 2016 at 9:02:37 AM UTC-8, Gervase Markham wrote: >> As in, their dishonesty would be carefully targetted and so not exposed >> by this sort of coarse checking? > > (Continuing with Google/Chrome hat on, since I didn't make the previous reply > explicit) > > Yes. An 'evil log' can provide a divided split-view, targeting only an > affected number of users. Unless that SCT was observed, and reported (via > Gossip or some other means of exfiltration), that split view would not be > detected. > > Recall: In order to ensure a log is honest, you need to ensure it's providing > consistent views of the STH *and* that SCTs are being checked. In the absence > of the latter, you don't need to do the former - and that's infrastructure > for monitoring primarily focuses on the STH consistency, with the > assumption/expectation that clients are doing the SCT inclusion proof > fetching. > > So if I were wanting to run an evil log, which could hide misissued > certificates, I could sufficiently compel or coerce a quorum of acceptable > logs to 'misissue' an SCT for which they never incorporated into their STH. > So long as clients don't ask for an inclusion proof of this SCT, there's no > need for a split log - and no ability for infrastructure to detect. You could > use such a certificate in targeted, user-specific attacks. > > This is why it's vitally important that clients fetch inclusion proofs in > some manner (either through gossip or through 'privacy' intermediaries, which > is effectively what the Google DNS proposal is - using your ISP's DNS > hierarchy as the privacy preserving aspect), and then check that the STH is > consistent (which, in the case of Chrome, Chrome clients checking Google's > DNS servers is effectively an STH consistency proof with what Google sees). > > In the absence of this implementation, checking the SCT provides limited > guarantee that a certificate has actually been logged - in effect, you're > making a full statement that you trust the log to be honest. Google's goal > for Certificate Transparency has been to not trust logs to be honest, but to > verify - but as Chrome builds out it's implementation, it has to 'trust > someone' - and given our broader analysis of the threat model and scenario, > the decision to "trust Google" (by requiring at least one SCT from a > Google-operated log) is seen as no worse than existing "trust Google" > requests existing Chrome users are asked of (for example, trusting Chrome's > autoupdate will not be compromised, trusting Google not to deliver targeted > malicious code). [1] > > Thus, in the absence of SCT inclusion proof checking (whether temporarily, as > implementations blossom, or permanently, if you feel there can be no suitable > privacy-preserving solution), you're trusting the logs not to misbehave, much > like you trust CAs not to misbehave. You can explore technical solutions - > such as inclusion proof checking - or you can explore policy solutions - such > as requiring a Mozilla log, or requiring logs have some criteria to abide by > ala WebTrust for CAs, or who knows what - but it's at least useful to > understand the context for why that decision exists, and what the trust > tradeoffs are with such a decision.
++ I feel compelled to note that we have an IETF draft on Gossip to address this need: https://datatracker.ietf.org/doc/draft-ietf-trans-gossip/ so if people are unaware of it, please read it and give us feedback on the IETF [trans] list. The document needs review, but we think we're done it excepting community review. On the point of SCT Inclusion Proofs, we propose three options: - Client fetches the Inclusion proof via DNS[0] and pollinates the resulting STH which should be privacy preserving - Client does _not_ fetch an inclusion proof, but provides historical SCTs to the website of origin[1] for auditors to collect - The client ships its browsing history to some third party wholesale. We're not too keen on the last one ;) But please, read the doc and give us feedback on [trans] - I don't want to divert this thread =) -tom [0] Or any other privacy preserving mechanism, such as Tor, but realistically DNS is going to be the main option for now. [1] We assume an attacker cannot MITM a website permanently, and the algorithm is designed such that in 'most cases' the evidence of an attack is preserved by the client for submission after the MITM ends. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
