On Wed, Jan 18, 2017 at 8:29 AM, Eran Messeri <[email protected]> wrote:
> I find this analysis very useful, though some of it seems to be based on > different security model than the one we currently use for CT (and as Paul > pointed out, 6962 and 6962-bis are about “exposing rogue parties”). > Let me again bust this myth that 6962 / 6962-bis do anything to expose rogue logs. Without some sort of consistency checking mechanism, logs can lie without any risk of discovery. That is true of CT as deployed today. There is no way to detect a rogue log. And a consistency checking mechanism only creates risk to rogue logs to the degree that it is deployed and used. If only 5% of SCTs ever get checked for consistency, then a rogue log has a 95% chance of getting away with any particular lie. So we really need consistency checking at scale. > The analysis is correct on the difficulty of public verifiability when > only SCTs are used, which we’re addressing by implementing the DNS-based > protocol <https://bugs.chromium.org/p/chromium/issues/detail?id=506227> > (in part to get data about its reliability). There’s academic work underway > to get inclusion proofs, and report log misbehaviour, in a > privacy-preserving manner (I hope to be able to share a paper soon). > > Ultimately I agree with Richard’s analysis and Andrew Ayer’s comment > <https://www.ietf.org/mail-archive/web/trans/current/msg02630.html>, that > inclusion proofs (and the STHs they chain to) should be embedded in the > certificate, together with the SCT. > 6962-bis specifies the mechanism > <https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-24#section-4.4> > to do it and UAs can require it as a policy. > ... and I definitely agree that 6962-bis is an improvement over 6962 in this regard! > > The claim that “CT’s public verifiability mechanisms are too inefficient > to be deployed at scale” is based on the following operating assumptions > for CT (my understanding from an out-of-band chat with Richard): > - The goal is to not require auditing after the fact but have all auditing > information beforehand (stronger model). > - Logs issue STHs every 8 minutes. > - SCTs are augmented with inclusion proofs up to the STHs covering them. > - Clients download all STHs, check consistency and store them. > - When a certificate with SCT and inclusion proof is observed, it is > rejected if it’s not chaining up to one of the STHs in the client’s > storage. If it is, then the SCT’s signature and inclusion proof are checked. > > This variation of CT is supposed to provide security against log > misbehaviour but is still deemed too expensive to deploy at the cost of > 4MB/month of data for each client. However: > - This assumes CAs are happy to wait 8 minutes for certificate issuance > (issuance bandwidth is high, but that benefits only large-volume CAs). > - It effectively brings down the MMD to 8 minutes. > - What about clients that have been offline for a while and have yet to > catch up with recently-issued STHs? If SSL connections are blocked until a > client catches up, that’s equivalent to on-line certificate checks (OCSP). > - A clear-cached-load of Facebook clocks at 1.6MB, slashdot.org 3.2MB, > bbc.co.uk 875KB, which should give some context for the 4MB/month cost > (note not all clients have to participate; herd immunity means all clientns > benefit even if only some audit logs). > - Equivocation may not be possible, but the threat of logs presenting > split-views remains (even if all clients start with a “trusted” STH) - a > collaborative way to compare the view logs present is still necessary (our > auditing > implementation in Chrome <https://codereview.chromium.org/2017563002/> > does not require it as STHs are pushed daily to clients). > > Exploration of different schemes for CT with stronger guarantees should be > independent of 6962-bis. > The problem here is that the document is not clear about what guarantees it provides, and where it tries to explain clearly it assumes a mechanism for auditing SCTs exists. For example: """ If a server presents a valid signed timestamp for a certificate, then the client knows that a log has committed to publishing the certificate. From this, the client knows that monitors acting for the subject of the certificate have had some time to notice the misissue and take some action, such as asking a CA to revoke a misissued certificate, or that the log has misbehaved, which will be discovered when the SCT is audited. """ The problem here is that there is no effective mechanism for auditing SCTs right now. The DNS thing you mention might work, though it seems to me to have really poor scaling properties (and it is completely unimplementable in Firefox, for software reasons). Or the log refactoring I'm proposing might work. But we're clearly pretty far from consensus here. So either we need to block this document on the creation of some auditing mechanism that we all feel comfortable with, or we need to put some clear warning labels on this thing in terms of the guarantees it provides, and in particular, its vulnerability to rogue logs. > 6962-bis allows us to address some of the issues with 6962 (like enabling > embedding of inclusion proofs) and even trial variants (using the > extensions mechanisms). > > Hearing a major UA vendor state that CAs should tolerate some latency > during certificate issuance for the benefit of the ecosystem is exciting > news. We can do it with 6962-bis > Indeed, it sounds like we've got some consensus here at least on the browser side of things that CAs and servers should be moving from SCTs towards inclusion proofs. I think there are a couple of straightforward things we could add to the document to facilitate that transition: * Adding an explicit lifetime to SCTs and a recommendation that RPs impose a maximum lifetime on SCTs on the order of the STH issuance frequency of the log * Adding a recommendation that RPs require signatures from multiple logs Those changes would bound the risk from SCTs in the short run, and give us a tool to phase out SCTs in the long run (in favor of inclusion proofs). > : newer CT log implementations and the upcoming Trillian based > implementation are capable of integrating added chains into the tree within > O(tens of seconds to minutes). > I would be interested to know what about the operation of adding to the tree causes this degree of latency. To be honest, it seems pretty extreme, given the rates at which CAs are capable of operating these days. In particular, I wonder if this is another example of the pain we have pain we have undertaken by having a single global Merkle tree instead of some more flexible structure. --Richard > Different, potentially simpler, systems can be built under that assumption > (and I’ll let proper cryptographers suggest them :)). > > Eran > > On Tue, Jan 17, 2017 at 3:49 PM, Richard Barnes <[email protected]> wrote: > >> >> >> On Tue, Jan 17, 2017 at 10:34 AM, Paul Wouters <[email protected]> wrote: >> >>> On Mon, 16 Jan 2017, Richard Barnes wrote: >>> >>> Speaking as individual only... >>> >>> - It is not practical to build a publicly verifiable log system that >>>> incorporates SCTs >>>> - The existing tools for public verifiability need to be made more >>>> efficient in order to work on the scale >>>> envisioned >>>> >>> >>> So I think there might be a different perception here of the goal of >>> CT. I think you are looking at a 100% catch-before-it-happens >>> scenario. While the document is only about "exposing rogue parties". >>> >> >> Those two goals are not as different as you might think. Either way, you >> need for the client to detect equivocation. You need the same data; it's >> just a question of when. >> >> >> >>> Fundamentally, CT is a public ledger system: every certificate is >>>> supposed to be entered into a log and RPs >>>> only accept certificates which are logged. In order for this to work >>>> properly, RPs need to be able to verify >>>> that there is public consensus about the state of the log. Otherwise, >>>> logs can “equivocate”: represent to the >>>> RP that a given certificate was published when it in fact was not. >>>> Unfortunately, in practice RPs are not >>>> doing this verification (for reasons discussed below), and so CT >>>> reduces to a countersignature scheme in which >>>> the RP trusts the log not to equivocate. There are two primary >>>> challenges here, as detailed below. >>>> >>> >>> The monitors are supposed to use multiple logs, presumably not all of >>> which are colluding. So a rogue log would be found out and lose its >>> trust? Maybe not in time for this one client visiting this one website, >>> but that was never the expected goal of CT. >>> >> >> I think you mean "RPs" where you say "monitors", right? >> >> Even in this scenario, in order for the rogue log to be found out, you >> still need a system for detecting equivocation, which we don't have now. >> >> >> >>> It has been known for quite some time that the public verifiability >>>> piece of CT introduces latency in >>>> certificate issuance. In order to allow for immediate certificate >>>> issuance, logs instead issue SCTs, which are >>>> just promises to incorporate the certificate into the log; effectively >>>> the SCT is a countersignature on the >>>> certificate. However, if an RP accepts a certificate + SCT, then it is >>>> vulnerable to collusion between a CA >>>> which issues a bogus cert and a log which issues a bogus SCT but never >>>> incorporates the cert into the log. >>>> >>> >>> So that is someting monitors should look at. >>> >>> We are unaware of any way to efficiently address this issue without >>>> introducing either privacy problems or >>>> latency. In order to validate inclusion in the log, the RP needs to >>>> validate that other entities (e.g., the >>>> software manufacturer) have the same view of the log. Either the RP >>>> downloads the whole log (which is >>>> inefficient), queries for the specific certificate in question (which >>>> has privacy problems) or retrieves a >>>> checkpoint which vouches for some batch of certificates (which >>>> introduces batch latency). >>>> >>> >>> So personally, I would like to know that ACME-style issued certificates >>> would start being accepted within a few minutes. At least for those >>> sites that did not have a certificate before. If we are talking about >>> renewing, then it should be able to properly submit new entries to log >>> before actually activating the new certs, so some latency wouldn't >>> matter. >>> >> >> As I noted in my little quantitative analysis, you can get the data >> structures down to a reasonable size with a ~8min issuance delay if you're >> willing to refactor the log structure. >> >> --Richard >> >> >> >>> >>> Am I missing something? >>> >>> Paul >>> >> >> >> _______________________________________________ >> Trans mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/trans >> >> >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
