add PQC blog post

_posts/2024-05-23-advancing-our-amazing-bet-on-asymmetric.md

@@ -0,0 +1,68 @@
+---
+title: Advancing Our Amazing Bet on Asymmetric Cryptography
+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
+---
+
+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).
+
+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.
+
+Chrome's post-quantum strategy prioritizes quantum-resistant key exchange in HTTPS, and increased [agility](https://www.chromium.org/Home/chromium-security/root-ca-policy/moving-forward-together/) in certificates from the Web PKI. While PKI agility may appear somewhat unrelated, its absence has contributed to significant delays in past cryptographic transitions and will continue to do so until we find a viable solution in this space. A more agile Web PKI is required to enable a secure and reliable transition to post-quantum cryptography on the web.
+
+To understand this, let's take a look at HTTPS and the current state of post-quantum cryptography. In the context of HTTPS, cryptography is primarily used in three different ways:
+
+-   **Symmetric Encryption/Decryption.** HTTP is transmitted as data inside a TLS connection using an authenticated cipher (AEAD) such as AES-GCM. These algorithms are [broadly considered safe](https://words.filippo.io/dispatches/post-quantum-age/) against quantum cryptanalysis and can remain in place.
+-   **Key Exchange.** Symmetric cryptography requires a secret key. Key exchange is a form of asymmetric cryptography in which two parties can mutually generate a shared secret key over a public channel. This secret key can then be used for symmetric encryption and decryption. All current forms of asymmetric key exchange standardized for use in TLS are vulnerable to quantum cryptanalysis.
+-   **Authentication**. In HTTPS, authentication is achieved primarily through the use of digital signatures, which are used to convey server identity, handshake authentication, and transparency for certificate issuance. All of the digital signature and public key algorithms standardized for authentication in TLS are vulnerable to quantum cryptanalysis.
+
+This results in two separate quantum threats to HTTPS.
+
+The first is the threat to traffic being generated *today*. An adversary could store encrypted traffic now, wait for a CRQC to be practical, and then use it to decrypt the traffic after the fact. This is commonly known as a [store-now-decrypt-later](https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later) attack. This threat is relatively urgent, since it doesn't matter when a CRQC is practical---the threat comes from storing encrypted data *now*. Defending against this attack requires the key exchange to be quantum resistant. Launching Kyber in Chrome enables servers to mitigate store-now-decrypt-later attacks.
+
+The second threat is that *future* traffic is vulnerable to impersonation by a quantum computer. Once a CRQC actually exists, it could be used to break the asymmetric cryptography used for authentication in HTTPS. To defend against impersonation from a CRQC, we need to migrate all of the asymmetric cryptography used for authentication to post-quantum variants. However, breaking authentication only affects traffic generated **after** the availability of CRQCs. This is because breaking authentication on a recorded transcript doesn't help the attacker impersonate either party---the conversation has already finished.
+
+In other words, there's no store-now-decrypt-later equivalent for authentication, and so while migrating key exchange and authentication to post-quantum variants are both *important*, migrating authentication is less *urgent* than key exchange. This is good, because there are a [variety of challenges](https://dadrian.io/blog/posts/pqc-signatures-2024/) for migrating to post-quantum authentication. Specifically, size.
+
+Post-quantum cryptography is big compared to the pre-quantum cryptographic algorithms used in HTTPS. A Kyber key exchange is ~1KB transmitted per peer, whereas an X25519 key exchange is only 32 bytes per peer, an over 30x increase. The actual key exchange operation in Kyber is quite fast. Transmitting Kyber keys is quite slow. The extra size from Kyber causes the TLS ClientHello to be split into two packets, resulting in a 4% median latency increase to all TLS handshakes in Chrome on desktop. On desktop platforms, this, with HTTP/2 and HTTP/3 connection reuse, is not large enough to be noticeable in [Core Web Vitals](https://web.dev/articles/vitals). Unfortunately, it is noticeable on Android, where Internet connections are often lower bandwidth and higher latency, and so we have not yet launched on Android.
+
+The size issues are even worse for authentication. ML-DSA (Dilithium) keys and signatures are ~40X the size of ECDSA keys and signatures. A typical TLS connection today uses two public keys and five signatures to fulfill all of the authentication requirements. A naive swap to ML-DSA would add ~14KB to the TLS handshake. [Cloudflare anticipates](https://blog.cloudflare.com/pq-2024) it would increase latency by 20-40%, and we've seen that a single kilobyte was already impactful. Instead, we need alternate approaches to authentication in HTTPS that provide the desired properties and transmit fewer signatures and public keys.
+
+We think the important next step for quantum-resistant authentication in HTTPS is to focus on enabling *trust anchor agility*. Historically, the public Web PKI could not deploy new algorithms quickly. This is because most site operators typically provision a single certificate for all supported clients and browsers. This certificate must both be issued from a trust hierarchy that is trusted by every browser or client the site operator supports, and the certificate must be compatible with each of these clients.
+
+The single certificate model makes it difficult for the Web PKI to evolve. As security requirements change, site operators may find that there is no longer an intersection between certificates trusted by deployed clients, certificates trusted by new clients, algorithms supported by deployed clients, and algorithms supported by new clients (all crossed with every separate browser and root store). These clients may range from different browsers, older versions of those browsers not receiving updates, all the way to applications on smart TVs or payment terminals. As requirements diverge, site operators have to choose between security for new clients, and compatibility with older clients.
+
+This conflict, in turn, limits new clients making PKI changes to improve user security, such as transitioning to post-quantum. Under a single-certificate deployment model, the newest clients cannot diverge too far from the oldest clients, or server operators will be left with no way to maintain compatibility. We propose to solve this by moving to a *multi-certificate deployment model*, where servers may be provisioned with multiple certificates, and automatically send the correct one to each client. This enables trust anchor agility, and allows clients to evolve at different rates. Clients who are up to date and reliably receiving updates could access the authentication mechanisms best suited for the Internet as it evolves without being hamstrung by old clients no longer receiving updates. Certification authorities and trust stores could introduce new post-quantum trust anchors without needing to wait for the slowest actor to add support. This would drastically simplify the post-quantum transition since it also enables the seamless addition and removal of hierarchies using experimental post-quantum authentication methods.
+
+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.
+
+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 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.
+
+Neither cross-signatures nor signature algorithm negotiation are solutions to migrating to post-quantum cryptography for authentication. Cross-signatures do not help with new algorithms, and signature algorithm negotiation is solely about negotiating algorithms, not providing information about trust anchors. We expect a gradual transition to post-quantum cryptography. Inferring information about the contents of the trust store from the result of signature algorithm negotiation risks ossifying to a specific version of a specific trust store, rather than purely being used for algorithm negotiation.
+
+Instead, to introduce agility to TLS we need an explicit mechanism for *trust anchor negotiation*, to allow the client and server to efficiently determine which certificate to use. At the November 2023 IETF meeting in Prague, Chrome proposed "[Trust Expressions](https://github.com/davidben/tls-trust-expressions)" as a mechanism for trust anchor negotiation in TLS. Chrome is currently seeking community input on Trust Expressions via the IETF process. We think the goal of being able to cleanly deploy multiple certificates to handle a range of clients is much more important than the specific mechanisms of the proposal.
+
+From there, we can explore more efficient ways to authenticate servers, such as [Merkle Tree Certificates](https://github.com/davidben/merkle-tree-certs). We view introducing some mechanism for trust anchor agility as a necessity for efficient post-quantum authentication. Experimentation will be extremely important as proposals are developed. Agility also enables using different solutions in different contexts, rather than sending extra data for the lowest-common denominator--- solutions like Merkle Tree Certificates and [intermediate elision](https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-02.html#name-intermediate-elision) require up-to-date clients.
+
+Given these constraints, priorities, and [risks](https://dadrian.io/blog/posts/pqc-not-plaintext/), we think agility is more important than defining exactly what a post-quantum PKI will look like at this time. We recommend against *immediately* standardizing ML-DSA in X.509 for use in the *public* Web PKI via the [CA/Browser Forum](https://cabforum.org/). We expect that ML-DSA, once NIST completes standardization, will play a part in a post-quantum Web PKI, but we're focusing on agility first. This does not preclude introducing ML-DSA in X.509 as an option for private PKIs, which may be operating on more strict post-quantum timelines and have fewer constraints around certificate size, handshake latency, issuance transparency, and unmanaged endpoints.
+
+Ultimately, we think that any approach to post-quantum authentication has the same first requirement---a migration mechanism for clients to opt-in to post-quantum secure authentication mechanisms when servers support it. Post-quantum authentication presents significant challenges to the Web ecosystem, but we believe trust anchor agility will enable us to overcome them and lead to a more secure, robust, and performant post-quantum web.
+
+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. [↩](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. [↩](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. [↩](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)