Critical-ness of CanSignHttpExchanges extension

[irori]

This came up in https://crrev.com/c/1111485.

https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#cross-origin-cert-req

Conforming CAs MUST mark this extension as critical, and clients MUST NOT accept certificates with this extension in TLS connections (Section 4.4.2.2 of [I-D.ietf-tls-tls13]).

In Chrome, certificate path building and verification is performed using underlying operating systems' API. So, if the CanSignHttpExchanges extension is marked as critical, the OS API will reject the cert, until the OS supports CanSignHttpExchanges extension.

Can we revisit the critical-ness of this extension? What's the security implication of not marking it as critical?

cc: @sleevi @jyasskin

[sleevi]

Thanks for filing, @irori! My understanding is that this could still be a potential issue for Edge/Safari, unless browser updates are strictly locked to OS updates (since the crypto APIs are controlled by the OS)

By making it critical, it ensures no existing application can use Signed Exchange certs in TLS - that is, it forces key separation by technological means. This minimizes risk for cross-protocol issues, and for ecosystem issues, by ensuring that 100% of (well-behaving) clients will reject Signed Exchange certs being used for TLS.

However, it presents its own set of compatibility issues - every certificate verifying application has to be updated to recognize this extension - and, in general, OS and cryptographic libraries don't let applications extensibly say "I know and recognize this extension", which means they also have to be updated to recognize this extension.

If we make it non-critical, then there's the risk that users can end up deploying their Signed Exchanges key on their TLS endpoint. This doesn't undermine the signature scheme of Signed Exchanges, but it does present certain operational risks - particularly, if your TLS edge is compromised and that key is compromised, folks can MITM users without requiring an active-network presence.

We can mitigate that risk by having Signed Exchange supporting TLS clients refuse to connect to TLS servers that present this extension. That is, if the certificate for an on-the-wire exchange contains this extension, fail the connection, in the same way that if a certificate in a signed exchange lacks this extension, the exchange fails validation. This creates the ecosystem disincentive to deploy your signed exchange key at your TLS server - but runs a chicken and egg problem of if a bunch of users do this before browsers start shipping signed exchanges, the ecosystem could end up more broken once they do ship exchanges.

Despite this, I think making it non-critical is fine. For example, there's nothing (at present) preventing a CA from issuing a TLS server cert and a "signed exchange server cert" using the same underlying key and CSR - providing two certificates, one with the extension and one without. This has all of the same security problems I just described above, and is not mitigated by the critical extension.

More broadly, I think the best way we can capture this is by making sure we have a "Security Considerations" section that details the risks from improper key hygiene, which can cover these scenarios in depth. This is somewhat captured in https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.6.4 and https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.6.2 but may be worth fleshing out more comprehensively as its own bit.