Without taking a position on the merits of these specific ideas, I don't see why most of them would require a new version of TLS. Indeed, a number of them (e.g., phasing out algorithms) is something we routinely do without a version number bump.
it's possible that the HKDF one would, but even then I expect we could simply have the definitions of how to use the new hashes state that HKDF would not be used. -Ekr On Wed, Oct 1, 2025 at 11:35 PM John Mattsson <[email protected]> wrote: > >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 <draft-ietf-tls-tls14= > [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] > To unsubscribe send an email to [email protected] > >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
