>Are there any specific issues which cannot be addressed in the framwwork of >TLS 1.3
I think almost everything _can_ be handled with extensions. A new version is justified when changes become too large or too numerous to fit cleanly into the extension model. Another valid reason is to more clearly forbid outdated or insecure options. I don't think draft-zhou-tls-tls14 motivates 1.4. Traffic Flow Security (TFS) is already specified, and the other parts should likely not be done. That said, a TLS 1.4 could make sense sometime in the future if it were used to mandate stronger security properties and eliminate weak options. For example: - Require quantum-resistant cryptography only. - Require ephemeral key exchange in all cases. - Require implementations to perform mAEAD rekeying (currently left optional or often pushed to the application). - Phase out static keys, or at least not violate NIST requirements (SP 800-227). - Require support for strong rekeying. TLS 1.3’s KeyUpdate is much weaker than the mechanisms in IPsec, SSH, and Signal and does not provide protection against key leakage. - Provide identity protection. Today, PSK identities and SNI are still sent in the clear. - Avoid designing around HKDF and HMAC, which are only needed when the hash function has significant vulnerabilities/issues such as length-extension, failure to behave like a random function, lack of variable-length output, etc. - Mandate support for ECH and other extensions. Cheers, John From: Eric Rescorla <[email protected]> Date: Wednesday, 1 October 2025 at 19:59 To: Bocai Zhou <[email protected]> Cc: [email protected] <[email protected]>, <[email protected]> Subject: [TLS] Re: [Pqc] Subject: Request for Technical Review: Internet-Draft draft-zhou-tls-tls14-03 – The Transport Layer Security (TLS) Protocol Version 1.4 + TLS WG Bocai, I agree with Paul Hoffman that the place to send this document would be the TLS WG. With that said I don't believe that this document is necessary. It seems to make three primary technical changes: 1. Specifying a new set of PQ-only key establishment and signature algorithms and new extensions to carry them. 2. Modifying CertificateVerify to support hybrid signatures and Certificate to support two certificates. 3. The addition of the dummy packet for traffic analysis resistance. 4. The requirement for a specific PQ/traditional key establishment combiner form. All of these can be accommodated within the existing framework of TLS 1.3. * For PQ-only key-establishment and signature, the client can simply offer the existing code points with the existing extensions but not offer any non-PQ values. There is no need to define new extensions, and I think the semantics of your extension are worse, not better. * We already have an existing draft for dual certificate chains within TLS 1.3 (https://datatracker.ietf.org/doc/draft-yusef-tls-pqt-dual-certs/). Incidentally, I don't think your design is correct: you write: If a server has negotiated a hybrid signature scheme, its Certificate message MUST contain two certificates: one for a traditional algorithm and one for a PQC algorithm. These certificates MUST be presented in a new certificate_list structure. However, you need to present two *chains* not two certificates. This is the reason for the structure in draft-yusef. * TLS 1.3 already supports empty application date records that just consist of padding, as defined in S 5.4 of RFC 8446. Thus, there is no need for a new record type to send cover traffic. * If we think your combiner form is better, we can just require it in TLS 1.3. On the non-technical side, this document is largely the same as RFC 8446. Here in the IETF, we grant rights to our contributions to the IETF so there's nothing inherently wrong with just doing a -bis document like this, but it's also the case that most of the work in this document is really the work of other people, so it's not great to remove the Contributor list, thus denying them credit. -Ekr On Tue, Sep 30, 2025 at 9:22 PM Bocai Zhou <[email protected]<mailto:[email protected]>> wrote: Dear esteemed PQUIP Working Group experts, I am writing to formally request a technical review of my Internet-Draft, draft-zhou-tls-tls14-03, which proposes The Transport Layer Security (TLS) Protocol Version 1.4. While the community’s current and critical post-quantum efforts are correctly focused on leveraging hybrid extensions within the established framework of TLS 1.3, this draft offers an alternative architectural exploration. I submit that the magnitude of the non-backward-compatible changes required for truly robust, long-term Post-Quantum Cryptography (PQC) integration—particularly concerning fundamental alterations to key derivation and authentication processes—warrants implementation under a new major protocol version number (TLS 1.4). This approach is designed to establish a cleaner, unambiguously secure, and sustainable foundation for PQC-era deployments. Core Technical Design Highlights for TLS 1.4 The central divergence from the TLS 1.3 hybrid model is rooted in a dedicated separation of classical and PQC cryptographic components: * Dedicated PQC Negotiation: TLS 1.4 introduces three new, dedicated extensions: supported_pqc_groups, pqc_key_share, and pqc_signature_algorithms. The existing classical supported_groups extension is deliberately constrained to advertise only classical groups. This cleanly enforces the separation of concerns for negotiation and simplifies the implementation logic required for both hybrid and PQC-only modes. * Key Combination Method: When a hybrid key exchange yields multiple secret inputs (classical and PQC), TLS 1.4 strictly mandates the use of length-prefixed concatenation to derive a single shared secret input before its application to the HKDF-Extract function. This design explicitly prohibits alternative mixing methods, such as XOR, thereby enforcing cryptographic rigidity and soundness within the key schedule. * Mandatory Hybrid Authentication: To effectively mitigate potential downgrade and substitution attacks in the long term, the design requires hybrid authentication to utilize two distinct certificate chains—one classical and one PQC. Crucially, these chains must be cryptographically linked (e.g., through cross-signatures or a Certified Linking X.509 Extension). The CertificateVerify message is accordingly updated to mandate the inclusion and validation of both signatures over the identical transcript hash. Specific Request for Expert Review Given that TLS 1.4 is fundamentally designed as a forward-looking, PQC-native protocol, the collective expertise of the PQUIP Working Group is invaluable to its validation. I respectfully request the working group to focus its review on the following critical areas: 1. The cryptographic soundness of the proposed key combination and derivation method. 2. The security properties and operational feasibility of the mandatory certificate linking mechanisms. 3. The clarity and robustness of the new negotiation rules and extension separation. The current draft is available for your review here: https://datatracker.ietf.org/doc/draft-zhou-tls-tls14/03/ I greatly appreciate your time and consideration of this proposal and look forward to a comprehensive discussion of this design on the mailing list. Best regards, Bocai Zhou Author, draft-zhou-tls-tls14 -- Pqc mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
