[TLS] Re: [Pqc] Subject: Request for Technical Review: Internet-Draft draft-zhou-tls-tls14-03 – The Transport Layer Security (TLS) Protocol Version 1.4

[Eric Rescorla <[e-mail]>]

+ 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=
[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>