On Mon, 15 May 2017 17:18:22 +0100 Eran Messeri <[email protected]> wrote:
> As it has been pointed out to me, the STH history API, even with the > proposed changes of adding a sequence number to issued STHs, or > requiring an STH refers to a previous STH, would not prevent > backdating of STHs in a meaningful way - see explanation below. This is not the only reason for a get-sths API. The other reason is that it facilitates the prospective auditing model favored by Mozilla, which is why Richard Barnes has asked for it[1]. There seems to be a general agreement that in the long term, TLS servers should send inclusion proofs due to the difficulty of auditing SCTs robustly and privately. 6962-bis already provides a way to embed inclusion proofs in the certificate, OCSP response, or TLS handshake. However, this is just shifting the problem to auditing STHs. Unfortunately, gossiping STHs or requesting consistency proofs has similar privacy problems[2]. An alternative to auditing STHs on-the-fly is for clients to download and cache batches of every STH the log has produced. An inclusion proof would be considered valid as long as it is based on one of the cached STHs. Currently, there are two obstacles to doing this: 1. Getting the STHs. Calling get-sth repeatedly isn't robust, because an STH might be missed. A get-sths endpoint allows all STHs to be obtained so they can be cached. 2. Auditing the STHs. Obtaining consistency proofs for every STH would require a lot of bandwidth. For this reason, Richard Barnes called for the use of a Haber-Stornetta hash chain[3], which would be a rather drastic change to the protocol. I have a simpler proposal: have each STH contain the hash of the previous STH. This provides the same properties as a Haber-Stornetta hash chain while making only a modest, backwards-compatible change to the protocol. Clients need only gossip the latest STH to be confident that everyone has the same view of the log, including its entire STH history. Therefore, there is no need for clients to audit the consistency of each STH, as this job can be left to auditors who are guaranteed to have the same view of the log's STH history. A get-sths endpoint, plus embedding the hash of the previous STH in each STH, plus the existing ability to embed inclusion proofs, will permit RFC6962-bis to be used with a robust, privacy-preserving, and prospective auditing model, while remaining conceptually backwards compatible with the auditing model of RFC6962. This seems like a win-win to me. Regards, Andrew [1] https://mailarchive.ietf.org/arch/msg/trans/Zm4NqyRc7LDsOtV56EchBIT9r4c [2] Although an STH doesn't uniquely identify a certificate like an SCT does, in practice a client auditing or gossiping a particular STH may be a very strong indicator that it just saw a particular certificate. For example, if 10 certificates embed an inclusion proof to STH X, but 9 of those certificates are expired or aren't used on the public Internet, then a client auditing STH X probably just connected to the server identified by the 10th certificate. [3] https://mailarchive.ietf.org/arch/msg/trans/gO_DFW3v9FmBCOek_hifZ6KL368 _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
