Viktor, thanks for the detailed feedback and questions. Comments inline below.
On Mon, Sep 14, 2015 at 2:56 PM Viktor Dukhovni <[email protected]> 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 >
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
