Subject: Re: Required Domain proposal for Additional Certificates

From: Nick Sullivan <[email-masked]>
Date: Tue, 2 Apr 2019 00:23:55 -0400

I'm not seeing and disagreement about the assertion that this proposal
solves the issue of key compromise. Let me know if you disagree.

On Sat, Mar 30, 2019 at 10:50 PM Ryan Sleevi <[email-masked]> wrote:

>
>
> On Sat, Mar 30, 2019 at 9:10 AM Nick Sullivan <[email-masked]> wrote:
>
>> 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.
>>
>
> 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.
>

I don't think it's necessary to spell out the exact requirements for "via
CT" in this RFC. I would be fine with a bit of text stating that the UA
should have some expectation that domains owners have the ability to detect
misissuance for certificates used as secondary. The decision and manner to
implement would be left to the UA based on their view of the ecosystem and
risks.

The breadcrumb aspect of how secondary certificates need to include the
attacker's domain is a bonus.

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

As mentioned earlier in this thread, DNS poisoning can happen without a
high-visibility BGP attack. An attacker in possession of a misissued
certificate is a big problem right now because the current DNS is insecure.

A different way to frame this would be in terms of the attacker's
cost/benefit of:
- misissuing a current DV certificate and using it maliciously against
any/all clients
- misissuing a Required Domain certificate from a CA that it enforces
stricter validation checks and using the certificate maliciously against
clients who have implemented secondary certificates and the recommended
guidelines we propose in this document

There is clearly some incremental risk of an attacker misissuing a
certificate with a Required Domain that contains their phishing domain, but
I question whether it's a likely vector given the current state of security
of DV certificates.

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

This scenario seems functionally equivalent to the compromised certificate
scenario but, instead of a malicious attacker, the party that has access to
the compromised certificate key is a friendly party you already have a
business relationship with.

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

We haven't measured the user-visible gains yet, but we hope to collaborate
with a browser vendor to quantify them. I'm optimistic that the performance
gains will be significant given the ubiquity of services like cdnjs and
jsDelivr.

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

I don't want to keep harping on this, but DNS poisoning does not require a
noisy attack like a BGP hijack <https://dl.acm.org/citation.cfm?id=3278516>.
Also, the proposals made here are not astronomically costly to implement,
they're modest steps in the direction the PKI is already going. I see the
recommendations we make in this document as a forcing function in the
direction of more secure web PKI practices.

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

What do you mean by centralization? In the case that I laid out, JavaScript
subresources, if a web server can serve code from a subresource on an
established connection without checking DNS, that means multiple servers
providers can serve the content. This allows content hosts to diversify the
set of TLS terminating proxies they can use simultaneously without using
hacks like the multi-CDN CNAME chain configuration that is causing issues
for the specification of ESNI right now.

>
>> 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 disagree that ESNI has fewer sharp edges. ESNI relies on DNS, and
specifically encrypted DNS. Deploying encrypted DNS at scale comes with its
own difficult policy questions and is years away from any sort of ubiquity.

This proposal acheives a meaningful step towards the "eliminate plaintext
hostnames on the network" goal for web sites. Subresources that are
available from a server that has already been connected to don't have their
metadata leaked. Unlike ESNI, it doesn't have to dabble in the complexities
surrounding putting data in DNS.

If there are hidden assumptions, we should reveal them and add them as text
in the security considerations.

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

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

I don't see how the implementation of ORIGIN by command line tools is
relevant. Browsers are more likely to benefit from connection coalescing in
ways that impact user experience than command-line tools used for bulk
downloads in which shaving off RTTs is less important.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 2 Apr 2019 14:46:32 +0900

> solves the issue of key compromise. Let me know if you disagree.

I tried to focus on the more significant concern, as it highlights
fundamental issues. I did not want to focus on those issues while the
structural issues were still outstanding, but no, I don’t think the
proposal addresses key compromise as presently proposed.

> attacker's domain is a bonus.

Thanks for clarifying. I think this is an area of disagreement we should
figure out how to resolve. I tried to offer a suggestion, by making sure
it’s clear what properties are necessary to achieve the claim that this is
not a fundamental security risk to potential implementors. I don’t think
the suggestion of “use CT” actually achieves this, because one can’t
examine that suggestion and rationalize whether or not a given UA’s
implementation of CT achieves those properties. Furthermore, by not
providing some guidance or assurance that those properties will be met,
site owners can not evaluate whether or not it is safe to enable this
feature, due to the lack of specific guidance to implementors on how to
achieve those properties.

This strikes me somewhat similar to the use of CBC in TLS, and leaving it
as an exercise to the reader as to how to achieve a constant time
implementation. We could opt to make it clear that an implementation MUST
be constant time, we could opt to provide a reference implementation that
achieves the constant time, or we could avoid using it entirely (or
deprecate it from relevant specifications), on the basis that it is a huge
security risk that is best accommodated by different constructions
entirely, rather than trying to safely aim the footgun. I fear the current
proposal doesn’t provide the necessary guidance as to what to expect, for
sites or implementors, and that makes this unacceptably dangerous.

