Subject: [Trans] Write-up of the "Strict CT" variant

From: Eran Messeri <[email-masked]>
Date: Tue, 23 May 2017 13:42:38 +0100

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).

[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.

[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.

Eran

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 23 May 2017 09:20:01 -0400

On Tue, May 23, 2017 at 8:42 AM, Eran Messeri <[email-masked]> wrote:

>    - 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].
>    - In the TLS handshake, clients get certificate + SCT + inclusion
>    proof to an official STH they know about [5].
>
>
> The purpose of the submitter bundling the STH + inclusion proof is to
> avoid the client having to retrieve it via some other protocol
>
>
>    - 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 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:
>

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).

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 :)

> 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 :)

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 23 May 2017 09:26:00 -0400

A variation of this to consider:

- CAs already MUST update their OCSP responses on a 3.5 day interval (by
virtue of Microsoft's program requirements), which I'm working on codifying
with the Baseline Requirements since they are, effectively, a baseline that
Microsoft has defined

A UA could define that:
- CAs MUST include the SCT and an inclusion proof from that SCT to one of
the 'blessed' STHs
- There is a rolling two week window of 'blessed' STHs (using whatever
selection scheme appropriate)

Whether this is the opt-in server basis or for all connections, this could
provide a privacy-preserving proof-of-inclusion with stronger guarantees.
This is built on existing 6962-bis primitives (AIUI), and simply an
exercise in UA policy. Further, this does not inhibit nor substantially
change the implementation story for other user agents - which could still
support other forms of SCT delivery (e.g. precerts, TLS) with asynchronous
inclusion proof checking.

---

From: Eran Messeri <[email-masked]>
Date: Tue, 23 May 2017 14:43:09 +0100

> situations of mobile devices, weekend home devices, etc, this doesn't hold.
I agree, this is a major concern and I haven't yet heard a proposal how to
address it.

>> [3] The web server only has to do this once for each new certificate
>> since clients are expected to cache all STHs indefinitely.
>>
>
As far as I understand, it was. Old STHs can be disposed of: if for
example, clients knew that the log that issued them only admits
certificates that are valid for at most a year, then STHs that are more
than a year older are not going to be received anymore.

>> [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 :)
>
Yes :( I mention that as an unlikely option.
I'd like to return to the critical extension too, the main concern brought
against it (AFAIK) is some TLS libraries that would accept precerts as
valid X.509 certificates.

>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>
>

---

From: Eran Messeri <[email-masked]>
Date: Tue, 23 May 2017 14:49:50 +0100

> - CAs MUST include the SCT and an inclusion proof from that SCT to one of
In the OCSP response, I assume?

> inclusion proof checking.
Seems to me like a simpler way to achieve the same requirements, and so
favourable. It does depend on clients fetching OCSP responses / OCSP
stapling by servers, correct?

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 23 May 2017 10:32:03 -0400

> In the OCSP response, I assume?

Yes, apologies :)

>> Whether this is the opt-in server basis or for all connections, this
>> could provide a privacy-preserving proof-of-inclusion with stronger
>> guarantees. This is built on existing 6962-bis primitives (AIUI), and
>> simply an exercise in UA policy. Further, this does not inhibit nor
>> substantially change the implementation story for other user agents - which
>> could still support other forms of SCT delivery (e.g. precerts, TLS) with
>> asynchronous inclusion proof checking.
>>

Right. It leverages the existing update infrastructure for OCSP responses
on stapling-supporting servers (or potentially in clients), and
externalizes the cost of tracking the 'blessed' STH onto the CA, rather
than to the millions of site operators. This keeps relative consistency
with the original design of CT, which was to find the points in the Web PKI
ecosystem most flexible to change (CAs) and deploying the robust fixes
there.

This certainly increases the friction to change - servers supporting robust
OCSP stapling becomes a potential necessity - but it allows UAs to make
those tradeoffs using the appropriate building blocks, based on their (or
the site's) risk profile. This makes it even more of a preventative
measure, at greater cost, but some UAs may feel that tradeoff is
appropriate.

---

From: Andrew Ayer <[email-masked]>
Date: Wed, 24 May 2017 12:34:35 -0700

On Tue, 23 May 2017 09:26:00 -0400

> inclusion proof checking.

I really like this idea.

Note that RFC6962-bis needs one additional primitive to make this work:
the get-sths endpoint.  Otherwise there is no robust way to gather the
blessed STHs for distribution to clients - one could always be missed
if you are relying on calling get-sth repeatedly.  This is why I think
the get-sths endpoint is important.

Regards,
Andrew

---

From: Andrew Ayer <[email-masked]>
Date: Wed, 24 May 2017 12:41:09 -0700

On Tue, 23 May 2017 14:43:09 +0100

> valid X.509 certificates.

Is that such a bad thing?  RFC6962 and RFC6962-bis are both quite clear
that a pre-certificate is a binding commitment by the CA to issue the
final certificate, and that misissuance of a pre-certificate is
equivalent to misissuance of the final certificate.  So what's the
difference between a client accepting a pre-certificate and a client
accepting the final certificate which the CA is bound to issue
anyways?  The only difference I see is that one has embedded CT
information and the other doesn't.  The pre-certificate is not
inherently untrustworthy.

CT would be simpler and more flexible if it didn't have
pre-certificates, and instead CAs were permitted to re-issue
certificates with duplicate serial numbers as long as the only change
was the addition/modification of the Transparency Information
extension.  I suggest keeping this in mind for RFC6962-bis-bis.

Regards,
Andrew

---

From: Magnus Ahltorp <[email-masked]>
Date: Thu, 25 May 2017 13:01:03 +0200

> 23 May 2017 14:42 Eran Messeri <[email-masked]> wrote:
> 
> *Overview*:
> 

I may have misunderstood something, but why would the STH not always be included with the inclusion proof? What is the reason for all this extra complexity (UA vendor distributing the STH, inclusion proof not self-contained)?

/Magnus

---

From: Tom Ritter <[email-masked]>
Date: Thu, 25 May 2017 09:45:51 -0500

> I may have misunderstood something, but why would the STH not always be included with the inclusion proof? What is the reason for all this extra complexity (UA vendor distributing the STH, inclusio…

The inclusion proof does contain the STH.  But we don't trust it. It
might represent a split view of the log.  There's no way to know
without comparing our view of the log with other people's.  By having
the UA vendor provide it's view of the log (or rather, a specific
subset of it in the form of specific STHs), we can confirm that this
STH we got is in the known set of STHs the UA vendor got. Our view is
the same as theirs. And since theirs is the same sent to every browser
client, we can be pretty sure that we and everyone - who uses this
browser at least - has the same view of the log and we are not being
presented a split view.

-tom