diff --git a/_posts/2024-05-23-advancing-our-amazing-bet-on-asymmetric.md b/_posts/2024-05-23-advancing-our-amazing-bet-on-asymmetric.md index f175590..e3fa6a0 100644 --- a/_posts/2024-05-23-advancing-our-amazing-bet-on-asymmetric.md +++ b/_posts/2024-05-23-advancing-our-amazing-bet-on-asymmetric.md @@ -4,9 +4,10 @@ author: David Adrian, Bob Beck, David Benjamin and Devon O'Brien date: 2024-05-23 source-url: https://blog.chromium.org/2024/05/advancing-our-amazing-bet-on-asymmetric.html source-blog: Chromium Blog +excerpt: Google and many other organizations, such as NIST, IETF, and NSA, believe that migrating to post-quantum cryptography is important due to the large risk posed by a cryptographically-relevant quantum computer (CRQC). In August, we posted about how Chrome Security is working to protect users from the risk of future quantum computers by leveraging a new form of hybrid post-quantum cryptographic key exchange, Kyber (ML-KEM). We’re happy to announce that we have enabled the latest Kyber draft specification by default for TLS 1.3 and QUIC on all desktop Chrome platforms as of Chrome 124.2 This rollout revealed a number of previously-existing bugs in several TLS middlebox products. To assist with the deployment of fixes, Chrome is offering a temporary enterprise policy to opt-out. --- -Google and many other organizations, such as [NIST](https://csrc.nist.gov/projects/post-quantum-cryptography), [IETF](https://datatracker.ietf.org/group/tls/about/), and [NSA](https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3148990/nsa-releases-future-quantum-resistant-qr-algorithm-requirements-for-national-se/), believe that migrating to post-quantum cryptography is important due to the large risk posed by a [cryptographically-relevant quantum computer](https://media.defense.gov/2021/Aug/04/2002821837/-1/-1/1/Quantum_FAQs_20210804.PDF) (CRQC). In [August](https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html), we posted about how Chrome Security is working to protect users from the risk of future quantum computers by leveraging a new form of [hybrid post-quantum cryptographic key ](https://datatracker.ietf.org/doc/draft-tls-westerbaan-xyber768d00/)exchange, Kyber (ML-KEM)^[1](https://blog.chromium.org/2024/05/advancing-our-amazing-bet-on-asymmetric.html#fn1)^. We're happy to announce that we have enabled the latest Kyber draft specification by default for TLS 1.3 and QUIC on all desktop Chrome platforms as of Chrome 124.^[2](https://blog.chromium.org/2024/05/advancing-our-amazing-bet-on-asymmetric.html#fn2)^ This rollout revealed a number of previously-existing bugs in several TLS middlebox products. To assist with the deployment of fixes, Chrome is offering a temporary [enterprise policy to opt-out](https://chromeenterprise.google/policies/#PostQuantumKeyAgreementEnabled). +Google and many other organizations, such as [NIST](https://csrc.nist.gov/projects/post-quantum-cryptography), [IETF](https://datatracker.ietf.org/group/tls/about/), and [NSA](https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3148990/nsa-releases-future-quantum-resistant-qr-algorithm-requirements-for-national-se/), believe that migrating to post-quantum cryptography is important due to the large risk posed by a [cryptographically-relevant quantum computer](https://media.defense.gov/2021/Aug/04/2002821837/-1/-1/1/Quantum_FAQs_20210804.PDF) (CRQC). In [August](https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html), we posted about how Chrome Security is working to protect users from the risk of future quantum computers by leveraging a new form of [hybrid post-quantum cryptographic key ](https://datatracker.ietf.org/doc/draft-tls-westerbaan-xyber768d00/)exchange, Kyber (ML-KEM)[^1]. We're happy to announce that we have enabled the latest Kyber draft specification by default for TLS 1.3 and QUIC on all desktop Chrome platforms as of Chrome 124.[^2] This rollout revealed a number of previously-existing bugs in several TLS middlebox products. To assist with the deployment of fixes, Chrome is offering a temporary [enterprise policy to opt-out](https://chromeenterprise.google/policies/#PostQuantumKeyAgreementEnabled). Launching opportunistic quantum-resistant key exchange is part of [Google's broader strategy](https://bughunters.google.com/blog/5108747984306176/google-s-threat-model-for-post-quantum-cryptography) to prioritize deploying post-quantum cryptography in systems *today* that are at risk if an adversary has access to a quantum computer *in the future*. We believe that it's important to inform standards with real-world experience, by implementing drafts and iterating based on feedback from implementers and early adopters. This iterative approach was a key part of developing QUIC and TLS 1.3. It's part of why we're launching this draft version of Kyber, and it informs our future plans for post-quantum cryptography. @@ -38,9 +39,9 @@ This conflict, in turn, limits new clients making PKI changes to improve user se At first glance, TLS may appear to have trust anchor agility by way of *cross-signatures* and *signature algorithm negotiation*. However, neither of these mechanisms provide true trust anchor agility, nor were they intended to. -A cross-signature is when a CA creates two different certificates for a single subject and public key pair, but with different issuers and signatures. The first certificate is issued and signed as usual, by the CA itself. The second is issued and signed by a different trust hierarchy, often by a different organization. For example, the original Let's Encrypt intermediate certificate [existed in two forms](https://letsencrypt.org/2023/07/10/cross-sign-expiration.html)^[3](https://blog.chromium.org/2024/05/advancing-our-amazing-bet-on-asymmetric.html#fn3)^. The "regular" intermediate was signed by the Let's Encrypt root, whereas the "cross-signed" intermediate was signed by IdenTrust. This approach of cross-signing a new PKI hierarchy with an older, more broadly available PKI hierarchy allows a new CA to bootstrap its trust on old devices, so long as the older devices support the signing algorithm. Cross-signatures, however, rely on significant cooperation among often competing CAs, and may not be suitable for when different clients have different needs. This limits when site operators can use cross-signs. Additionally, devices that do not support a new algorithm will still need to be updated to be able to use the new signing algorithm in the newer certificate, regardless of whether or not it is cross-signed. +A cross-signature is when a CA creates two different certificates for a single subject and public key pair, but with different issuers and signatures. The first certificate is issued and signed as usual, by the CA itself. The second is issued and signed by a different trust hierarchy, often by a different organization. For example, the original Let's Encrypt intermediate certificate [existed in two forms](https://letsencrypt.org/2023/07/10/cross-sign-expiration.html)[^3]. The "regular" intermediate was signed by the Let's Encrypt root, whereas the "cross-signed" intermediate was signed by IdenTrust. This approach of cross-signing a new PKI hierarchy with an older, more broadly available PKI hierarchy allows a new CA to bootstrap its trust on old devices, so long as the older devices support the signing algorithm. Cross-signatures, however, rely on significant cooperation among often competing CAs, and may not be suitable for when different clients have different needs. This limits when site operators can use cross-signs. Additionally, devices that do not support a new algorithm will still need to be updated to be able to use the new signing algorithm in the newer certificate, regardless of whether or not it is cross-signed. -Signature algorithm negotiation allows TLS peers to agree on the algorithm to be used for the handshake signature. This algorithm needs to correspond with the key type used in the certificate. Endpoints can infer that if the peer supports an algorithm such as ECDSA for the handshake signature, it must also support ECDSA certificates. This value can be used to multiplex between an RSA-based chain and a smaller ECDSA-based chain. For example, Google's RSA-based large compatibility chain is four certificates and ~4.1KB, whereas the shortest ECDSA-based chain is three certificates and only ~1.7KB^[4](https://blog.chromium.org/2024/05/advancing-our-amazing-bet-on-asymmetric.html#fn4)^. +Signature algorithm negotiation allows TLS peers to agree on the algorithm to be used for the handshake signature. This algorithm needs to correspond with the key type used in the certificate. Endpoints can infer that if the peer supports an algorithm such as ECDSA for the handshake signature, it must also support ECDSA certificates. This value can be used to multiplex between an RSA-based chain and a smaller ECDSA-based chain. For example, Google's RSA-based large compatibility chain is four certificates and ~4.1KB, whereas the shortest ECDSA-based chain is three certificates and only ~1.7KB[^4]. Signature algorithm negotiation does not provide trust anchor agility. While the signature algorithm information implies algorithm support, it provides no information about what trust anchors a client actually trusts. A client can support ECDSA, but not have the latest ECDSA root certificate from a specific CA. Due to the wide variety of trust stores in use, many organizations may still often need to be conservative in when they serve ECDSA certificates and may need to provide a longer, cross-signed chain for maximum compatibility. @@ -57,12 +58,10 @@ Ultimately, we think that any approach to post-quantum authentication has the sa Notes ----- -* * * * * +[^1]: The draft is X25519Kyber768, which is a combination of the pre-quantum algorithm X25519, and the post-quantum algorithm Kyber 768. Kyber is being renamed to ML-KEM, however for the purposes of this post, we will use "Kyber" to refer to the hybrid algorithm defined for TLS. -1. The draft is X25519Kyber768, which is a combination of the pre-quantum algorithm X25519, and the post-quantum algorithm Kyber 768. Kyber is being renamed to ML-KEM, however for the purposes of this post, we will use "Kyber" to refer to the hybrid algorithm defined for TLS. [↩](https://blog.chromium.org/2024/05/advancing-our-amazing-bet-on-asymmetric.html#fnref1) +[^2]: As the standards from NIST and IETF are not yet complete, this will be later removed and replaced with the final versions. At this stage of standardization, we expect only early adopters to use the primitives -2. As the standards from NIST and IETF are not yet complete, this will be later removed and replaced with the final versions. At this stage of standardization, we expect only early adopters to use the primitives. [↩](https://blog.chromium.org/2024/05/advancing-our-amazing-bet-on-asymmetric.html#fnref2) +[^3]: It actually exists in considerably more than two forms, but from an organizational perspective, there are versions that signed by other Let's Encrypt certificates, and a version that is signed by IdenTrust, which is a completely separate certification authority from Let's Encrypt -3. It actually exists in considerably more than two forms, but from an organizational perspective, there are versions that signed by other Let's Encrypt certificates, and a version that is signed by IdenTrust, which is a completely separate certification authority from Let's Encrypt. [↩](https://blog.chromium.org/2024/05/advancing-our-amazing-bet-on-asymmetric.html#fnref3) - -4. The chain length includes the root certificate and leaf certificate. The byte numbers are what is transmitted over the wire, and so they include the leaf certificate but not the root certificate. [↩](https://blog.chromium.org/2024/05/advancing-our-amazing-bet-on-asymmetric.html#fnref4) \ No newline at end of file +[^4]: The chain length includes the root certificate and leaf certificate. The byte numbers are what is transmitted over the wire, and so they include the leaf certificate but not the root certificate \ No newline at end of file