Requirements for Secondary Certificates (#522)

In my silliness, I thought there hadn’t been enough activity to warrant allocating time to Secondary Certs at IETF 101.  😊  Instead, we had a brief but lively discussion and hit on an important divergence of concerns where Secondary Certificates are concerned.

Let’s start by thinking about the threat model.  The attacker has obtained a certificate that’s valid for a victim origin.  There are two main ways this could happen:

  *   Misissuance
  *   Key compromise
Now the attacker wishes to convince users to contact it and believe it regarding the contents of the victim origin.

In the case of misissuance, the certificate can be issued to cover both the victim origin and an attacker-controlled origin.  Such misissuance can be detected through Certificate Transparency, so while it’s certainly a threat, the risk of being discovered is higher and there’s documentation of an attacker-controlled domain that might serve to identify the attacker (or at least burn a domain it controls).  The certificate should be revoked in short order, so checking SCT and OCSP is a good client mitigation here.

If the misissued cert doesn’t cover the attacker’s domain, then the attack looks much like a key compromise:  The attacker has to also compromise either DNS or BGP to get traffic flowing to it.  (Or Alt-Svc, though that should only work if the victim wasn’t using HTTPS to begin with.)  If it’s a misissued cert, the remedies look much the same:  Find a certificate in the CT logs for your domain that you didn’t request, get the certificate revoked, and OCSP is your friend.  For a key compromise, you’d need to detect either the breach or the DNS/BGP subversion to identify the attack.

That’s the world as it exists today.  Now, enter Secondary Certificates.

You no longer need the domains to be on the same certificate, so no breadtrail.  The misissued certificate case is effectively identical; the attacker does less work (no DNS/BGP), but the remedy is the same.  However, taking advantage of a key compromise becomes as easy as a misissued SAN cert for both hostnames, while detection by the victim origin becomes almost impossible.

That’s the problem, and we’re in search of solutions.

One proposal is to define a new OID and require it to be on any certificates that servers present as Secondary.  This poses substantial deployment problems.  For one thing, what IT department is going to approve marking their certs with the “we’re fine if this gets compromised” OID?  Further, the likely server implementers of this functionality are going to be the few giant companies with many varied domains, and the CDNs.  From the CDN side, I can say this will be very difficult to deploy if we require every customer certificate to be re-issued with the specific intent of turning on this feature.  Difficult to the point that it might slow implementation, because the payoff for us is dramatically reduced.  (From the giant company side, the front-end acts effectively like a CDN and might well wind up with the same situation.)

Another idea is to require the thing presented by the server to be, not a certificate, but a delegated credential (see draft-ietf-tls-subcerts).  However, that has very similar concerns since subcerts requires the certificate to explicitly opt in to Delegated Credentials.  That is a more general capability that people are likely to adopt more willingly.  The key compromise threat model looks almost exactly the same, though, since once the key is compromised you can mint a delegated credential.  (And there’s also the fact that it’s a -00 draft that probably has a lot more runway before it lands in browsers.)

How can we best balance the origin’s concern with detecting impostors with the server operator’s concern of deployability?