Re: Required Domain proposal for Additional Certificates

On Fri, Mar 29, 2019 at 9:20 PM Nick Sullivan <nick@cloudflare.com> wrote:

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

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?

>