> guidelines we propose in this document

I don’t find that to be a helpful framing, and this may be another source
of disagreement. I fear that this framing encourages us to make insecure
compromises that ossify weaknesses, on the basis that there is something
weaker, rather than address gaps and build stronger systems.

For example, CAs are taking steps to improve and mitigate agains the DNS
attacks mentioned, and we can reasonably expect the industry to continue to
do so, and to continue to mitigate DNS risks. We should not assume this
protocol is safe or secure merely because that’s not universally
distributed yet, and should instead ensure the system is robust even when
these DNS attacks are mitigated. I don’t believe the current proposal gets
there.

> business relationship with.

I think we should be careful about trying to group attacks at this early a
stage. I don’t agree that they are the same. The existence of a past
business relationship doesn’t imply a present business relationship.
Likewise, this scenario is where the Related Domain is still in the
possession of the “attacker”, and the certificate was legitimately
authorized. The technical and policy mitigations are rather significantly
different in this regard, and the proposed solution hardly defends against
it.

> gains will be significant given the ubiquity of services like cdnjs and

It seems like this can be quantified well in advance of needing any UA to
implement. Whether this is modifying existing open-source browsers to
synthetically test, or by gathering the data and quantifying the potential
savings, it seems rather possible to objectively evaluate this based on the
current ecosystem, and to look at a host of metrics that this
hypothetically could affect.

> I don't want to keep harping on this, but DNS poisoning does not require
> a noisy attack like a BGP hijack
> <https://dl.acm.org/citation.cfm?id=3278516>. Also, the proposals made
> here are not astronomically costly to implement, they're modest steps in
> the direction the PKI is already going. I see the recommendations we make
> in this document as a forcing function in the direction of more secure web
> PKI practices.
>

We disagree here as well. The presumptive value of the Required Domain is
based on an assumption of certain properties being met, which are not
enumerated in the proposal, but which it is believed that “use CT” meets.
CT has taken 7 years to reach ubiquitous deployment in a single UA, and
many of the present properties provided to that UA are a result of
non-generalizable policy decisions which other UAs would not want to
implement, given the harm it would cause the ecosystem. That seems like a
rather astronomical costs, especially given the ongoing costs to maintain a
healthy CT deployment and implementation.

If you think there are modest proposals that approximate the value of CT,
without those costs, they would be great to elaborate on in the proposal.
However, I don’t think we should say “This is fine, because CT”, while not
acknowledging the significant cost it has to implement at this time.

> What do you mean by centralization? In the case that I laid out,
> JavaScript subresources, if a web server can serve code from a subresource
> on an established connection without checking DNS, that means multiple
> servers providers can serve the content. This allows content hosts to
> diversify the set of TLS terminating proxies they can use simultaneously
> without using hacks like the multi-CDN CNAME chain configuration that is
> causing issues for the specification of ESNI right now.
>

A server can also serve code on the same origin, far more efficiently, and
with significantly better caching properties in today’s modern browsers, if
our focus is merely interactive user agents, and without these rather
significant security considerations.

To your question though, the certificates only provide a benefit if the
same TLS terminating entity is responsible for both origins - and that
seems to centralize more. If a given service can only be “competitive” with
performance if they collocate on the same CDN as their dependent resources
(such as ad networks or other truly 3P content), then it creates
significant incentives to further internet centralization, right?

> in the security considerations.

I think right now there’s a huge assumption in the detection property,
presumably being met via CT (with a host of assumptions of site operators
jeopardized by the mere existence of this spec), and in the responsiveness,
presumably being handled via revocation. We should be spelling out what a
safe or successful deployment looks like - or more carefully calling out
the risks, both those believed addressed and those unaddressed.

>> be hidden beneath those statements.
I still believe this would be a more useful exercise than comparing to the
PKI and HTTPS system at this point in time today.

> downloads in which shaving off RTTs is less important.

It’s relevant because the overall proposal introduces significant risks,
and whose mitigations don’t have easily deployed options for these clients.
If, say, curl were to implement this feature, but without proposed
mitigations (such as an ambiguous deployment of CT or some out of band
revocation protocol), would that be safe or responsible? For site operators
who are contemplating deployment of this, would a deployment of this by UAs
that don’t feel the mitigations are necessary - as seems to be the present
suggestion, much like ORIGIN left DNS optional - lead to security risk for
site operators who service those users?

This is an area where the comparison to CBC is again apt - that a number of
browser UAs implemented constant time mitigations for CBC still leaves
servers at risk for enabling CBC ciphersuite, due to not being able to be
assured that clients negotiating CBC are actually doing so securely. This
is an ecosystem consideration, but one that seems to directly impact the
deployability of this proposal, which is why it bears consideration. The
purpose of the spec providing guidance here is not “just” for implementors
deploying servers or clients capable of negotiating this - but for the site
operators tasked with obtaining such certificates and wanting to understand
what, if any, properties the spec guarantees if they do so.