Subject: Required Domain proposal for Additional Certificates

From: Nick Sullivan <[email-masked]>
Date: Sat, 30 Mar 2019 00:59:28 +0100

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

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 29 Mar 2019 22:27:48 -0400

On Fri, Mar 29, 2019 at 9:20 PM Nick Sullivan <[email-masked]> wrote:

> - Any misissued certificate can be detected in the certificate
> transparency logs and revoked.
>

I'm not sure that this is a meaningful mitigation, and thus the implied
value it provides may be overstated here.

This is because we need to acknowledge that while Certificate Transparency
is a technology with a spec that describes the technical implementation
(RFC 6962), much like RFC 5280 does not dictate how to select 'trust
anchors', RFC 6962 does not dictate how clients can or should use
Certificate Transparency. As such, the conclusion here - detection - is
implicitly assuming certain deployment/policy-level properties that haven't
been enumerated, in the pull request or in the original secondary certs
draft.

Further, while CT provides a sound set of cryptographic building blogs to
enable the detection of, say, split log views, clients themselves need to
deploy mechanisms to allow that. This is also a policy consideration - in
that different approaches, such as gossip or proof-stapling - have their
own set of privacy and performance tradeoffs and assumptions.

It also further makes assumptions about the capabilities of clients
regarding revocation and/or out-of-band delivery mechanisms. Revocation is
not merely a technology matter, but as shown through the use of revocation
for censorship purposes, one that has a policy angle that needs to be
carefully considered. The assumption of mitigation here, being revocation,
is one that seems to presume certain solutions for this space. Similarly,
the assumption of out-of-band delivery methods for blocking a site (if
revocation is slow to propagate) similarly presumes an out-of-band update
mechanism.

While it's certainly true that risks - such as on-path adversaries or
misissued certificates - exist independent of the CERTIFICATE frame, there
may be a disagreement about the relative cost of the attack compared to the
value it provides. It strikes me as something similar to the debate about
SHA-1 vs SHA-256 for signatures. While there are significant similarities -
they're Merkle-Damgard constructions, they're both crytographci hash
algorithms - there's also a significant difference in the work-factor/cost
to exploit, by many orders of magnitude. Similarly, while the 'utility' of
a SHA-1 certificate also is limited by an attacker's on-path premise, and
while CT (in an idealized form) may provide detection, I don't think many
would advocate that SHA-1 is safe to use because of these mitigations.

Separately, but perhaps just as importantly, this overall analysis it seems
to have overlooked the attack scenario of BygoneSSL (
https://insecure.design/ ). Considering how many CDNs were/are vulnerable
to this, I'm concerned that this solution fails to meaningfully address
that threat model, which is more about "misconfiguration" than "actively
malicious" (although they are admittedly hard to distinguish)

Given the significant investment in technologies that this proposal would
seem to necessitate - from implementing and deploying an RFC 6962 solution
(and associated policy), reliance on unreliable revocation information or
out of band delivery mechanisms, requiring site operators to add yet
another source of information to actively monitor (by effectively mandating
all domains monitor CT to prevent easy MITM), exacerbating the risks of
situations like BygoneSSL, all CAs implementing yet more validation checks
- perhaps its worth evaluating the benefit such a solution would provide.
Based on your description, it seems that the primary goal is saving 1
connection and 2 RTTs. That does not seem a very cost-effective tradeoff,
but perhaps I've misunderstood the calculus?

While I understand and appreciate the comparison to ORIGIN, its worth
nothing that there seems to be limited industry uptake of the ORIGIN frame,
in part due to the considerable security risks. Perhaps this is a signal
that the calculus was wrong there as well?

---

From: Nick Sullivan <[email-masked]>
Date: Sat, 30 Mar 2019 14:10:04 +0100

Hi Ryan,

Thanks for your reply.

> own set of privacy and performance tradeoffs and assumptions.

Maybe I wasn't clear. I'm not suggesting that UAs should
detect misissuance on the client. I am suggesting is that operators can
detect misissuance via CT monitoring. The majority of publicly-trusted
certificates are already included in a set of CT 'trust anchors' trusted by
multiple UAs. Many server operators leverage CT monitoring to detect
misissuance on their domains to great effect.

> revocation is slow to propagate) similarly presumes an out-of-band update

Because the trade-offs involved in revocation checking are judged
differently by different UAs, what we can do here is provide reasonable
recommendations.

