On Tue, May 23, 2017 at 8:42 AM, Eran Messeri <[email protected]> wrote:
> Below is a write up of the “Strict CT” variant, based on Mozilla’s
> suggestion.
> The goal of this write-up is to serve as a foundation for a document that
> will describe the deployment of CT needed to operate with stronger
> guarantees for TLS clients, as well as the protocol extensions necessary to
> deploy it.
>
> *Goal*: Provide TLS clients with proof of inclusion to a tree state they
> already know (save clients the need to audit logs themselves).
>
> *Overview*:
>
> - UA vendor ("auditor") periodically collects an STH (denoted
> "official" STH [1]) from each log, distributes it to its UAs ("clients").
> Clients are expected to cache all STHs.
> - CA/Site Owner ("submitter") submits (pre)certificate to the log,
> gets SCT [2].
> - Submitter waits until the next official STH that includes the
> certificate, gets an inclusion proof to be served alongside the certificate
> + SCT.
> - In the TLS handshake, clients get certificate + SCT + inclusion
> proof to an official STH they know about [5].
>
>
> The purpose of the UA vendor sending down the official STH is to provide
> third-party verification of the consensus.
> The purpose of the submitter bundling the STH + inclusion proof is to
> avoid the client having to retrieve it via some other protocol
>
>
> Options for dealing with the delayed usability of certificates:
>
> - Submitter waits until an inclusion proof to an “official” STH
> becomes available, only starts serving that certificate then (could take up
> to 2 x MMD - two days, typically).
> - The CA could wait until the proof becomes available and only
> issue the final certificate then - delay issuance by up to MMD.
> - The requester could get the certificate immediately but only
> start using it once it’s able to obtain an inclusion proof to an
> official
> STH [3].
> - Certificate is used immediately, only with SCT: Clients accept
> certificates only with SCTs for a limited duration; after that an inclusion
> proof must be accompanied [4].
> - Opt-in: servers requires presence of proofs via header / X.509
> extension [6].
> - Certificate is used after the client can fetch an inclusion proof
> and an STH the log has produced; if it’s an unknown STH the client sends it
> to the auditor for reconciliation.
>
>
> Footnotes:
>
> [1] The "official" STH does not have to be explicitly marked: Assuming
> daily STH push cycle, a log could mint one marked STH every day, to be
> distributed to clients. Alternatively, if STH issuance frequency (which
> 6962-bis requires specifying) is not too high (e.g. hourly) then the
> "official" STH could be the first one issued after midnight UTC
> (synchronizing on the clock).
>
Note: A 'daily' cycle is a generous assumption. While this captures
publication, it does not measure client update. For example, it presumes
the UA is awake and listening and able to receive such an update, but in
situations of mobile devices, weekend home devices, etc, this doesn't hold.
> [2] An intermediate improvement is to return, rather than just SCT, the
> SCT + STH issued immediately afterwards (~seconds) + inclusion proof to
> that STH. Effectively, this would rid of SCTs - the STHs issued that way
> will have the same privacy properties of SCTs, but it will simplify the
> system by removing the requirement to deal with inclusion proofs, only
> consistency proofs (clients would still have to know how to check an
> inclusion proof to those intermediate STHs, but not have to fetch them).
> If this variant can be successfully deployed using 6962-bis, in
> 6962-bis-bis we could get rid of SCTs completely.
>
> [3] The web server only has to do this once for each new certificate since
> clients are expected to cache all STHs indefinitely.
>
Was this part of Mozilla's proposal? I probably misunderstood, but this
would seem to be an effective non-starter. Indefinite, unbounded caching,
on billions of clients of a variety of form factors, doesn't really seem
like a solution at all :)
> [4] That requires auditing logs asynchronously, since an attacker with
> persistent access could keep getting new SCTs issued, or some clients may
> not have fresh STHs because they missed some updates.
>
> [5] There will be a time period where a submitter serves an official STH
> that the client doesn’t yet know about because it wasn’t distributed, or
> received, yet. Clients could send these for reconciliation, or the
> submitter required to not serve it yet until it was distributed to clients.
>
> [6] In theory, a new certificate, with the inclusion proof embedded, could
> be issued - but it may run afoul of the restriction on issuing different
> certificates with the same serial number.
>
Isn't that the whole reason 6962-bis moved to the (terrible) CMS structure?
:) That CAs were concerned that precerts & certs constituted two logically
distinct X.509 certificates? If that was to be introduced, it would make
sense to simply return to the critical extension, since we'd have lost the
main argument for using CMS :)
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
