+1 to ekr’s comments spt
> On Oct 1, 2025, at 13:57, Eric Rescorla <[email protected]> wrote: > > + 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: >> >> The cryptographic soundness of the proposed key combination and derivation >> method. >> >> The security properties and operational feasibility of the mandatory >> certificate linking mechanisms. >> >> 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]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
