Required Domain proposal for Additional Certificates

HTTP Working Group,

In the meeting on Thursday, Mike Bishop presented a proposal that has been
under discussion to add a new requirement for certificates to be used as
secondary certificates on an existing connection as part of
The proposed text change is on Github ( There was some
confusion at the mic that I'm hoping to clear up with this post. It's a bit
long, so bear with me.

Overview: I'll first explain the additional risks posed by the current
secondary certificates draft, then explain the proposed certificate
extension, how the new requirements will work operationally, and list open



*Risk #1: Key compromise*
An attacker compromises a key for a certificate that covers

Without secondary certificates, to impersonate to a victim, the
victim would have to attempt to connect to and then the attacker
would need to intercept the victim's connection and present the compromised
certificate in the TLS handshake. This attack requires either compromising
the DNS or being on-path between the victim and

With secondary certificates (as is), the attacker gains the ability to
impersonate without compromising the DNS or being on-path if
they are able to induce the victim to visit any site under their control
(via phishing, for example).

The attack works as follows:
- Attacker compromises certificate for
- Victim connects to
- Attacker sends CERTIFICATE and ORIGIN for on the connection
- Victim sends credentials for to the attacker over
the coalesced connection

Giving an attacker an additional capability is something we want to avoid.

*Risk #2: Certificate Misissuance*
This is a different scenario that I'll cover further down.


*Proposal (simplified)*

In order for a certificate to be used as a secondary certificate, the
certificate MUST contain a new OID called "Required Domain" that contains a
single entry containing one hostname. A certificate can only be used as
secondary on an existing connection if that connection is already
authoritative over the hostname listed in the certificate's Required Domain


*Deployment Scenarios*

There are two major deployment scenarios: single web property and CDN.

*Scenario 1, Single Web Property*
In this scenario, a web property has a main domain that most users use to
navigate it (say,, and a number of affiliated domains that are
used to host subresources (say, and

The site operator obtains two additional certificates, one for
and one for Both these certificates contain a
Required Domain extension that contains "" as its hostname. If
the page that the visitor navigates to contains subresources from, then the server sends ORIGIN for and
CERTIFICATE for the certificate that covers The client
then re-uses the existing connection to download the subresource. This
prevents the browser from having to create a new connection for, which saves a TLS handshake and a DNS lookup, which can
result in better performance.

If an attacker compromises the certificate, they are in the same
situation that we are in today: they need to be on-path or modify DNS to

If an attacker compromises the certificate, they are not
able to use it as a secondary certificate on a connection to
because their certificate is not authoritative for
In order to use the certificate as
a secondary certificate, the attacker would need to compromise a
certificate for and hijack by being on-path or
modifying DNS.

This scenario emphasizes why the Required Domain proposal eliminates the
additional risk introduced by Secondary Certificates in the case of key
compromise. By specifying the domain you expect to already be authoritative
over *at issuance time*, Required Domain prevents an attacker from using a
compromised certificate on a "random" domain.

*Scenario 2, CDN*
In this scenario, a large CDN has many customers (,, etc.) and each customer has a unique certificate. Say N of
these customer sites share a common subresource (such as a JavaScript
library from In this scenario, is also
a customer of the CDN. Secondary certificates can be used to improve the
performance of these N sites by improving the load time of the common
subresource as follows:

The CDN issues N certificates. Each of these certificates contains a
Required Domain extension listing a different customer domain that has as a subresource. All of these certificates are valid for
a single domain which is under the control of the CDN (e.g. the Subject Alt
Name contains "" only). We call these "glue" certificates.

Now, issues a certificate for
containing a Required Domain extension containing and gives it
to the CDN. This is the certificate the CDN will use to prove it is
authoritative for using Secondary Certificates. Note that
this certificate can only be used in connections that have already proven
control over

Whenever a visitor goes to, the CDN adds to the
set of authoritative domains for the connection by sending ORIGIN for and CERTIFICATE for the "glue" certificate for as a Required Domain. Then if the visitor navigates to a page
containing subresources from, the server sends ORIGIN for and CERTIFICATE for the certificate that covers This adds to the set of domains the
server is authoritative for on the connection. The client fetches
subresource over this existing HTTP/2 connection.

This prevents the browser from having to create a new connection for, reducing the overall number of HTTPS connections between
the client and the CDN and potentially improving performance.

Similar to the story in Scenario 1, compromising any of these certificates
does not give the attacker any advantage compared to the current situation.


*Risk #2: Certificate Misissuance*

Say an attacker tricks a CA into issuing them a certificate that covers Just like in the key compromise scenario, the attacker would
need to be on-path or compromise DNS to hijack

The attacker could also trick the CA into issuing a certificate for that contains as its Required Domain. The attacker
could then implement the same attack described in Scenario 1: if they can
trick the victim into visiting, then they can compromise the
credentials for by sending the misissued certificate as a
secondary certificate.

This is unfortunate because it increases the utility of a misissued
certificate to an attacker. However, because the Required Domain is part of
the certificate, there are some mitigating factors:
- Any misissued certificate can be detected in the certificate transparency
logs and revoked.
- Required Domain provides a breadcrumb pointing to the site used to launch
the attack. The site can be blocked immediately if the revocation status is
slow to propagate.

Furthermore, since the Required Domain extension is new, it may be possible
to include additional domain validation requirements for CAs in order to
make misissuance much less likely. For example, we could define a new CAA
extension that contains the possible set of Required Domains and update the
BRs to require CAs to check this CAA extension before issuing a certificate
with the Required Domain extension.

e.g.:  CAA 0 requireddomain ""


Open questions:

*Format of Required Domains*
I described the Required Domain extension here as containing only a single
domain. In order to reduce the number of certificates necessary in the CDN
case, it could be useful to:

a) Make the Required Domain syntax the same as the Subject Alt Name
This would allow things like multiple domains, wildcards or IP addresses,
greatly reducing the number of glue certificates needed. It might also make
it easier to parse with existing code. This seems about right to me.

b) Allow Required Domain to have a "allow use as secondary on every
connection" flag. Mike described this in his slides as *. Having this
ensures that every CDN only needs a single glue certificate. This opens up
the certificate to being used in the attacks described above and removes
the breadcrumbs left in CT. I'm unsure about this because it seems like
something that risks being used too broadly, resulting in higher risks in
the case of certificate compromise.

Opinions welcome on both these points.

*The ORIGIN DNS question*
This same analysis applied in the misissuance scenario above can be applied
to ORIGIN. The attacker could trick the CA into issuing a certificate for
both and The attacker could then implement the
same attack described in Scenario 1: if they can trick the victim into
visiting, then they can compromise the credentials for by sending an ORIGIN frame for (since DNS is skipped).

The proposal to strengthen the issuance requirement for Required Domain
helps reduce the risk of misissuance happening for secondary certificates,
but ORIGIN can be leveraged for all existing certificates. This suggests
that the working group's consensus is that this misissuance risk is not one
that should be strongly considered in this document. In that light, it may
even be that the additional validation requirements for Required Domain I
suggested under Risk #2 are overly cautious. Clearly, the answer is to
retroactively require CAA for all certificates! I jest, but I think it's
important to weigh the benefits against the potential risks and operational
considerations for deployability.

To deal with this apparent conflict, I could see UAs making the choice to
implement ORIGIN in a compliant way (skipping DNS validation), but only
doing so for names covered by certificates that have passed the more
stringent Required Domain CAA validation suggested here. I'd be interested
in hearing what browser vendors think of this proposal and how they plan on
implementing it.


Received on Saturday, 30 March 2019 01:17:41 UTC