Subject: Requirements for Secondary Certificates (#522)

From: Mike Bishop <[email-masked]>
Date: Tue, 10 Apr 2018 18:03:37 +0000

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?

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 10 Apr 2018 21:42:56 +0300

On Tue, Apr 10, 2018 at 06:03:37PM +0000, Mike Bishop 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.

Also, the following occured to me recently. Even if secondary
certificates do incorporate secure nonce and thus one can not
pre-sign responses, the attack window is much larger than with
TLS key exchange. Thus, if if the certificate has RSAEncryption
key and the server is vulernable to BB98 (a.k.a. ROBOT), the
attacker might be able to obtain a signature.

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

Yeah, that is going to have deployment problems.
 
> 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.)

Also, delegated credentials would be even more vulernable to BB98
(ROBOT) if used with RSAEncryption keys.

-Ilari

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 10 Apr 2018 15:11:15 -0400

> Yeah, that is going to have deployment problems.

I'd like to understand more about these deployment problems. It seems these
are based on assumption of long-lived certificates and the difficulty of
obtaining new certificates. However, a number of CDNs and large providers
are using automated APIs for their issuance and renewal, and a number of
CAs offer automated APIs for end-users, including, notably, Let's Encrypt.

I can understand that this might have been true a decade ago, but it seems
reasonable to challenge the claim now as to difficulty - at least for those
providers that aren't BYOC.

Similarly, the concerns around appearances - the 'compromise me' flag - is
one way of framing the discussion, but isn't this fundamentally the
security tradeoff being discussed? That is, that unless servers take
meaningful steps and are aware of the risks, this weakens the security
assurances that servers have by default - and that clients and networks
implicitly rely on (or, in the case of things like DNS-over-HTTPS and
BGPSec, explicitly rely on)

> > runway before it lands in browsers.)

While I agree that it looks similar, there is a meaningful difference in
the ideal deployment - namely, in a Delegated Credentials model, you can
keep your DC signing key offline or in a higher protected (possibly
airgapped or HSM protected) network, while your delegated credential key is
short-lived and distributed. Now, in practice, if you reuse the key in a DC
model, then the concerns are similar - and if you don't take steps to
separate out the key protection lifecycle, the concerns are similar. Thus,
to a client, the security assurances are similar - but to a server, there
are steps they can take in DC that they cannot take with a Secondary
Certificate (due to the effective online-signing requirement)

It's worth noting that in addition to the similarities between Secondary
Certificates and Delegated Credentials (in terms of oracles and
compromise), there are also similarities to Signed HTTP Exchanges (
https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html
) - in that potentially third-party domains can assert (by providing a
signed exchange) control over a domain.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 10 Apr 2018 22:37:27 +0300

> CAs offer automated APIs for end-users, including, notably, Let's Encrypt.

