Re: Requirements for Secondary Certificates (#522)

I don't see adding a new OIDs as a big barrier for adoption as long as
there is no requirement for the certificate used to set up the TLS
connection to contain the OID. The initial use case for secondary server
certificates is to let large sites with sub-resources hosted on other
domains make use of connection coalescing, so as long as the domains that
contain popular shared content are willing to re-issue a certificate, sites
can still retain their current certificates and take advantage of this
optimization.

Nick

On Tue, Apr 10, 2018 at 4:37 PM Ryan Sleevi <ryan-ietf@sleevi.com> wrote:

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