Re: [STDS-802-11-TGBT] Fw: IEEE 802.11 liaison communication to IRTF reg

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Hi Dan,

Thanks for the detailed answers – very helpful.

Regarding your question about who would conduct the security review, I was hoping that candidate proposals for consideration in 11bt would already come with a security analysis and supporting evidence. In that case, the TG could limit itself to verifying that the assumptions and conditions under which the analysis is valid still hold for the PAKE as ultimately specified by 802.11bt.

Regards,

Sigurd

From: Harkins, Dan <daniel.harkins@xxxxxxx>
Sent: Friday, October 30, 2026 4:39 PM
To: Sigurd Schelstraete <sschelstraete@xxxxxxxxxxxxx>; STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBT] Fw: IEEE 802.11 liaison communication to IRTF regarding draft-vos-cfrg-pqpake

⚠ External: Verify sender, links and requests.

Hi Sigurd,

On 10/30/26, 10:20 AM, "Sigurd Schelstraete" <0000147fea1cee5c-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

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:

1. The IRTF response mentioned ongoing discussions on draft-vos over the reflector. Can someone summarize the discussion points? Are there any identified fundamental shortcomings?

There have been requests on the CFRG mailing list to do a call for adoption. The IETF is the week after the IEEE and I do expect this topic to come up. CFRG has 2 meeting slots. I will be attending and will let the TG know what happens.

The CPaceOQuake draft is also dependent on another CFRG draft (which *is* a RG document) called kemeleon and there are 2 pull requests (from Mathy Vanhoef) on the kemeleon github repository to make the encoding and decoding work in constant time. I’m confident those will be accepted.

2. If I understand correctly, CPACEOQUAKE comes with a formal security proof. Is this proof generally accepted by the cryptographic community, or are there aspects of the proof that remain under discussion?

CPaceOQuake itself does not have a formal security proof. CPace has a security proof. It is based on classical cryptography and therefore is vulnerable to a cryptographically relevant quantum computer. It is “quantum annoying” though the quantum attacker will be slowed down. The security of OQuake is discussed in section 11.2 of draft-vos. Here’s a link:

https://datatracker.ietf.org/doc/html/draft-vos-cfrg-pqpake-03#name-security-against-quantum-at

So UC is the gold standard of cryptographic proofs and OQuake does not realize UC functionality against certain quantum attackers but it does have a game-based security proof in the random oracle model.

The composite protocol has been analyzed by 3 different groups, as mentioned in the draft. So there is confidence in the construction of the hybrid protocol. There are some caveats: the identities are important to the proof and OQuake needs to get a derived secret and not the raw password, but those are part of the CPaceOQuake draft already. Provided those are satisfied in a TGbt version of CPaceOQuake (and they are in 11-26/0089r7) I feel comfortable with the protocol. I’m sure others will voice their opinions either way.

3. With draft-vos being an individual contribution at this point, are there any alternatives for PQC PAKEs (at any stage of development) that could potentially be considered for use in 802.11?

OQuake is very similar to NoIC which the security proof relies on but there’s no point in abandoning OQuake for NoIC because they’re essentially the same. And, as I mentioned, I’m pretty sure that it will be accepted as a CFRG RG work item. So the individual contribution concern should go away.

Looking at the discussion so far, I'd make the following observation and ask one additional question:

1. It does not appear that publication as a finalized standard is, by itself, the deciding factor. Some participants appear comfortable using draft-vos as the starting point despite the possibility of future changes, while others have raised concerns regarding its maturity or suitability. The key question therefore appears to be the maturity and confidence level of a proposal rather than on whether it has completed formal standardization.

I think that’s a very fair summary. The draft is clear about what needs to happen to retain the security guarantees it is providing and we, TGbt, can propose a protocol that abides by those requirements and whether it ends up being word-for-word identical to whatever RFC draft-vos becomes is, IMHO, irrelevant.

2. Can we agree that any PQC PAKE proposal adopted in 802.11bt should be supported by a formal security analysis, with sufficient public review to provide confidence in its security properties? By modern cryptographic standards, that appears to be a pretty basic expectation.

I think that’s a great idea. First things first, though. We need a protocol in the TGbt draft that can be analyzed. Do you happen to know anyone who would analyze our protocol?

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

Regards,

Sigurd

From: Jay Yang <yang.zhijie@xxxxxxxxxx>
Sent: Thursday, October 29, 2026 11:57 PM
To: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBT] Fw: IEEE 802.11 liaison communication to IRTF regarding draft-vos-cfrg-pqpake

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>

To: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBT@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