Re: Requirements for Secondary Certificates (#522)

On Tue, Apr 10, 2018 at 4:09 PM, Mike Bishop <mbishop@evequefou.be> wrote:

> That seems solvable in the long-term -- if it's a defined OID, then it
> eventually wouldn't be a "special request" but simply an option included as
> part of your request.  But certainly it will slow adoption, as first these
> CAs need to be updated to permit it.
>
> To Ryan's question, it's a mix of concerns.  First, a fair segment of our
> customers are BYOC, so Let's Encrypt doesn't help them.  For those where we
> control the certificate provisioning process, the issue is this:  We've
> already received feedback that the origin of the primary connection wants
> control over whether "their" connection can be re-used and for which
> origins.  That doesn't entirely make sense to me, but it's there.


Just to make sure I understand this - today, for the automated provisioning
of certificates, you address this by ensuring that these mutually-exclusive
domains (or those for which the customer has approved) don't both appear in
the subjectAltName of a Certificate, correct? And with Secondary
Certificates, you would need to ensure you don't advertise support for that
origin on that connection.

As to the use case, that makes perfect sense to me for customers that would
be concerned about being used as 'collateral damage' for content that might
otherwise try to be blocked. For example, if a given network was prone to
block 'evil.example.com' (which today such networks might accomplish via
inspection of SNI, of TLS-SNI, and of returned Certificates in handshakes),
they would also have to block 'good.example.com' in the case of H/2
coalescing - thus collateral damage. While such mechanisms are getting more
difficult to implement (DNS-over-HTTPS, TLS1.3), market forces are still
such that the collateral damage risk of domain fronting is a reasonable
thing to be concerned about. Similarly, such customers might be worried
about the asymmetry between the assumptions of, say, the Web Security model
(if considering HTTPS) or other, protocol-specific risks, in which sharing
the same connection for otherwise mutually-untrusted services might provide
an information leak. But I digress :)


> We've so far agreed to swallow that, but also requiring opt-in in the
> reverse direction seems likely to result in a relatively low total opt-in
> rate.  To be clear, that conclusion is primarily intuition from having had
> features that were opt-in rather than opt-out in the past, but it's shared
> by others involved with the feature that I've talked to.
>

I agree that, in practice, this will make it significantly harder to
accidentally deploy - but I think that's part of the goal of such a design
that requires opt-in, given the potential risks and new surface it exposes.
It's not desired to make it more difficult to intentionally deploy,
although some of that may be unavoidable. The introduction of Secondary
Certificates seems like it would remove what otherwise constitutes a
high-barrier for misuse of a compromise key (namely, DNS compromise, BGP
hijack, or on-network presence), making it readily available at scale for
abuse. To the extent we can design protocols that either require consent to
such protections (opt-in), or to designs that allow for separation of key
material (delegated credentials, short-lived certificates), it's really
about just trying to restore that barrier to compromise.


> I see the point about subcerts allowing the primary certificate to be kept
> at higher security.  Regardless, we need to ensure that a delegated
> credential can be used with Secondary Certificates, so that operators can
> move in that direction.  I think that's probably the right long-term place
> to end up -- the question is whether we require everyone to start there,
> too.


I'm guessing for the BYOC scenario, short-lived certificates as an
alternative to delegated credentials isn't meaningfully different, but it
may be worth keeping in consideration as an alternative that is presently
available today for experimentation.