[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM KeyAgreement for TLSv1.3
Alicja Kario writes: > NIST has selected HQC for standardisation this week... No idea about > its patent situation Interesting question. My tracking page lists HQC as being claimed by GAM. People have mostly heard about GAM as a lattice patent, but the patent is actually broader and originates in code-based cryptography. As confirmation, https://web.archive.org/web/20250314182134/https://csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/round-4/final-ip-statements/HQC-Statements-Round4.pdf claims applicability of U.S. patent 9094189 and French patent 10/51190. However, that document also has a FRAND-RF commitment triggered by NIST standardization. Of course FRAND-RF can have poison pills, but https://web.archive.org/web/20221130033932/https://csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/selected-algos-2022/nist-pqc-license-summary-and-excerpts.pdf doesn't report any poison pills, and at a cursory glance it seems to exempt not just Kyber but also HQC from the GAM patent. Maybe I'm missing something---NIST's latest report mentions just the future-FRAND-RF commitment without mentioning the existing license---but maybe the NIST patent negotiators back in 2022 did something right. On the other hand, this patent minefield is bigger than the GAM patent. The same license has different terms regarding patent 9246675, clearly allowing _only_ unmodified ML-KEM. As far as I can tell, even another version of Kyber (the 2017 version, the 2019 version, the 2020 version, or a future patched version) wouldn't be within this 9246675 license; merely being similar, like HQC, is definitely not enough to trigger the license. The question, then, is whether HQC is covered by 9246675. As always, the doctrine of equivalents says that patents cover not just what's literally claimed but also anything that's doing "substantially" the same thing, so a patent lawyer will pull out endless literature on similarities between HQC and the patent. NIST's report even feeds into this by saying that HQC is "similar in structure" to LPR, ML-KEM, etc. An HQC user targeted by 9246675 wins if the court doesn't accept the doctrine-of-equivalents argument. Otherwise I think there's some chance of success of an ensnarement defense. The way this works is that the court challenges the patent holder to retroactively expand the patent claims, and then the court will ask whether the expanded "hypothetical" claims (1) would also have been patentable and (2) literally cover HQC. It's not immediately obvious to me that the patent holder will be able to get past this. On the other hand, the patent holder has carte blanche to engage in retroactive creative writing, so thinking through all the possibilities in advance is labor-intensive. This analysis then has to be repeated for other patents in the same minefield, such as the Zhao patent that claims Kyber coverage. HQC was modified in October 2024, so any patent filed before then might apply. Patent applications typically aren't public until 18 months later. ---D. J. Bernstein ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] [IANA #1413503] expert review for draft-ietf-tls-esni (tls-extensiontype-values)
Dear Yoav Nir (cc: tls WG, tls-reg-review mailing list), Following up on this; as a designated expert for the TLS ExtensionType Values registry, can you review the proposed registration in draft-ietf-tls-esni-23 for us? Please note that Nick Sullivan is a co-author for this draft and that Rich had already approved. Please see: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ The due date is March 18. If this is OK, when the IESG approves the document for publication, we'll make the registration at: https://www.iana.org/assignments/tls-extensiontype-values/ We'll act after both experts approve the registration. With thanks, David Dong IANA Services Sr. Specialist On Thu Mar 06 21:31:55 2025, david.dong wrote: > Dear Yoav Nir (cc: tls WG, tls-reg-review mailing list), > > As a designated expert for the TLS ExtensionType Values registry, can > you review the proposed registration in draft-ietf-tls-esni-23 for us? > Please note that Nick Sullivan is a co-author for this draft and that > Rich had already approved. > > Please see: > > https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ > > The due date is March 18. > > If this is OK, when the IESG approves the document for publication, > we'll make the registration at: > > https://www.iana.org/assignments/tls-extensiontype-values/ > > We'll act after both experts approve the registration. > > With thanks, > > David Dong > IANA Services Sr. Specialist > > On Wed Feb 26 18:26:30 2025, david.dong wrote: > > Hi Nick, > > > > Yes, that's correct; this review request is for the two new > > registrations in section 11.1 in the TLS ExtensionType Values > > registry, which has the registration procedure of Specification > > Required. > > > > Thank you. > > > > Best regards, > > > > David Dong > > IANA Services Sr. Specialist > > > > On Wed Feb 26 08:10:28 2025, nicholas.sulli...@gmail.com wrote: > > > I’m conflicted out as mentioned, but I want to clarify: this > > > request > > > is for > > > the code points in the existing extension (section 11.1), not the > > > request > > > for the alert code point (11.2) or the new extension registry > > > (11.3), > > > correct? > > > > > > On Wed, Feb 26, 2025 at 3:15 AM Salz, Rich > > > wrote: > > > > > > > I approve. > > > > > > > > The draft does not say if the existing TLS DE's will do the new > > > > table, but > > > > I am okay with taking on that additional workload :) > > > > > > > > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Comment on draft-bmw-tls-pake13
I went through the PAKE draft on TLS 1.3, and while I certainly appreciate the use of a PAKE within TLS, I would like to highlight one potential security issue that the working group needs to be aware of. The draft has SPAKE2+ as its sole defined parameter set; SPAKE2+ has a rather interesting property that if the attacker can perform a single discrete log problem, in particular, compute the discrete log of N to the base of M, that is, find k such that kM = N, then the PAKE properties go away. That is, an active attacker can perform a single exchange, and then efficiently run through his dictionary of potential passwords and (as long as the correct password is in the dictionary) recover the password. Let me repeat this: if someone can solve a single discrete log problem (for example, if he has a slow Cryptographically Relevant Quantum Computer), then the attacker can immediately attack any SPAKE2+ implementation using that parameter set, anywhere in the world. If the working group endorses SPAKE2+, then they need to be aware of this, and should highlight it in the security considerations. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Artart last call review of draft-ietf-tls-esni-23
Reviewer: Carsten Bormann Review result: Ready with Nits (Insert ARTART boilerplate here.) Thank you for this draft, it is in very good shape. The document is explicit about the different configurations the protocol can be run in, the participants, their roles, the security and privacy objectives that can be achieved as well as the security considerations, and it discusses (and addresses!) deployment considerations. This specification is ready with nits. A few editorial observations and a few nits below. ## Editorial 10.1 »Security and Privacy Goals« starts with definitions (active/passive) that aren’t really Security/Privacy goals. Since “passive” is then used distinguishingly in only three places, it is not clear that this passage is particularly useful. It is also puzzling to sort filtering middleboxes under “passive”. 10.1: I cannot find a discussion of a “threat model” under this name in RFC 8446. 10.1: This section starts using the term “host” as a noun with a distinguishing quality that in this document is probably related to server_name, but not explained (“host” as a noun does not occur in RFC 8446). 10.2 appears to address integrity only, where the heading might suggest some discussion about confidentiality. I don’t understand the last sentence of 10.3 (“servers with high load”…). 11.3: After »A "Y" or "N" value indicating if the extension is TLS WG recommends that the extension be supported.« — can’t parse »Adding a value with a value of "Y" requires Standards Action .« -- s/value/registration/ ? 10.11: I would have expected a brief discussion on how granularizing the padding to 32 byte steps cannot be used by an attacker to extract information beyond that granularity (by causing the client to vary the size before padding, straddling a step). ## Nits Please do a pass of replacing “which” with “that” where a restrictive clause is intended (usually easy to find by the lack of a comma, about two dozen occurrences) Thank you for the many section references; two more could be used in »Note that, if the cookie includes a key name, analogous to Section 4 of« and »RFC8446]) when ECH is negotiated.« There are at least 17 occurrences of ‘bytes’ for counting lengths in bytes and 3 of ‘octet’/‘octets’. Please expand HRR on first use. Please define “ECH key” (8 occurrences) and “ECH record” (5 occurrences). Please define “application profile” and “application profile standard” (10.4 uses “application using (D)TLS” — is that the same?) 1: »the SNI remains the primary explicit signal used to determine the server's identity.« -- used by whom? Figure 2 uses private.example.com in the second variant where private.example.org is used in the first; may want to use .org here as well 5: it is slightly surprising that the definition list explaining config_id and cipher_suite does this in an order different from the TPL in the figure above 5.1: The first figure has a cliff-hanger (length_of_padding); maybe add a reference to 6.1.3. 5.2: »This value does not include Handshake structure's four-byte header in TLS,« 6.1.1: »Including ClientHelloOuterAAD as the HPKE AAD binds the ClientHelloOuter to the ClientHelloInner, this preventing attackers« s/this/thus/ ? 6.1.3: »through -their length« 6.1.3: »that have sensitive-length fields« (hyphen ➔ space) 6.1.6 »yield a tracking vector« — for whom? ➔ supply the server with a tracking vector? 6.1.7: »reference identity« -- define? 6.1.7: »(e.g. [RFC3986], Section 7.4 and [WHATWG-IPV4])« The "and" does not work here 6.2.2: »Correctly-implemented client will ignore those extensions.« 10.9: could use superscript in place of 2^64 (This of course only applies to usage in text, which seems to be the only one here.) 10.10.4: »out-of-scope. including, « I assume “page” in 11.3 is what is now called “registry group”? ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
