Hey all, I wanted to follow up on my earlier comments and a bunch of side conversations I've had with people since then with a revised change proposal that I think can get -rfc6962-bis to a point we can live with.
tl;dr: 1. We/Mozilla can live with the Merkle tree for now, though we/community might ultimately want something different later 2. At a systemic level, we need to move toward servers providing inclusion proofs, but -rfc6962-bis provides sufficient tools for this 3. We need to better document "STH discipline", and define a "canonical STH" for each element in the log 4. We need to update the security considerations to describe more clearly the implications of various levels of auditing I'm willing to write up a PR for (2); EKR has volunteered for (3). # Auditing Models There are basically two approaches to auditing available to clients: 1. Prospective: Browser does auditing checks at TLS connection time 2. Retrospective: Browser does auditing checks after TLS connection time Prospective checking provides better assurance than retrospective, since it prevents any harm that would come from a mis-issued, improperly-attested certificate. The cost is that the server has to send enough information the cert and the browser has to cache enough information about the log that the two can be married up without further requests. In practice, however, it looks like some degree of retrospective checking will be necessary even in browsers that support the cache enough information for prospective checking. On the one hand, if an inclusion proof can't be embedded in a cert, then we can't count on all server operators providing it (via OCSP / TLS). On the other hand, including proofs in certs imposes issuance delays that will not be acceptable in many circumstances, even if it is O(minutes). And given Eran's SSL proxy proposal, with the amendments I suggested, I'm now pretty well convinced that the fetches you need for retrospective validation can be done privately with something short of Tor (just). The scalability problems are bad, but probably ultimately workable. It should be clear that either of these models work much better if the server provides inclusion proofs. Together with the STH discipline notions below, this would enable prospective auditing for all but very new certificates if a browser is willing to cache STHs. Even in cases where CT information must be fetched, having the server send an inclusion proof would mean that the only fetch would be for consistency, which is a less privacy-sensitive, more cacheable query. # STH Discipline Either style of auditing also works better if logs have a notion of "STH discipline", in the following sense: 1. The official state of the log comprises a sequence of STHs issued at specified intervals. 2. For each certificate in the log, there is a single "canonical STH" to which the log will produce an inclusion proof. Proofs to other STHs are done by adding a consistency proof to the inclusion proof. This property makes things work more smoothly in both auditing models: - If the browser is willing to cache STHs, this tells the browser exactly which STHs it needs to cache in order to validate all inclusion proofs. - Everything is more cacheable, since there's only one inclusion proof per certificate, and a limited set of heads among which consistency needs to be calculated. - Cacheability means that the fetches of inclusion proofs get greater privacy benefit from caching, since they depend only on the certificate, not the STH that the client is using. Likewise for consistency proofs, because of the reduced variety. >From a protocol point of view, I haven't done a thorough evaluation of the document, but there are at least a few things you would want to make this model work: - Prose that articulates the above bounds on logs / inclusion proofs / STHs. Probably a notion of "STH issuance frequency" parallel to MMD. - A field in an SCT that indicates the canonical STH for the certificate in question. Possibly a serial number in STH that SCTs could refer to. - An API endpoint for fetching STHs in the official sequence (in addition to the current one, which is the only option right now). If this line of thinking sounds generally sane to people, I'll take a pass through the document and make some concrete proposals. Thanks, --Richard
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
