[TLS] Re: I-D Action: draft-ietf-tls-hybrid-design-15.txt

[Loganaden Velvindron <[e-mail]>]

On Thu, 4 Sept 2025 at 10:40, Yaakov Stein
<ystein=[e-mail]> wrote:
>
> Just a few notes on the latest version of the hybrid-design draft.
>
> Section 1.2 introduces a very general definition of hybrid key exchange,
> with traditional+PQC as merely one example.
> This begs the question of what other possibilities there may be
> (and of what, precisely, is meant by "different cryptographic assumptions" -
> would RSA+ECC or ML-KEM+HQC be considered hybrids under this definition?).
> I suggest giving an additional example, such as QKD+PQC (which is actually used in some circles).
>
> I don't understand the rationale behind the terminology "next generation" in this document.
> Next generation crypto need not be PQ.
> If I come up with a completely new 1-way function, which has advantages over existing schemes
> but is still a special case of the hidden subgroup problem,
> then this is NG but not PQ.
>
> Section 1.3 uses the term "retroactive decryption" which is usually (and in draft-ietf-pquip-pqc-engineers) called HNDL.
> The term is fine, but the more usual one should at least be mentioned.
>
> Section 1.5 introduces the key-share size issue as a sub-issue of latency,
> but it could alternatively be considered a performance issue.
> Or even better is an issue unto itself.
> Actually, latency is determined by the computational complexity and the key sizes
> and is thus not a separate issue at all.
>
> Section 4 states "all defined parameter sets for ML-KEM [NIST-FIPS-203] have public
>                               keys and ciphertexts that fall within the TLS constraints."
> It is worthwhile mentioning that ML-KEM and its hybrids
> can expand CHs that were previously a single packet into multiple packets,
> and hence disrupt the functionality of middleboxes that make assumptions about CHs.
>

I made a PR about this some time ago, but I missed the deadline.

Should I revive the PR ?


> Y(J)S
>
> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Wednesday, September 3, 2025 4:06 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [TLS] I-D Action: draft-ietf-tls-hybrid-design-15.txt
>
> External Email: Be cautious do not click links or open attachments unless you recognize the sender and know the content is safe
>
> Internet-Draft draft-ietf-tls-hybrid-design-15.txt is now available. It is a work item of the Transport Layer Security (TLS) WG of the IETF.
>
>    Title:   Hybrid key exchange in TLS 1.3
>    Authors: Douglas Stebila
>             Scott Fluhrer
>             Shay Gueron
>    Name:    draft-ietf-tls-hybrid-design-15.txt
>    Pages:   23
>    Dates:   2025-09-03
>
> Abstract:
>
>    Hybrid key exchange refers to using multiple key exchange algorithms
>    simultaneously and combining the result with the goal of providing
>    security even if a way is found to defeat the encryption for all but
>    one of the component algorithms.  It is motivated by transition to
>    post-quantum cryptography.  This document provides a construction for
>    hybrid key exchange in the Transport Layer Security (TLS) protocol
>    version 1.3.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-15.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-hybrid-design-15
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> This message is intended only for the designated recipient(s). It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distribute this message. If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. Thank you.
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]