Certificates for signed exchanges should be allowed also for TLS connections.

[sebastiannielsen]

I read this in the specification: "Clients MUST NOT accept certificates with this extension in TLS connections (Section 4.4.2.2 of [RFC8446])."

I don't see any specific reason for this. I would suggest removing this completely from specification, and allowing content to be signed with the same certificate as for TLS connections. (provided the certificate is allowed for signed exchanges)

Since a signed exchange have a very specific format, I don't see any risk with for example an site-wide XSS becoming a signing oracle for signing exchanges, unless the administrator explicitly configures the page/server in that way for some specific application. (for example a timestamping service allowing signing of arbitary data which is then time-stamped)

Another way to improve on this, is to have a special magic value for the extension, that will allow dual usage, so if the extension, instead of having the null value ( 05 00 ), have the exact octet-binary value "BOTH" ( 04 42 4f 54 48 ), it will allow dual usage of the certificate.

Thus specification could be instead: "A conforming CA MUST NOT issue certificates with this extension unless, for each dNSName in the subjectAltName extension of the certificate to be issued: An “issue” or “issuewild” CAA property ([RFC6844]) exists that authorizes the CA to issue the certificate; and The “cansignhttpexchanges” parameter (Section 4.2.1) is present on the property and is equal to “yes” or "both". A conforming CA MUST NOT issue certificates with this extension set to "BOTH", unless "cansignhttpexchanges" is equal to "both".

Clients MUST NOT accept certificates with this extension in TLS connections, unless the extension has the exact octet-binary value BOTH ( 04 42 4f 54 48 ) (Section 4.4.2.2 of [RFC8446])."

For this, the cansignhttpexchanges CAA value must also be extended with a "both" option to allow certificates to be issued with the BOTH extension value. (if "yes", it will only allow NULL, but if "both", it will alllow both NULL and BOTH values)

---

I also read this: "TLS server certificates must be accessible from online servers, so they’re easier to steal or use as signing oracles than an offline key. An exchange’s signing key doesn’t need to be online." and this: "Using an exchange-signing key in a TLS (or other directly-internet-facing) server increases the risk that an attacker can steal the private key, which will allow them to mint packages (similar to Section 6.4) until their theft is discovered."

This is very untrue, as most content-signing servers will of course be directly internet-facing. A majority of server operators will just configure their servers to sign static content when requested, or possibly with a client whitelist (like cloudflares IPs) to prevent it from signing content for others. Thus their CanSignHttpExchanges certificate will in most cases, reside side-with-side with their TLS certificate in the same folder on the same machine.

Only more sensitive and advanced companies will make content-signing servers airgapped.

The only way to enforce secure usage of such a certificate and make sure its "airgapped", is to require it to be loaded on a secure element with presence validation. This is a requirement imposed by most CA's for sub-CA certificates.

The only risk I see with completely dropping the restriction, is that a stolen content-signing certificate could be used to host a TLS server used for example phishing attacks and such.

Thats why it might be good to instead use the proposed NULL and BOTH values, so theres 3 types of certificates: 1: Certificates ONLY valid for TLS connections. 2: Certificates valid for BOTH. 3: Certificates ONLY valid for Signed-exchanges.

thus a server operator is able to choose the security level that fits them best.

[sleevi]

Would it be possible to explain why it is desirable?

Cross-protocol attacks have caused a number of severe security issues - as demonstrated by things as “simple” as between QUIC and TLS or TLS1.3 vs TLS1.2. Just as these protocols admonish users to make use of separate keys and identities, it seems there is no significant benefit, compared to the significant risk it introduces to users.

Furthermore, ensuring key separation helps encourage better key hygiene for the purposes being used. This is similar to the discussion of TLS Delegated Credentials, in that separating online and offline key pairs, via distinct technical capability, is highly desirable.

Finally, given that SXGs, as a general technology, come with new trade offs and risks with respect to impersonation (if the key is compromised), the explicit extension also serves to ensure direct and affirmative consent by the site to use SXGs (e.g. via the CAA check)

As such, the use of the extension plays a critical and essential, perhaps irreplaceable, role in the overall security of SXG. It would have to be demonstrated a significant and serious benefit to consider removing, and necessary to introduce comparable security measures. Perhaps the spec can make it clearer why this is such an essential property, so that proposals to remove it can be accompanied with the same thorough and thoughtful security mitigations.

[sebastiannielsen]

1: My stance on it, is that its up to the server administrator if they want to share keys should be able to do that.

2: I didn't say that the extension should be removed. What I said, is that the limitation where a certificate with said extension cannot be used as a TLS server certificate, should be removed. The extension is good and need to be there, as SGX creates new risks.

