[openssl-dev] [openssl.org #4041] [PATCH] Add Certificate Transparency Support

[Adam Eijdenberg]

Viktor, thanks for the detailed feedback and questions.  Comments inline
below.

On Mon, Sep 14, 2015 at 2:56 PM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Mon, Sep 14, 2015 at 09:19:32PM +0000, Adam Eijdenberg wrote:
>
> > > What is then the purpose of the new "-serverinfo" option of s_server?
> > > If CT works without it, why add it?
> >
> > There are 3 ways by which a server can deliver Signed Certificate
> > Timestamps (SCTs) to clients:
> >
> > 1. SCTs embedded in the certificate itself.
>
> Some certificates will have these, and some won't.  The client-side
> API has clients setting CT policy prior to the start of the handshake,
> before the client knows the issuer of the server certificate, or
> whether the server's certificate is EV or not.
>
> Is that the right design?  Or does it make more sense for the client
> to require (or not require) CT dynamically, based on certificate
> features, (and likely on whether it is doing tranditional WebPKI
> or DANE).
>

The idea of CT is to make mis-issuance easily detectable by requiring all
certs to be logged in order to be considered valid (and thus deter
mis-issuance).   It would not be good if one could deliberately mis-issue a
cert that would make clients think they need didn't need CT, so in the
fullness of time (when is CT widely adopted, required by browsers) I would
expect most clients would just turn this on in the same manner they would
turn on verifying a cert chains to a trusted root.

That said, I agree the higher level API proposed in the later patch isn't
flexible enough, for example, one couldn't implement the current Chrome EV
policy with it, and likely should be replaced with a callback similar to
how verify is currently done.

I figured that it's still worth starting on the more basic patches first as
I expect it'll take a while to get all the pieces through the pipeline, and
I think will leave us open to try a variety of approaches there later.


> > 2. SCTs embedded in an OCSP-stapled response.
>
> Some servers don't support OCSP stapling, will the introduction of
> CT "require" them to start doing that?
>

No.  A server can choose either of the option options (1) or (3) instead to
support CT.


> > 3. SCTs sent in a TLS extension.
>
> Under what conditions should a server be configured to do that?
>

Any time a server wishes to serve SCTs.  I'll list some reasons in the
similar question below as to why this is desirable.  Note that these
methods are additive, not mutually exclusive.  SCTs may be provided by any
combination of these 3 mechanisms.


> > (1) requires work only by the CA issuing the cert.
>
> So entirely transparent to the server...  Do we really need any of
> the other models?  Why?
>

Under both (2) and (3) (but not (1)) the set of SCTs returned for a
certificate can vary over time.  So, for example, if a CT log ceased to be
trusted for any reason, servers that send SCTs via methods (2) or (3) can
log the certificate to new logs and return SCTs from those.  Servers
configured with (1) alone will need to get and install a new certificate
from their CA.  This is reflected in Chrome's current EV policy, which
guards against this by requiring more SCTs be present depending on
certificate validity length when they are delivered by being embedded in
the certificate.

(3) has another desirable property in that no participation is required by
the CA who issued the certificate.  A server operator can log their own
certificate, grab the latest version of Apache, nginx or haproxy and
support CT.  For examples of this see:
http://www.certificate-transparency.org/resources-for-site-owners


> > (2) requires work by the CA in their OCSP responder, and work by the site
> > operator to enable OCSP stapling in their server.
>
> What's the advantage of SCT via OCSP rather than in the certificate?
>

The set of SCTs returned can be varied over time by the OCSP operator as
logs come and go - and less SCTs (= less bandwidth) are required for
longer-lived certificates (under Chrome's current EV policy).


> > (3) requires work by the site operator only to configure their server to
> > send SCTs.
>
> When is this the right model?
>

If your CA doesn't currently offer an option to issue a certificate with
embedded SCTs, or an OCSP responder with embedded SCTs, then this is a
great option.  If those other options are available to you, you might still
choose to serve via the TLS Extension if fidelity around which SCTs from
which logs are returned is important to you.

(As a data point, Google properties have recently started serving SCTs via
this mechanism.)


> > The "-serverinfo" option to s_server is one way to achieve (3), and in
> fact
> > the tests (in a later commit) for s_client use this flag to verify
> > behavior.  I believe "-serverinfo" is purposely generic so it can also be
> > used for adding other TLS extension data that does not require dynamic
> > processing.
>
> So it is required for (3) only?
>

Correct.


> > Rich is correct that a server does not need to do anything, that is,
> until
> > clients begin to require CT support (as we expect them to do over time as
> > CT proves its value).
>
> The API at the moment seems to support "requiring" CT before any
> communication with the server.  That seems to be a flag-day transtion.
> Should the policy not be based on particular issuing CAs (that
> commit to log everything they issue)?  That would make for a more
> incremental transition.
>

I think that when you want to require CT or not depends also on the context
in which openssl is being used.  For example if it's being used as part of
a browser, there'll be one set of considerations (e.g. an incremental
rollout like Chrome's current policy or perhaps one as you've described).
However if you were using openssl in an application to make custom API over
HTTPS calls back to a server that you control, you might want to require CT
for all calls, as you know that your server supports it.

I'm not a fan of enabling per CA as it means you can avoid detection of a
mis-issued certificate by targeting a CA that doesn't indicate it supports
CT yet.

Again, CT is about providing assurance for site-owners that they can detect
mis-issuance of certificates, so one other option that we're considering
(in the context of Chrome) is a mechanism by which a site-owner can opt-in
to requiring CT ahead of any scheduled requirement (inspired by what Tom
Ritter proposes in:
https://ritter.vg/blog-require_certificate_transparency.html)

> Chrome, for example, already actually requires SCTs be supplied during
> > the handshake for EV certificates that have been issued after January 1
> > this year
> >
> https://www.chromium.org/Home/chromium-security/root-ca-policy#TOC-Extended-Validation-Certificates
>
> Which one does not know until the ServerCertificateMessage is
> received.  In that light, do CT policy settings made indepent of
> any input from the server make sense?
>

I think it does under some scenarios (e.g. own app talking to own server)
but I agree it isn't flexible enough for others (such as anyone trying to
duplicate the current Chrome EV policy).  Perhaps a callback similar to how
verify works would be a helpful replacement for that part of the API?


> Perhaps the right place for CT policy (which logs to use, whether
> CT is required, ...) is in auxiliary data stored with "TRUSTED
> CERTIFICATE" objects for root CAs?
>

Trusted log metadata will need to be stored somewhere.  For the reasons
above, I don't think it makes sense in general to key this on a root CA
though.  One thing to consider though is whether the trusted certificate
objects have any notion of whether they are real root CAs, or certs
installed by local admins on machines (e.g. by an enterprise that wishes to
MITM all outbound connections).  For that case ("local" roots) it doesn't
make a lot of sense to require CT.


> --
>         Viktor.
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150914/70cfcd6c/attachment.html>