On Thu, 4 Sept 2025 at 10:40, Yaakov Stein <ystein=40allot....@dmarc.ietf.org> 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: internet-dra...@ietf.org <internet-dra...@ietf.org> > Sent: Wednesday, September 3, 2025 4:06 PM > To: i-d-annou...@ietf.org > Cc: tls@ietf.org > 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 -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > 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 -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
