[cabfpub] Upcoming changes to Google Chrome's certificate handling

[Ben Laurie]

On 7 November 2013 19:44, Jeremy Rowley <jeremy.rowley at digicert.com> wrote:
> 2)      Time Frames.  Maximum Merge Delay is not a long period of time.
> Considering that sites can currently go weeks without detecting a mis-issued
> certificate, even a CT of 24 hours (which is ridiculous, it’s more like
> minutes) provides a substantial benefit over the existing landscape.

Note that the MMD is a _maximum_ that the log must commit to. It has
to allow for things like machine deaths, s/w faults, fires in DCs and
inter-DC links getting dug up. As such, it needs to be long enough
that the log really can realistically take action within the MMD. So,
whilst I agree that minutes are often feasible, it would be unwise to
commit to minutes.

I'd also note that the more available a log is, the longer the typical
merge delay is likely to be (since available == distributed and
distributed == longer time to consensus).

>  A DoS
> attack against the log server is detectable, and a log server that fails to
> report for an extended period of time becomes untrusted, minimizing the
> possibility of an attack. Plus any attacker would need to attack every log
> that issued an SCT proof.

I think that would depend on the motives of an attacker.

Another point, though, is that anyone can mirror a log. I'd suggest
that log mirroring is a good idea, and makes DoS much harder to
achieve.

> 3)      Preventative v. Remediation. Although we also favor preventative
> solution, we do not believe any currently proposed preventative solution
> alone is sufficient.  CT helps fill the gaps where preventative solutions
> fail. Deploying CT does not eliminate prevent CAs from deploying other
> preventative solutions.

CT offers a spectrum of solutions, ranging from "detect misissuance
some time after the fact" to "prevent use of misissued certificates
altogether". It is possible to re-tune CT to make an entirely
preventative system.

This would involve, at least, giving monitors time to view and dispute
logged certificates, before a newly logged certificate would be
accepted by browsers.

Right now, in order to minimise the impact on CA operations, we are
tuned as far to the performance end of the spectrum as we can be,
whilst maintaining an acceptable level of security. However, we agree
that preventative solutions are better and we would be very happy to
modify CT towards the preventative end of the spectrum if the industry
would prefer.


> 5)      Size. We do not support Google’s recommendation for three separate
> time stamps.  Two is sufficient to provide protection.  In fact, I’d prefer
> to include only a single proof in each certificate.  If you log a cert to
> multiple servers, you can include a new proof later on during re-issue,
> which minimizes concerns about log compromise.  Regardless, I do not think
> Google should dictate the number of logs.  Instead, each CA should
> individually evaluate the risks of a log compromise or unavailability and
> decide the number of proofs required.

I have some sympathy with this argument, but the concern is that if a
large CA decides that a single log is sufficient, and that log is
compromised, then we would be faced with the choice of allowing
compromised certs in the wild or breaking a significant fraction of
HTTPS sites. This weakens the whole system, we think unacceptably.

Since browsers are ultimately the ones that must take action when
compromises occur, I do not agree that it is not their decision to
make.

> 10)   Mandate.   We believe Google should require CT for all certs, not just
> EV.  To date, EV certificates have been free from missuance.  Changing
> processes and creating logs for just EV requires a lot of work for little
> benefit.  In fact, we are concerned that requiring logs for only EV
> certificates may have a negative impact on EV adoption and implementation.
> Implementing  CT for DV certificates is of greater importance and will yield
> a more significant improvement in overall Internet security. We would really
> like to see a CT requirement date for DV and OV certificates, even if Google
> is unable to require full compliance by CAs for several years. EV are a
> higher caliber of certificate, and we’d like to see more done to encourage
> their use.  As such, we highly recommend that Google establish a CT date for
> all certificates instead of just EV certificates. If Google insists on only
> requiring CT for EV, then the date for full CA compliance, and a loss of EV
> indicators, should be March 2016, two years from when CAs must include
> proofs in the certificates.  EV certificates are only valid for two years,
> meaning this date will minimize the impact on issued certificates and keep
> the white list relatively small.

We agree that all certs should require CT and are happy to start
setting deadlines if there's support from CAs. Our default plan was to
get some experience with EV + CT before setting deadlines, though.

> 12)   Implementation Date. We suggest that March 2014 be the date when all
> certs are required to hit a log server.  This will give CAs time to adapt,
> implement CT, and notify customers of the change. We suggest the same date
> be used for all certificate types.  We do not thing CAs should be required
> to include the proof in the certificate at that time.  Instead, that date
> should be later to ensure a smooth transition of certificates and encourage
> the spread of operational log servers.  Because of the development time
> involved and encourage proofs through OCSP stapling, we propose March 2016
> as the date when CT become mandatory for every certificate.  OCSP stapled
> proofs are more elegant than embedding the proof, but we need time to
> promote OCSP stapling and encourage adoption.

It seems to me that "all certs are required to hit a log server" is
difficult to enforce technically (and the whole idea is to remove
trust, so non-technical enforcement is not really in the right
spirit), however, I guess a CA that made no effort would be pretty
visible. What should the consequence of non-compliance be, in your
view?

March 2016 for mandatory CT seems perhaps too far in the future, but I
can certainly support it as the very latest date we should consider.

> 13)   Other Technology.  We agree with Rick that CAA (if implemented
> correctly) is a good bootstrap.  However, CT and CAA are not mutually
> exclusive. CAA adds security the same way requiring OV certificates adds
> security.  CAA records add an additional step that ensure the CA know the
> certificate is authorized, which is already part of the OV process.
> Although neither remediate certificate issuance in the event of a compromise
> both OV and CAA are great preventative measures.  Therefore, we agree that
> the CAB Forum should continue discussing preventative technologies and
> improvements.

CAA is even less preventative than CT with its current settings is. I
do not understand why you describe it as preventative?