However, another solution is to extend the extension with the BOTH/NULL alternatives, so the ability of the certificate can be gated into "Only TLS", "BOTH" and "Only SGX", with accompanying CAA checks, so the server administrator can choose exactly how he wants to do it.

[sleevi]

On Tue, Apr 9, 2019 at 7:59 AM Sebastian Nielsen notifications@github.com wrote:

1: My stance on it, is that its up to the server administrator if they want to share keys should be able to do that.

It’s unclear. Are you disagreeing that there are fundamental cryptographic cross-protocol risks introduced by the reuse of keys in unrelated protocols? It is basic cryptographic practice to ensure that unrelated protocols should use unrelated keys. While significant effort has been made to reduce the cross-protocol confusion, the prohibition serves as a critical and essential safety margin.

Could you help explain the concern/motivation more? It’s unclear whether this is motivated by a concern of simply obtaining an additional certificate, or whether there is some other consideration at play.

[sebastiannielsen]

No im not disagreeing with it.

Yes I do understand there need to exist a safety margin, but the final authority of a domain, should be able to decide if that safety margin should be in effect or not.

The advantage of being able to use the same certificate for more tasks, is multi-fold. First, by having lesser amount of keys and certificates in system, the certificates and keys can be secured more, and lesser management overhead. 1: If its the same server serving both normal TLS content and SGX content, theres no security gain in having 2 certificates and 2 keys on the same machine. 2: If you use a HSM or crypto accelerator that only supports one key and/or chain, it would be preferable to be able to use that. 3: If the CA charges for certificates, having 2 certificates would of course incur additional costs than 1 certificate.

[sleevi]

On Tue, Apr 9, 2019 at 8:31 AM Sebastian Nielsen notifications@github.com wrote:

No im not disagreeing with it.

Yes I do understand there need to exist a safety margin, but the final authority of a domain, should be able to decide if that safety margin should be in effect or not.

Ultimately, the User Agent is responsible for ensuring the user’s security needs are met, above and beyond what domain holders may wish.

This is why User Agents disable SHA-1 or 1024-but RSA keys, or denote certain powerful features to HTTPS. Yes, a domain operator may be interested in setting their security policies lower, but such desire is counter to the security of users needs.

The advantage of being able to use the same certificate for more tasks, is

multi-fold. First, by having lesser amount of keys and certificates in system, the certificates and keys can be secured more, and lesser management overhead.

This does not seem to logically follow. Given that TLS keys are online, while SXG keys are inherently offline, coupling these two functionally reduces the security of the system and users. Every operation involving such shared keys needs to fully consider both protocols, causing more management overhead.

1: If its the same server serving both normal TLS content and SGX content,

theres no security gain in having 2 certificates and 2 keys on the same machine.

This does not logically follow. With SXG, there is no technical need to install keys on the server. Such a thing would seem counter to best practice.

2: If you use a HSM or crypto accelerator that only supports one key and/or

chain, it would be preferable to be able to use that.

Are you aware of any such products? I have yet to encounter one in my career. In general, HSMs are unable to be deployed for TLS at scale, as modern HSMs and “accelerators” (more of a 90s concept) are unable to perform signatures at the pace of modern large scale deployments. On the other hand, SXGs, and their infrequent signatures, absolutely make these technologies viable again for key protection.

3: If the CA charges for certificates, having 2 certificates would of

course incur additional costs than 1 certificate.

I agree that this is a possibility, but it’s not a technological concern. You can choose CAs, for example, that do not charge for certificates at all, or which charge for validations (which both types of certificates can be issued from a single validation). I totally understand and appreciate the concern here - it’s one introduced whenever anything involving certificates is used - but it does not seem necessary to weaken the cryptographic security in order to address. As demonstrated by current and past CA practices, it also seems to be a practice going out of vogue and more hypothetical?

[sebastiannielsen]

1: I agree about the user agent responsible for end user security, and of course it should restrict certain sensitive features to HTTPS.

But in my opinion, the user agent should not put any restrictions on how the server operator may manage their keys and certificates.

[sleevi]

Do we agree that User Agents already place restrictions on how servers manage their keys (e.g. no 1024-bit) and certificates (e.g. expiration policies, weak signatures)? This does not seem to be a change from the status quo.

We seem to be in agreement that an SXG key is more valuable than a TLS key, due to the ability to mount off-path attacks, so it seems there’s clear justification for putting stronger protection requirements on the SXG key. Those requirements are incompatible with TLS, due to TLS requiring online signing.

