| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi all, Thanks to the experts for trying to address the issue of the missing PQC PAKE in 802.11bt. For those of us who are not security experts, can someone clarify the following:
Looking at the discussion so far, I'd make the following observation and ask one additional question:
Regards, Sigurd From: Jay Yang <yang.zhijie@xxxxxxxxxx>
This email was sent from outside of MaxLinear. Hi Dan, Thank you for the further response. I also appreciate your pointing out the reference issue in my contribution. In the 3GPP specification (3GPP TS 23.261 (Rel-10)), the reference format of I-D is as follows: [8] IETF Internet-Draft, draft-ietf-mext-flow-binding-09.txt, "Flow Bindings in Mobile IPv6 and Nemo Basic Support", work in progress. [12] IETF Internet-Draft, draft-ietf-mext-binary-ts-04.txt, "Traffic Selectors for Flow Bindings", work in progress. I plan to remove the URLs from my contribution and correct the reference issue as follows: IETF Internet-Draft, draft-vos-cfrg-pqpake-03.txt,
"Hybrid Post-Quantum Password Authenticated Key Exchange", work in progress, 13 October 2026. Additionally, I will try to address as many as possible other issues pointed out in 26/1452r1 in the next revision before/after I arrive in Bangkok. Let us continue
the F2F discussion then and look forward to more cooperation. 杨志杰10343608 Thanks Best Regards Jay Yang (杨志杰)
Original From: Harkins,Dan <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx>
To: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx
<STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx>; Date: 2026年10月30日
13:55 Subject: Re: [STDS-802-11-TGBT] Fw: IEEE 802.11 liaison communication to IRTF regarding draft-vos-cfrg-pqpake
Jay, Thanks for the rule dump. I’ll note the excerpt “IEEE 802 prefers that this be avoided if at all possible.” Can we avoid this? Yes, we absolutely can. It says that it is inappropriate to use an I-D as reference material and that is EXACTLY what you’re doing. You’re not citing it as a work in progress, you’re
using it directly as reference material because you’re including URLs to an I-D in your submission! What is inappropriate is this from11-26/1203r4: a)
Encapsulate
ut (part of upk) using 2-round Feistel encryption, producing
S and T, following the equations defined in subclause 8.2.1 (Initiation) :
https://datatracker.ietf.org/doc/draft-vos-cfrg-pqpake/02/. It’s a URL! This is not citing it as a work in progress. You’re
referring, directly and normatively, to an I-D, it is reference material. That is exactly what is deemed inappropriate. And while you say “/02”, the URL you’re pointing to, if anyone bothered to click on it, is actually the -01 version. To make this
even worse, there is no 8.2.1 in the -01 version of this I-D that you’re pointing to* so this section in your submission is not coherent. Anyone who tried to follow the URL you provide would be presented with something that didn’t exist—“follow the equations
in section 8.2.1 of this Internet-Draft that doesn’t have an 8.2.1 section.” This is not “a dated, versioned reference” as you try to portray it. Furthermore, this URL is already old! The current version is -03 and you’re referring to -01. So what do you propose? Constantly updating the TGbt draft to inappropriately refer to a URL and have the URL change as the I-D changes? And
hope that nothing changes in the URL-referenced document to break things in the TGbt draft? Well sorry, your submission has already been broken (assuming it could be updated to point to -03) because the + version of the protocol behaves differently than the
non-+ version in the response so your 12.17.6.2.3.2 doesn’t work using the (inappropriate) reference. Can you give any example of this sort of thing—a URL being inserted into a proposed amendment to the IEEE 802.11 standard to specify normative behavior—being done in any other TG in 802.11? As someone who implements 802.11 standards I can tell you this is not a realistic method of spec development. It would mean nothing could be implemented for at least 3 and probably more like 4+ years because there’s no way to implement
to a moving target. We cannot wait 4+ years to have an implementable PAKE in TGbt. You said my proposed model is “not a wise approach” but I described exactly how it works in practice and it works great. Our standard is not suffering today for practicing this model in the past. If you would like to criticize the model
of spec development I’m proposing then please directly address it as I have addressed your proposal for spec development. Dan. * I know you’re gonna try and fix this in an update to 11-26/1203 before the Bangkok meeting (after I pointed the problem out to you here) but it won’t matter because it illustrates the problem with the scheme you are proposing. It’s broken.
It doesn’t work. It’s not sustainable. -- “the object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane.” – Marcus Aurelius On 10/29/26, 4:59 PM, "Jay Yang" <yang.zhijie@xxxxxxxxxx> wrote: Hi Dan, Thanks for the response. Seems there is some misunderstanding on the I-D boilerplate: The boilerplate says it is inappropriate to cite a draft
other than as work in progress. Citing it
as work in progress — which is exactly what a dated, versioned reference does — is not prohibited by that text; it is the only use the boilerplate contemplates.
Status
of This Memo
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts
is at
https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." Also, according to the the Cross-Referencing rule(see highlight part below) between IETF and IEEE 802 defined in RFC 7241, it's allowed to reference non-expired ID
by IEEE 802. Correct? Welcome your further insights, and feel free to correct me if I make any mistake. 3.4 Cross-Referencing IETF and IEEE 802 each recognize the standards defined by the other organization. Standards produced by each organization can be used as references in standards produced by the other organization. IETF specifications may reference IEEE 802 work in progress, but these references should be labeled "Work in Progress". If the references are normative, this will block publication of the referring specification until the reference is available in a stable form. IEEE 802 standards may normatively reference non-expired Internet- Drafts, but IEEE 802 prefers that this be avoided if at all possible. Informative references in IEEE 802 standards are placed in a bibliography, so they may point to either approved IETF standards or IETF Internet-Drafts, if necessary. When an IEEE 802 standard is revised, it normally retains the same number and the date is updated. Therefore, IEEE 802 standards are dated with the year of approval, e.g., IEEE Std 802.1Q(TM)-2011. There are two ways of referencing IEEE 802 standards: undated and dated references. IEEE 802 practice allows undated reference to be used when referencing a whole standard. An undated reference indicates that the most recent version of the standard should be used. A dated reference refers to a specific revision of an IEEE 802 standard. Since clauses, subclauses, tables, figures, etc., may beDawkins, et al. Informational [Page 15] RFC 7241 IEEE 802/IETF Relationship July 2014 renumbered when a standard is revised, a dated reference should be used when citing specific items in a standard. IETF standards may be cited by RFC number, which would also be a dated reference. If an undated reference to an IETF Internet Standard is desired, a number is also assigned in the "STD" series [BCP9], and these references refer to the most recent version of an IETF Internet Standard. 杨志杰10343608 Thanks Best Regards Jay Yang (杨志杰)
Original From: Harkins,Dan <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx>
Date: 2026年10月28日
01:39 Subject: Re: [STDS-802-11-TGBT] Fw: IEEE 802.11 liaison communication to IRTF regarding draft-vos-cfrg-pqpake
Hi Jay, I would like to focus on just this one paragraph of yours: On 10/25/26, 11:01 PM, "Jay Yang" <yang.zhijie@xxxxxxxxxx> wrote: The key point is that the PQC PAKE protocol is merely a tool for 802.11. Why should we duplicate the entire protocol into the 802.11 draft? In the event that a security
issue arises within the Wi-Fi industry, who would be responsible for addressing it? Since the authors are part of CFRG, not 802.11, it is not a wise approach. I’m not sure what you mean by “merely a tool” and I don’t follow how that means we shouldn’t duplicate the protocol in the TGbt draft. I have been maintaining that the CFRG draft describes a tool—in fact several tools—and not a protocol
with on the wire (or over the air) specification. Therefore we can, and should, take as much of that draft as possible and incorporate it into our draft (that has over the air specification) so that we have something implementable. I will tell you why we should not refer to the draft. First of all, the I-D itself says in its boilerplate “It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ‘work in progress.’” So it is
inappropriate to refer to drafts. We need to duplicate the parts of the draft we want if we don’t want to wait 4 years to have an implementable 802.11 PQC PAKE. If we were to ignore that and refer to the draft anyway, it would not be implementable because
that draft, as we have seen, is a moving target. It would not be possible to implement the TGbt draft if the draft just points to a moving target. I maintain it would be wrong for the group to not have anything implementable for 4 years, especially since
we have told 2 external organizations that we’re working on a PQC PAKE. Therefore, we need something solid in the TGbt draft that can be implemented and we need it ASAP, not in 4 years. Regarding what happens if “a security issue arises within the Wi-Fi industry”. Well, the Wi-Fi industry, by whatever definition you use, should handle it. If someone in the CFRG identifies a flaw or an issue in the CFRG draft (or even
in an RFC) then the Wi-Fi industry should look at the issue, see if it applies to what we have and if so, address it in the recommended manner. There is precedence for this! Let me give you a little 802.11 history: SAE proposed a rejection sampling method method of PWE computation (euphemistically called “hunting-and-pecking”) because the alternative, Icart’s method, was patented. In 2019, the Dragonblood attack showed that hunting-and-pecking
was flawed. It could be done in constant time but it was fragile and wasteful and just about every implementation did it wrong. Serendipitously, around that time an unpatented way of hashing to an elliptic curve was being proposed in… guess where… the CFRG.
But it was a draft and it was inappropriate to just refer to it. We needed something in the standard that was implementable. The draft discussed several ways to hash to a curve for different types of elliptic curves. But we only supported a few curves—the
NIST ones and the brainpool ones, all Weierstrass curves—so I copied a part of the CFRG draft that did the Simplified Shallue-Woestijne-Ulas (SSWU) method with Weierstrass curves which became 11-19/1173. That eventually got put into the TGm draft. SSWU uses
a constant, z, which I calculated, and it became table 12-2 “Unique Curve Parameter”. After some time, someone on the CFRG list pointed out that the formula to calculate z might be patented. So the CFRG draft changed to come up with a different formula to
calculate z. So guess what we had to do? Change the formula in the the TGm draft! So I wrote 11-19/1817 which changed the formula and generated new values for z. And that’s what we have today. A copied subset of what ended up becoming an RFC. Our standard
diverges from the RFC but it doesn’t matter because what we have is secure and it works and it is not patented. When an issue arose with the CFRG draft we addressed it ourselves. This model works and we should do it in TGbt. We should take the parts of draft-vos that we need and specify a PQC PAKE in the TGbt draft. If any issue arises in draft-vos (or draft-irtf-cfrg-whatevernameitbecomes) we should analyze
the issue, and if it is applicable to what is in the TGbt draft we should change the TGbt draft in the manner recommended by those who came up with the issue. This is not a problem. It works and it is a wise approach. Regards, Dan. -- “the object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane.” – Marcus Aurelius To unsubscribe from the STDS-802-11-TGBT list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1 To unsubscribe from the STDS-802-11-TGBT list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1 To unsubscribe from the STDS-802-11-TGBT list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1 To unsubscribe from the STDS-802-11-TGBT list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1 To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1 |