Contact emailsdadr...@google.com Explainer https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html
Specification https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html Summary Protect current Chrome TLS traffic against future quantum cryptanalysis by deploying the Kyber768 quantum-resistant key agreement algorithm. This is a hybrid X25519 + Kyber768 key agreement based on an IETF standard. This specification and launch is outside the scope of W3C. This key agreement will be launched as a TLS cipher, and should be transparent to users. Blink componentInternals>Network>SSL <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ESSL> Motivation In order to protect today’s network traffic against future quantum cryptanalytic attacks, we need to begin migrating network security protocols, like TLS, to use quantum-resistant cryptography. TLS will need to update to quantum-resistant cryptography in three separate areas: - Establishing, or agreeing upon a symmetric session key - Authenticating the server’s identity (e.g. X.509 certificate validation) - Authenticating the connection was established by the holder of the server’s private key This feature makes incremental progress on “External Encryption in Transit” by migrating TLS key agreement to a Kyber768 key encapsulation mechanism (ISE on Kyber and PQC strategy). Migrating TLS key agreement to quantum-resistant cryptography provides two important properties: - Protecting future network traffic against real-time interception and decryption - Protecting past and current network traffic against the store-and-decrypt attacks While the capability to break currently-deployed cryptography with quantum cryptanalytic attacks has not yet been publicly demonstrated, it is widely accepted that the “store” component of store-and-decrypt attacks are already underway and must be defended against. Past cryptographic algorithm rollouts have demonstrated that these migrations can take a significant amount of time to deploy, so its important to start before quantum computers exist Initial public proposalNone Search tagstls <https://chromestatus.com/features#tags:tls>, kem <https://chromestatus.com/features#tags:kem>, kyber <https://chromestatus.com/features#tags:kyber>, postquantum <https://chromestatus.com/features#tags:postquantum> TAG review TAG review statusPending Risks Interoperability and Compatibility Post-quantum secure ciphers are larger than classical ciphers. This may cause compatibility issues with middleboxes. *Gecko*: No signal *WebKit*: No signal *Web developers*: No signals *Other signals*: WebView application risks Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? Debuggability Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ?No Flag name on chrome://flagsenable-tls13-kyber Finch feature namePostQuantumKyber Requires code in //chrome?False Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1442377 Launch bughttps://launch.corp.google.com/launch/4252981 Estimated milestones DevTrial on desktop 115 DevTrial on Android 115 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5257822742249472 Links to previous Intent discussions This intent message was generated by Chrome Platform Status <https://chromestatus.com/>. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42%2BgKeCTA6vWwzrE%3DDVR%3DTmQaCyDFQxqnXkOy9GcVyGtnA%40mail.gmail.com.
