[cabfpub] Ballot 118 - SHA1 Sunset

[Ryan Sleevi]

On Oct 3, 2014 1:58 AM, "Gervase Markham" <gerv at mozilla.org> wrote:
>
> On 02/10/14 20:55, Ben Wilson wrote:
> > _Effective 1 January 2016, CAs MUST NOT issue any new Subscriber
> > certificates or Subordinate CA certificates using the SHA-1 hash
> > algorithm.
>
> It is worth noting the ramifications of this.
>
> If we assume that any site can present at most one certificate, and
> furthermore that every site needs to work in very modern browsers which
> are implementing SHA-1-deprecating UI such as recent Chrome or recent
> IE, then the CAB Forum making a requirement is basically the same thing
> as the browsers making a requirement.
>
> However, if someone were to add a feature to a webserver where it could
> send different certs to different clients based on SSL handshake
> fingerprinting, then (without a CAB Forum ballot) they could continue to
> use SHA-1 certs for older browsers and use SHA-256 for newer ones. But
> if we pass this ballot, we preclude that possibility.
>
> The situation which makes me think of this is as follows. Firefox has a
> download site, served over HTTPS. We have many people who want to
> download Firefox to get a supported and secure browser, who are on XP
> SP2 or below. If we switch the cert for that site completely to SHA-256,
> they are caught in a chicken and egg situation - they can't get a
> SHA-256-supporting browser until they get a SHA-256-supporting browser!
>
> The only other possibility is to make the initial load of the download
> page over HTTP, then redirect to two different sites based on a
> JavaScript test of the OS version. But clearly, we would much prefer
> end-to-end SSL for the entire experience. (Also, there are lots of
> direct-to-HTTPS download links out there already.)
>
> One way we could solve this problem by making our webservers do SSL
> handshake sniffing, and serve different certs to different clients. But
> if the CAB Forum passes this ballot, we would have trouble getting a
> SHA-1 cert to serve to the legacy clients.
>
> Gerv
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

Gerv,

Isn't this best dealt with like the discussion of short-lived certs? That
is, when there is a meaningful way to do such detection (and there is for
OpenSSL servers, its just not exposed in great configuration detail by
Apache or nginx), we can revisit a ballot for that, if necessary, based on
the technical details and goals of the implementation?

It is worth noting that, according to Microsoft's policies (which, I should
note, Chrome has also adopted), no SHA-1 certs can be issued by members of
the root programs. Tom was also quite clear on this during the most recent
F2F, in reiterating that policy, and we agree. A SHA-1 cert issued after
2016 is unacceptable.

So, ballot aside, its a defacto requirement. The ballot just memorializes
this and adds a helpful auditing function to it.

However, I think you perhaps have too rosy a view about how such an
exemption would play out in practice. If browsers adopt negative UI (as
Chrome does, and as have both you and other Mozilla developers suggested
Firefox will/should) for such post-2016 certs, then the ability to
reasonably enforce such UI is contingent upon believing no CAs will be
issuing such certs.

The situation you describe - which doesn't arise until Jan 2016 - however,
relies not upon CAs, but in server operators to properly configure their
servers to do such switching. I think we have ample evidence that servers
will be misconfigured, thus our browsers will see these post-2016 SHA-1
certs, thus we will be unable to take reasonable UI action because the
failure rate will be so high. In short, it would force us to postpone the
2016 deadline.

Having experienced similar discussions for MD5 deprecation, I have no
appetite for that. I think it's reasonable that by 2016, if you're still
running a 15 year old OS, you'll have a bad time. And not just because
SHA-1, but because SNI, ECDSA, etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141003/95268b71/attachment.html