Assuming we had a technology which allowed a TLS key to be protected to that same level, such as TLS Delegated Credentials proposes (moving the TLS key offline, in favor of ephemeral assertions), then we also seem to be in agreement that there are still fundamental cryptographic reasons to keep key material separate, to defend against cross-protocol attacks.

I don’t mean to dismiss the feedback, but to walk through how the conclusion was reached - which is that it is essential to the security of end users to ensure a TLS server does not reuse an SXG key. While of course such thing is possible by virtue of a CA issuing two certificates for the same key - such a thing should be seen as a security vulnerability, rather than an expected or accepted practice.

[grittygrease]

I don't agree with the assertion that SXG key is strictly more valuable than a TLS key. An attacker that has possession of a TLS key can perform a MITM attack that steals authentication credentials such as cookies, while an attacker in possession of an SXG certificate can only display arbitrary content as the site owner. In some respects, being able to MITM TLS is a more powerful attack.

With that said, not all clients will implement the MUST NOT. This means that there will be a risk that a compromised SXG certificate can be used to MiTM a TLS connection, just not with Chrome. This puts all users of non-conforming browsers at risk.

What is the point of adding this restriction to not allow TLS with the certificate if the extension is not marked critical? It seems to only protect users of conforming browsers while exposing other users to risk. I understand this has been discussed before (https://github.com/WICG/webpackage/issues/238) but it's not clear the conclusions still hold given that a large percentage of user agents that will not be updated to respect this MUST NOT.

In my opinion, this spec should be non-discriminatory and pick a side. Either SXG certificates should be permitted for use in TLS (maintaining the legacy browser behavior), or certificates should be forbidden to be used for TLS and the extension made critical (to protect the users of legacy browsers).

I'm not swayed by the argument that just because some TLS clients use system PKI validators, that this extension should not be made critical. This is a big change to how the PKI is used and clients who want to support it should make correct validation of the certificate a requirement on platforms they run on. Fudging this with a MUST NOT that will only be used for a subset of clients does not improve the situation.

[davidben]

I don't agree with the assertion that SXG key is strictly more valuable than a TLS key. An attacker that has possession of a TLS key can perform a MITM attack that steals authentication credentials such as cookies, while an attacker in possession of an SXG certificate can only display arbitrary content as the site owner. In some respects, being able to MITM TLS is a more powerful attack.

In a web context, an attacker that can display arbitrary content as the site owner can, in turn, run arbitrary JS as the site owner. That allows them to read credentials for that origin, make credentialed requests as that origin, etc.

[jyasskin]

I've been convinced that neither SXG keys nor TLS keys are strictly more powerful than the other, especially since we're talking in #376 and elsewhere of checking SXG contents against a live TLS connection. The difference in power is complicated and probably not too helpful in deciding this particular issue.

I think @sebastiannielsen is right that many servers will put their SXG key on the same internet-facing server as their TLS key, unless we require it to be on a secure element, which I suspect will limit adoption too much.

However, I'm also sympathetic to @sleevi's point that we want a buffer around the possibility of cross-protocol attacks. Especially since the SXG signed-message format is still evolving, I don't want to accidentally enable cross-protocol attacks in a future update, after we've allowed the keys to be used for TLS servers. On the other hand, it seems like it'll be easy to enable TLS use later, using the mechanism @sebastiannielsen suggests, once the format has settled down.

On the third hand, @grittygrease is right that not all clients will implement the MUST NOT, and so we have to be careful about cross-protocol attacks during the SXG evolution anyway, so maybe we should make that explicit by allowing use for TLS.

[sebastiannielsen]

@sleevi Also the reason to drop SHA-1 certificates, is not about key management or security of a single website. Its more about the security of ALL websites. Because, a malicious actor could, with a valid SHA-1 certificate, be able to generate another such, with hash collision, to be valid to for example github.com or google.com

So even if one single website would be allowed to use SHA-1 certificates, it would hurt the security of all websites. In the same way, most (if not all) CA's require sub-CA keys to be on a secure element, just because if one such leaks, ALL websites will be in danger, even a website that doesn't use that sub-CA.

That doesn't stand for TLS/SGX certificates. Even if I would publish the private key for my certificate to my website, it wouldn't hurt the security for any other website than mine.

Thus any cross-protocol attacks, if found, would only affect those websites that do use the same certificate for TLS and SGX.

Thus I stand my position on that the website administrator should be in full control of if a certificate should be allowed for either TLS, SGX or both. Also there should possible be some mechanism preventing CA's from charging extra for SGX-enabled certificates, maybe in some baseline requirements or something. Currently its one certificate each - and you also have to submit 2 full validations with papers and pay everything for most CA's (it was just StartSSL that did have the concept with a "validation" being valid for multiple certificates) - now Im talking about organizational certificates and not domain-only certificates.

If you had both certificates combined into one, you would only need to submit everything once - and only pay once. Some CA's might then charge extra for a combined cert because they know you save on not having to get 2 certificates, and there should be some mechanism preventing this, possible in baseline requirements.

[jyasskin]

Let's avoid the question of how much CAs charge for certificates here.

[sleevi]

On Fri, May 3, 2019 at 1:38 AM Sebastian Nielsen notifications@github.com wrote:

@sleevi https://github.com/sleevi Also the reason to drop SHA-1 certificates, is not about key management or security of a single website. Its more about the security of ALL websites. Because, a malicious actor could, with a valid SHA-1 certificate, be able to generate another such, with hash collision, to be valid to for example github.com or google.com

1024-bit certificates, then.

http://google.com

Thus I stand my position on that the website administrator should be in full control of if a certificate should be allowed for either TLS, SGX or both.

User agents priorities dictate that the user comes first. Poor security practices by a website jeopardize user security. This is similar to UAs having policies about which ciphersuites in TLS they support, which CAs they support, or even requiring TLS at all for certain features.

Arguments in favor of web developers need to consider risks to users, both from that of a single site and from an ecosystem perspective if all sites adopted that.

The key management issues highlight a significant change, just as the work proposed for Secondary Certificates would significantly alter the TLS key risks.

[jyasskin]

@sleevi I'm mostly convinced by @grittygrease's argument that since we don't want to make the extension critical (doing so would prevent Chrome from adopting), any protocol confusion attacks put the users of non-adopting browsers at risk, and so we should allow use of SXG certs for TLS in order to make sure we pay attention to preventing protocol confusion attacks. How are you feeling about that argument?

[sleevi]

I don’t find it a particularly compelling argument for removing any protections. I also don’t deny the current design is significantly weaker than desirable, from a security POV.

During the design, we discussed other ways we could mitigate the risk. The current design was chosen to favor the ease of adoption for CAs, but since it seems there’s concern that it may not be sufficient, we should revisit those designs.

For example, we discussed previously the use of EKUs, much in the same way Code signing and TLS certificates are distinguished. This requires CAs perform new issuance ceremonies for intermediates, before they can issue SXG certificates, but also allows for reliable and interoperable enforcement between SXG supporting clients and those that don’t.

[grittygrease]

@jyasskin @sleevi Is there a timeline for moving the PKIX components of Chrome from the OS into the browser? Doing so would allow this extension to be marked as critical, which would go a long way towards solving this issue.

[sleevi]

The decision here was not based solely on Chrome. This is an issue virtually every implementation will face.

[grittygrease]

Once the underlying PKIX packages on the OS are updated, this should no longer be an issue, right? Or are you indicating that there is a broader pattern that makes extensions that introduce new security risks difficult to make critical?

On Wed, May 29, 2019 at 9:35 AM sleevi notifications@github.com wrote:

The decision here was not based solely on Chrome. This is an issue virtually every implementation will face.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/WICG/webpackage/issues/420?email_source=notifications&email_token=ABHDHZ3LLZNNARYQYSKJUIDPX2WFVA5CNFSM4HEOU6G2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWP5FLQ#issuecomment-497013422, or mute the thread https://github.com/notifications/unsubscribe-auth/ABHDHZ25U3OO7EPVXJMARYTPX2WFVANCNFSM4HEOU6GQ .

[sleevi]

A design which forces the extension critical forces an implementation decision for UAs to either:

• Lock the UAs/consumers to the OS version, and either only update them in sync, or only make functionality available on certain OSes for these externalized reasons. This is often bad for the Web and for users, especially given the update cadence of OS vs browsers.
• Force implementors (which, in the case of SXG, is intended to be more than 'just' browsers) to ship their own PKI library, which is often a net-negative for user security in the aggregate, and a significant implementation cost.

I think the comment in https://github.com/WICG/webpackage/issues/420#issuecomment-488858875 is making an implicit, but unsupported, assumption that an SXG certificate is at greater risk of compromise than a TLS certificate, and that therefore disadvantages legacy clients if that key is compromised because it can be used in MITM. It's unsupported, because SXG-supporting clients would be at just as much (if not greater) risk of malicious SXGs, and thus the assumption that SXG would encourage laxer key hygiene isn't actually explained. It also ignores the other benefits of having the explicit extension and signal, and doesn't explain or justify why using it in TLS is desirable or useful, other than it would avoid having to think about key protection - which is exactly what the extension is trying to force contemplation of (among other things).