Re: Requirements for Secondary Certificates (#522)

On Tue, Apr 10, 2018 at 11:13 AM Mike Bishop <mbishop@evequefou.be> wrote:

> 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.
>

If the main problem is that Secondary Certificates make detecting
compromise more difficult, would it help to have clients make a parallel
connection to the DNS-discovered IP address that simply reports who's using
the server's identity? I think it's safe for this connection to fail open,
since if the attacker's network-privileged, they didn't need to use
Secondary Certs.

Downsides:
* This tells network monitors which domain the user has connected to via
SNI, where Secondary Certs could have otherwise hidden that information.

Non-downsides:
* Data from the maybe-exploited domain could flow over the original
connection while the parallel connection is being established. It doesn't
slow anything down.
* The original connection could handle all of the congestion control. The
parallel connection could just close after delivering its report.

Apologies if this suggestion is naive. :)
Jeffrey

>