Re: exposing certificate information (current + upcoming)

[Ryan Sleevi <[e-mail]>]

On Fri, May 10, 2019 at 6:50 AM Stefan Eissing <[e-mail]>
wrote:

> Christophe Brocas (@cbrocas), organizer of Pass-the-Salt security
> conference, tweeted
> about checking HTTP server certificates against CT logs to detect very
> early if someone
> successfully highjacked one of your domains.
>
> A renewed certificate is often not immediately used on a server but
> activated on the
> next restart which can be several hours away. To check if a certificate
> mentioned in a
> CT log, one would need to obtain information about upcoming certificates
> as well.
>

I'm not sure I understand the CT use case. Are you attempting to verify
that a certificate with embedded SCTs has been incorporated within a logs
MMD? The discussion of detecting very early if someone hijacked one of your
domains seems largely orthogonal to providing information about your
present certificate, since the attacker/adversary would simply not provide
this information. In CT, this is fine, because the reliance is upon the
SCTs (whether from TLS, embedded, or OCSP) being proof of inclusion within
a log, and, as Ilari mentioned, client verification and/or gossip of those
SCTs (and related STHs) to ensure presence within a log.

While I don't think there's any harm in exposing information about upcoming
certificates, particularly if they've already been logged (by the server,
in the case of TLS, or by the CA, in the case of embedded SCTs or OCSP
responses), it doesn't seem to fit with a very clear threat model, and I
worry I'm missing something that's supposed to be obvious here.