The thing I am concerned about is one able to get suitable certificate
at all, or if it requires some nasty (unscalable) "special request" (which,
e.g., Let's Encrypt never does).

-Ilari

---

From: Mike Bishop <[email-masked]>
Date: Tue, 10 Apr 2018 20:09:29 +0000

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, April 10, 2018 12:37 PM
To: Ryan Sleevi <[email-masked]>
Cc: Mike Bishop <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: Requirements for Secondary Certificates (#522)

On Tue, Apr 10, 2018 at 03:11:15PM -0400, Ryan Sleevi wrote:
> I'd like to understand more about these deployment problems. It seems 
> these are based on assumption of long-lived certificates and the 
> difficulty of obtaining new certificates. However, a number of CDNs 
> and large providers are using automated APIs for their issuance and 
> renewal, and a number of CAs offer automated APIs for end-users, including, notably, Let's Encrypt.

The thing I am concerned about is one able to get suitable certificate at all, or if it requires some nasty (unscalable) "special request" (which, e.g., Let's Encrypt never does).

-Ilari

---

From: Jeffrey Yasskin <[email-masked]>
Date: Tue, 10 Apr 2018 20:20:29 +0000

On Tue, Apr 10, 2018 at 11:13 AM Mike Bishop <[email-masked]> 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.
>
>
>

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

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 10 Apr 2018 16:28:59 -0400

On Tue, Apr 10, 2018 at 4:09 PM, Mike Bishop <[email-masked]> 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.

---

From: Nick Sullivan <[email-masked]>
Date: Tue, 10 Apr 2018 22:46:46 +0000

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 <[email-masked]> wrote:

> 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 :)
>
>
>> I see the point about subcerts allowing the primary certificate to be
>> kept at higher security.  Regardless, we need to ensure that a delegated

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Apr 2018 11:56:46 +1000

... 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
<[email-masked]> 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
>
>> Secondary Certificates, you would need to ensure you don't advertise support
>> for that origin on that connection.
>>
>> 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
>> 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

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 11 Apr 2018 17:01:46 +1200

On 11/04/18 08:20, Jeffrey Yasskin wrote:
> 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.

I don't think it would help at all. Recall that DNS/BGP is already
compromised in order to perform the attack at all. So any side
connection is just as easily caught and faked as the original was.

( Time for a shameless plug about DNSSEC + DANE ? )

Amos

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 11 Apr 2018 11:15:19 -0400

> connection is just as easily caught and faked as the original was.

I think there may have been a misunderstanding. In the Secondary
Certificates case, with key compromise, you can mount the attack without a
DNS/BGP compromise. That is, total effort to mount attack = (key
compromise). Jeffrey's suggestion is to force a connection establishment -
even in the case of a Secondary Certificate offer - such that the effective
steps to compromise require (key compromise) + (BGP hijack, DNS compromise,
on-path presence). Which is roughly the status quo for today in a
non-Secondary Certificate case.

---

From: Jeffrey Yasskin <[email-masked]>
Date: Wed, 11 Apr 2018 15:28:46 +0000

> non-Secondary Certificate case.

That is, effective steps to compromise *without detection*. If the attacker
is willing to be detected, it'd still just take (key compromise).

Jeffrey

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 12 Apr 2018 04:58:11 +1200

On 12/04/18 03:15, Ryan Sleevi wrote:
> 
> 
> On Wed, Apr 11, 2018 at 1:01 AM, Amos Jeffries <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> Certificates case, with key compromise, you can mount the attack without
> a DNS/BGP compromise. That is, total effort to mount attack = (key
> compromise). Jeffrey's suggestion is to force a connection establishment
> - even in the case of a Secondary Certificate offer - such that the
> effective steps to compromise require (key compromise) + (BGP hijack,
> DNS compromise, on-path presence). Which is roughly the status quo for
> today in a non-Secondary Certificate case.

ah, I see. So the aim here is just to plug the new holes added by
secondary certificates. Not to actually increase security beyond the
leaky bucket already existing?

Amos

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 11 Apr 2018 13:38:00 -0400

> leaky bucket already existing?

Yes, I think the goal is to consider the change in security posture that
Secondary Certificates might introduce, in terms of costs/incentives of
attacks and detectability of attacks, relative to existing threats in the
TLS/HTTPS ecosystem. One would also presume that a secondary goal is to
ensure that improvements in other parts of the ecosystem remain applicable
to use cases in which Secondary Certificates are used, or, alternatively,
to ensure that other comparable mitigations exist.

In this model, DNSSEC + DANE may offer a mitigation for DNS attacks, if it
was a reliable system that clients could trust, depending on your threat
model. Similarly, depending on your threat model and concerns,
DNS-over-HTTPS might offer an alternative mitigation. Of course, neither
solution would mitigate risks of, say, BGP hijacking, whereas BGPsec might
be more appropriate.

As attackers have the incentives to attack the weakest link, the goal for
Secondary Certificates reasonably should be do "not be the weak link" -
where weak link, in this conversation, might mean reducing the costs of
attacks or reducing the chance of detection.

---

From: Mike Bishop <[email-masked]>
Date: Wed, 11 Apr 2018 18:04:05 +0000

Basically.  The security of the PKI infrastructure as a whole is something we should strive to improve, but we need not do that with this draft.  With this draft, my goal is simply to not make it worse.

From: Ryan Sleevi [mailto:[email-masked]]
Sent: Wednesday, April 11, 2018 10:38 AM
To: Amos Jeffries <[email-masked]>
Cc: Ryan Sleevi <[email-masked]>; [email-masked] Group <[email-masked]>
Subject: Re: Requirements for Secondary Certificates (#522)

On Wed, Apr 11, 2018 at 12:58 PM, Amos Jeffries <[email-masked]<mailto:[email-masked]>> wrote:
ah, I see. So the aim here is just to plug the new holes added by
secondary certificates. Not to actually increase security beyond the
leaky bucket already existing?

Yes, I think the goal is to consider the change in security posture that Secondary Certificates might introduce, in terms of costs/incentives of attacks and detectability of attacks, relative to existing threats in the TLS/HTTPS ecosystem. One would also presume that a secondary goal is to ensure that improvements in other parts of the ecosystem remain applicable to use cases in which Secondary Certificates are used, or, alternatively, to ensure that other comparable mitigations exist.

In this model, DNSSEC + DANE may offer a mitigation for DNS attacks, if it was a reliable system that clients could trust, depending on your threat model. Similarly, depending on your threat model and concerns, DNS-over-HTTPS might offer an alternative mitigation. Of course, neither solution would mitigate risks of, say, BGP hijacking, whereas BGPsec might be more appropriate.

As attackers have the incentives to attack the weakest link, the goal for Secondary Certificates reasonably should be do "not be the weak link" - where weak link, in this conversation, might mean reducing the costs of attacks or reducing the chance of detection.