Re: Requirements for Secondary Certificates (#522)

... or wait for the usual refresh cycle and have the OID added as the
refresh happens.

For someone doing BYOC with concerns about coalescing, they don't add the OID.

I'm not seeing a significant deployment hurdle here either, frankly.
As Ryan and Nick both say, the bump that exists seems small enough for
someone who wants to use the feature, but sufficiently difficult for
an attacker to cross for someone who doesn't want the exposure the
feature comes with.

So, if anything, the concerns I have are about adding yet another knob
and making certificates that much larger, but those are minor
concerns.

Separately, I'm interested in what interaction we might insist on with
delegated credentials, if any.  I'm not seeing one right now, and
keeping them orthogonal seems easiest.

On Wed, Apr 11, 2018 at 8:46 AM, Nick Sullivan
<nicholas.sullivan@gmail.com> wrote:
> 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.

Received on Wednesday, 11 April 2018 01:57:13 UTC