It was previously suggested that UAs may choose to require OSCP stapling in
order to accept a secondary certificate -- this seems like a reasonable
requirement but it leaves the client open to attack for the lifetime of the
last valid OCSP response. If the OCSP lifetime is too long for comfort, UAs
may also require that an out-of-band mechanism is in place and has been
updated within a more reasonable amount of time.

> would advocate that SHA-1 is safe to use because of these mitigations.

This is a particularly good strawman. Would this still hold if there were
additional issuance requirements for SHA-1 certificates that, if violated,
would result in disqualification of the CA?

> Separately, but perhaps just as importantly, this overall analysis it
> seems to have overlooked the attack scenario of BygoneSSL (

I'm familiar with this issue but not the proposed resolution. Even if
certificates were revoked when a customer changes CDNs, some UAs don't
check for revocation on the vast majority of certificates. This scenario
suggests that for Required Domain certificates, clients should check
revocation before accepting them as secondary.

> but perhaps I've misunderstood the calculus?

The benefits fall into two categories: performance and privacy.

The performance savings are 1 connection, 2-RTTs, and a DNS resolution per
domain that is coalesced. The savings are front-loaded at the beginning of
the HTTP/2 connection, so they have a good chance at improving page loads
times for users in real scenarios. On the server side, each coalesced
domain results in one fewer live connection and one fewer handshake. For
servers that handle thousands of simultaneous connections, no longer having
to do redundant handshakes and maintain redundant TLS connections can
result in substantial efficiency gains.

The privacy benefits are also quite clear. DNS queries leak the hostname of
the subresource to the network (or the resolver in the case the UA is using
DoT or DoH). Not doing a second HTTPS connection prevents the SNI from
being leaked to the network in the absence of ESNI.

As an operator, you still need to make the investments you listed (logging
certs in CT, CT monitoring, relying on revocation, relying on CAs to not
misissue) if you want to prevent your site from being hijacked by "slightly
less easy" MITM. If an attacker obtains a misissued certificate for your
site, then they can hijack it without being on-path or hijacking BGP by
leveraging a DNS Fragmentation attack (
https://blog.powerdns.com/2018/09/10/spoofing-dns-with-fragments/), for
example. The DNS is a very weak a second factor to protect against MITM.
We're in a bad place right now with respect to misissuance, pretending
we're on solid ground by checking DNS is not helpful.

Adding an additional OID whose use encourages better operational practices
by operators and enforces safer validation by CAs while providing multiple
privacy and performance benefits seems to be a net positive.

> that the calculus was wrong there as well?

Correct me if I'm wrong, but don't both Firefox and Edge skip DNS
validation when connecting to domains on the SAN list of the primary
certificated in the presence of ORIGIN?

In any case, ORIGIN is scoped to work for any certificate so it carries
with it the baggage of the existing web PKI. This calculus may be different
with new validation requirements. Requiring stronger validation for
certificates that enable new capabilities is a pattern I've seen be
successful for projects like SXG. I'm hopeful that other UAs will chime in
here.

---

From: Ryan Sleevi <[email-masked]>
Date: Sat, 30 Mar 2019 17:50:32 -0400

> misissuance on their domains to great effect.

No, you were clear in your suggestion. I am, however, suggesting that it's
not a meaningful mitigation if you don't also specify the assumptions or
constraints you're making when you say "via CT". Considering that we're
discussing adversarial models, the 'majority' could be 99.7% of issued
certificates, and it would still be woefully inadequate. Similarly, an
assumption about detectability is making a number of assumptions about not
just the set of trusted logs, but also the policies and implementation of
the ecosystem. You cannot suggest it's a meaningful mitigation without
specifying the assumed properties - and the ecosystem has shown there are a
variety of properties one COULD obtain, and even in the existing
deployments, UAs do not all achieve equivalent properties.

I realize get dismissed as a strawman, but I think the inclusion of RFC
6962 as a mitigation here is making too many unstated assumptions, and as a
result, is the technical equivalent of stating a dependency on RFC 3514.
While I think it is possible to make a more compelling and clarified
argument, by enumerating those properties, I felt that the claim that
Required Domain somehow mitigated the second case to be unsupported by the
actual proposal, and thus was calling it out.

> It was previously suggested that UAs may choose to require OSCP stapling
> in order to accept a secondary certificate -- this seems like a reasonable

I don't think we can say it's a reasonable requirement, given these
tradeoffs exist. What I think is more useful, to avoid miring the proposal
in policy debates, is to instead focus on what properties are desired to be
achieved. What does a 'reasonable' amount of time look like, compared to
the existing ecosystem? Is "time" a sufficient replacement for the high
visibility that would come with, say, a BGP hijack.

>> https://insecure.design/ ). Considering how many CDNs were/are
>> vulnerable to this, I'm concerned that this solution fails to meaningfully
>> address that threat model, which is more about "misconfiguration" than
>> "actively malicious" (although they are admittedly hard to distinguish)
>>
>

The authors of that research have recommended significantly reduced
certificate lifetimes as a mitigation, rather than relying on revocation as
the primary mitigation. This is not a new tradeoff - Dan Geer's "Risk
Management is Where the Money is" -
https://cseweb.ucsd.edu/~goguen/courses/275f00/geer.html - looked at a
number of these tradeoffs, and how the costs of revocation are unequally
distributed.

However, I don't think we should be so quick to paper over the issues by
focusing too much on revocation or reduced lifetimes as the way of
mitigating the second-order risks of CERTIFICATEs. To do so would be to
ignore that we're at a more fundamental debate about the primacy of the
domain name system to deliver information versus other systems. This is a
more fundamental design issue, and BygoneSSL is merely a symptom of the
incongruous lifetimes (between certificates and the DNS information), which
the CERTIFICATE frame would exacerbate.

> times for users in real scenarios.
>

Do you have data to support this? Much like HTTP/2 PUSH, I think we can
imagine 'idealized' models of how this SHOULD improve performance, but the
practical reality is often far from it, and hardly realized. This is core
to not just thinking about the cost to implement such a specification
(which, as mentioned previously, is significantly higher), but also the
cost to engage in the specification effort itself, given the number of very
difficult security tradeoffs that need to be rationalized here, with the
natural tension between being "as secure as" today (and e.g. the noisiness
of a BGP hijack) and "not astronomically costly to implement" (as it is
presently).

> On the server side, each coalesced domain results in one fewer live
> connection and one fewer handshake. For servers that handle thousands of
> simultaneous connections, no longer having to do redundant handshakes and
> maintain redundant TLS connections can result in substantial efficiency
> gains.
>

Isn't this largely a consequence of the increased centralization of those
servers? That is, it seems the cost is born by client implementations -
which I think extends far beyond merely contemplating UAs, unless this is
truly meant to be something "only browsers do, because if anyone else does
it, it's not safe/useful" - in order to accommodate greater centralization
by the servers. I ask, because given the costs, a more fruitful technical
discussion may be exploring how to reduce or eliminate that centralization,
as an alternative way of reducing that connection overhead.

> The privacy benefits are also quite clear. DNS queries leak the hostname
> of the subresource to the network (or the resolver in the case the UA is
> using DoT or DoH). Not doing a second HTTPS connection prevents the SNI
> from being leaked to the network in the absence of ESNI.
>

I find these three sentences actually highlighting why the privacy benefits
are not clear. ESNI has far fewer of these sharper edges, so does that mean
it would be more fruitful and useful to focus on improving that adoption,
rather than adopting a "try everything" approach? Similarly, the discussion
of DoT/DoH seems to have considered a degree of trust in the resolver -
considering that some of them are proposing to be audited against privacy
policies. I totally understand that the best solution to privacy is a
technology solution, where possible - hence things like ESNI - but I do
want to highlight that the fairly significant and substantial costs here,
which haven't really been articulated due to the hidden assumptions make it
difficult to see this as necessarily progress.

I think it'd be much more fruitful to focus on what the properties are,
rather than attempting to iterate on technical solutions with hidden
assumptions or dependencies. I suppose we'd treat that as a "problem
statement" in IETF land, much like we might pose it as an "Explainer"
within groups like WHATWG, which try to set out and articulate the problems
and need for a solution, and then iterate on the many assumptions that may
be hidden beneath those statements.

> certificated in the presence of ORIGIN?

I was thinking of
https://tools.ietf.org/html/draft-bishop-httpbis-origin-fed-up in
particular. I don't know what Firefox or Edge are doing in this regard, but
I haven't heard much support from other HTTP/2 implementations deploying
it. Do you know if curl or wget have deployed this?