I just made the mistake of not sending this to the mailing list. It's my mistake. I sincerely implore Eric Rescola to disregard the email containing the same content as below.
Dear Eric Rescola, Thank you for your careful review and for taking the time to give such thorough, constructive feedback. Your criticisms identified serious, unavoidable problems in my work, and I am deeply ashamed and very grateful. I apologize sincerely to you and to everyone who has contributed to TLS 1.3 for my oversights regarding copyright and contributor attribution — this was a grave failure on my part. I will correct it immediately and offer my heartfelt apologies for any inconvenience or offense caused. Thank you for your patience and candor. About the submission channel You are absolutely right that the TLS WG is the appropriate forum. I initially considered consulting the PQUIP working group first because I doubted my own judgment and wanted to surface major design flaws early to avoid wasting everyone's time. That was an inexperienced choice and cannot replace raising the matter directly in the TLS WG for community discussion. Going forward I will work through the TLS WG and, when needed, consult other relevant working groups transparently, avoiding detours and ensuring proper process. About whether this should be TLS 1.4 Your point that these changes can be implemented within the TLS 1.3 framework is very persuasive and has caused me to rethink my starting assumption. My intention was never to circumvent prior work. I was worried by the scale of the handshake changes and feared that labeling them as an optional 1.3 extension might create semantic clashes with existing hybrid schemes and lead to implementation and interoperability confusion. Your reminder was timely — I realize I should defer to the WG’s judgment rather than make unilateral determinations. >From an engineering perspective I was concerned (for example, possible >ambiguity when supported_groups and supported_pqc_groups coexist) and so I >leaned toward a separate version to make semantics explicit, but that was only >my personal view and must not override community consensus. If the WG and >experienced colleagues judge that folding these changes into TLS 1.3 as an >extension is preferable, I will fully comply and assist with migrating the >work into the existing framework. Thank you again for steering me away from >needlessly proposing a fork. About dual chains and draft-yusef Your correction that I spoke of “two certificates” rather than “two certificate chains” was crucial. Thank you for pointing to draft-yusef-tls-pqt-dual-certs; its structure is indeed more rigorous and better suited for path validation. I will adopt that approach immediately and add proper acknowledgement and citation to that draft and its authors to give them due credit. About cover traffic and record layer You reminded me that RFC 8446 §5.4 already supports empty application data records as padding; I had not checked that thoroughly, and that was my oversight. Thank you for correcting me — I will remove the proposal for a new record type and instead explain how to use existing mechanisms for traffic hiding, unless there is a clear, irreplaceable reason to add a record type. About combiner form and contributor attribution If the community or WG finds merit in the combiner form I proposed, I am willing to provide further analysis and experiments to support discussion; I will not use such a proposal as a reason to dismiss existing work. More importantly, your critique on contributor attribution touches on my professional integrity — I will restore and retain all rightful contributor acknowledgements, strictly follow IETF copyright and contribution policies, and clearly cite and thank contributors in the draft. Once again, please accept my sincere gratitude. Your corrections not only improve the draft but also remind me of the humility and responsibility required of contributors. If you or other reviewers feel the draft should be withdrawn, I will do so without hesitation. If the community finds room for improvement, I will revise the document point by point according to your and others’ suggestions and submit a new version, with explicit acknowledgements at the front. Thank you for your patience and help; I deeply value and respect your advice. With respect and gratitude, Bocai Zhou 使用 Proton Mail 安全邮箱发送。 2025年10月2日 星期四 上午 1:58，Eric Rescorla <[email protected]> 来信： > + 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]> 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]
publickey - [email protected] - 0xD2280D56.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
