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

[Ryan Sleevi <[e-mail]>]

On Wed, Jun 7, 2017 at 8:51 AM, Magnus Ahltorp <[e-mail]> wrote:

> Well, that depends on the assurance level, doesn't it? For
> domain-validated certificates, sure, but those are next to worthless
> anyway. It would be hard to hold a CA responsible for issuing them, so the
> need for logging them is really small.
>

Let's not introduce CAs' marketing distinction into the technical
discussion.

Domain validated certificates - the basis for the Web PKI - are the only
security level that matter. The holder of such a certificate can
impersonate any site named in the certificate - whether from example.com to
google.com.

The other forms of certificates, "Organizationally Validated" or "Extended
Validation", or, in the EU, Qualified Website Authentication Certificates,
while nominally trying to provide higher assurance, do not meaningfully do
so in the security model of the Web (which is the Origin).

To that end, the past decade of CA misissuance responses have come down, in
part, to the misissuance of certificates that attest to a websites
identity, and CAs have been held responsible.

I can totally appreciate a perspective that believes that CAs' human
processes are far more secure than their automated processes, even if that
perspective is not supported by the data. However, if we accept that - from
a pragmatic and practical security perspective - that identifying a website
grants the capability of TLS termination (namely, lacking an EKU or having
an id-kp-serverAuth EKU, and naming one or more dNSName or iPAddress
identities in a SAN) - then these certificates are very much in scope of
the Web PKI, and thus need to be logged, as they present risk to the Web
PKI consumers.


>
> > > 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].
> > > [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.
> >
> > This seems potentially promising but I think it has some flaws. Would
> this auditing be done by the logs themselves, or by monitors? IIUC, logs
> are allowed to produce infinite SCTs for the same cert once they've logged
> it, and they don't have to produce the list of SCTs they've signed. So the
> only party that could meaningfully audit for excessive SCT generation would
> be the log itself, which is the party we're trying to defend against.
>
> If we are talking about "limited duration" of SCTs, we are talking about
> the age of the timestamp in the SCT. Each timestamp that is used to
> generate an SCT is required to be logged in the log. That is what the log
> is logging, cert+timestamp.
>

I think this may have resulted from a misunderstanding. I'll try to explain
one such scenario.

Consider at T=0, Certificate X is logged, and an SCT(X, 0) is issued. The
proof that such SCT has been incorporated into the STH will not be required
until T=24, so such a certificate can be used (without proof of inclusion)
from T=0 to T=24.

Now, if I am a malicious CA, a T=23, I approach the log again, and request
SCT(X, 23). The log, colluding with the CA, issues SCT(X, 23) - rather than
the expect SCT(X, 0). Further, the log does not incorporate the SCT(X, 0)
into STH(24) - it silently discards it.

Clients will not expect to see a proof of this inclusion until STH(47) -
that is, SCT(X, 23) + 24.

On T=46, I repeat this process, obtaining SCT(X, 46), and clients not
expecting this until STH(70).

By the CA and Log colluding, I can continue to extend the period upon which
I, the Evil Log, do not log this certificate.

This situation arises because the SCTs can be delivered through multiple
means, so it does not necessarily need to be fixed in the certificate. Yet
even if it was fixed in the certificate, so long as I, the Evil Server,
stop serving the cert prior to T=24, clients won't check the inclusion
proof. This is why it was remarked that some form of auditing - of the SCTs
produced by the log - would need to be asynchronously done, to ensure that
SCT(X, 0) wasn't 'extended' beyond that.