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
draft-bishop-httpbis-http2-additional-certs
<https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-05>.
The proposed text change is on Github (
https://github.com/httpwg/http-extensions/pull/709). 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
questions.

--

*Risks*

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

Without secondary certificates, to impersonate mysite.com to a victim, the
victim would have to attempt to connect to mysite.com 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 mysite.com.

With secondary certificates (as is), the attacker gains the ability to
impersonate mysite.com 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 mysite.com
- Victim connects to phishing.com
- Attacker sends CERTIFICATE and ORIGIN for mysite.com on the connection
- Victim sends credentials for mysite.com 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
extension.

--

*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, mysite.com), and a number of affiliated domains that are
used to host subresources (say, myvideos.com and myjavascript.com).

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

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

If an attacker compromises the myjavascript.com certificate, they are not
able to use it as a secondary certificate on a connection to phishing.com
because their phishing.com certificate is not authoritative for mysite.com.
In order to use the myjavascript.com certificate as
a secondary certificate, the attacker would need to compromise a
certificate for mysite.com and hijack mysite.com 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 (customer1.com,
customer2.com, etc.) and each customer has a unique certificate. Say N of
these customer sites share a common subresource (such as a JavaScript
library from ourjavascript.com). In this scenario, ourjavacript.com 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
ourjavacript.com 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 "cdnglue.com" only). We call these "glue" certificates.

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

Whenever a visitor goes to customerX.com, the CDN adds cdnglue.com to the
set of authoritative domains for the connection by sending ORIGIN for
cdnglue.com and CERTIFICATE for the "glue" cdnglue.com certificate for
customerX.com as a Required Domain. Then if the visitor navigates to a page
containing subresources from ourjavascript.com, the server sends ORIGIN for
ourjavascript.com and CERTIFICATE for the certificate that covers
ourjavascript.com. This adds ourjavascript.com 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
ourjavascript.com, 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
mysite.com. Just like in the key compromise scenario, the attacker would
need to be on-path or compromise DNS to hijack mysite.com.

The attacker could also trick the CA into issuing a certificate for
mysite.com that contains phishing.com as its Required Domain. The attacker
could then implement the same attack described in Scenario 1: if they can
trick the victim into visiting phishing.com, then they can compromise the
credentials for mysite.com 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.:
myjavascript.com.  CAA 0 requireddomain "mysite.com"

--

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
extension.
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 mysite.com and phishing.com. The attacker could then implement the
same attack described in Scenario 1: if they can trick the victim into
visiting phishing.com, then they can compromise the credentials for
mysite.com by sending an ORIGIN frame for mysite.com (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.


Nick