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

Re: [STDS-802-11-TGBT] Fw: IEEE 802.11 liaison communication to IRTF regarding draft-vos-cfrg-pqpake

 

  Hi Mathy,

 

  Good collection of documents. There’s also draft-irtf-cfrg-dnhpke which is not an RFC but has been in working group last call (next stop before RGLC and then publication as RFC) for several years. CFRG is active for some stuff and a graveyard for others. My draft is in the graveyard.

 

  But I think the issue is not so much when it was published as an RFC after it was adopted as a RG item. I think it’s better to look at when the draft became *stable* which is when other documents can start considering referencing it. And given the fact that CPaceOQuake is based on other cryptographic work that has good providence—CPace, hash-to-curve, NoIC—I think the time to acceptable stability is not that long.

 

  That said, one of my gripes about CFRG is that its documents are doing more E than R, that is its more IETF than IRTF. IRTF is supposed to make tools, IETF uses the tools in a protocol. It used to be that IRTF documents didn’t need IANA registries because they’re not proposing a protocol. Now we have all sorts of IRTF documents with IANA considerations. And they are proposing on-the-wire formats which not everyone needs. For instance, lv_cat(). 802.11 has elements. Our data already have length indicators. We don’t need to lv_cat() an Information Element. That’s redundant, it’s overkill. But CPaceOQuake is specifying the use of lv_cat() when constructing the messages it sends.

 

  Given the fact that the TG has already told 2 external organizations that we’re working on a PQ PAKE I don’t think we can punt this effort to “whenever the CFRG comes up with an RFC or a draft of considerable stability.” We need something that is as faithful to CPaceOQuake as possible (given the requirements of 802.11) and then we need to closely monitor the draft to see if there are any substantial changes that we need to incorporate. This will be an ongoing concern as the TGbt draft matures. The composition of these two PAKEs is discussed quite extensively and I think we can follow that text to define an 802.11 version of CPaceOQuake that addresses the needs of 802.11 but is not so rigid that it cannot change if considerable changes are made to the CFRG draft. But I don’t think we necessarily need to be 100% aligned with the draft. This is not going to be showing up as an API to call in OpenSSL—e.g. “pmk = cpaceoquake(password, sta-mac, ap-mac, profile)—so we don’t need to treat it as a black box. That doesn’t mean we should just roll-our-own though. The draft has some very specific, cryptographically justified, and well defined, key derivation and it would behoove us to not deviate from that. But if other aspects of the draft are not really compelled by a use case, then just saying “well the draft says to do this so we’re doing it” is not right.

 

  Interested in other opinions.

 

  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

 

 

On 10/18/26, 1:48 AM, "Mathy Vanhoef" <00006588701cd687-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

 

Hello all,

 

Making predictions is hard, especially about the future. Nevertheless, at least for me it was useful to look up the timelines of a few other recent cryptographic RFCs to have a comparison:

 

- OPAQUE (RFC 9807): adopted in September 2020, published in July 2025.

 

- SPAKE2 (RFC 9382): adopted in January 2015, published in September 2023.

 

- OPRF/VOPRF (RFC 9497): adopted in July 2019, published in December 2023.

 

- Hashing to Elliptic Curves (RFC 9380): first CFRG group draft in March 2018, published in August 2023.

 

- HPKE (RFC 9180): adopted in June 2019, published in February 2022.

 

Here, 'adopted' means adopted by the CFRG as a research-group document. The CPaceOQUAKE draft has not yet been 'adopted' (but may soon be?). All of the above are Informational RFCs. Of course the timeline of CPaceOQUAKE may be substantially faster (or slower), but this at least gives something to compare to.

 

> This IETF message seems to generate more doubts on basing PAKE on draft-vos-cfrg-pqpake: only an individual draft, not IETF standards, security analysis inconclusive, etc.

 

Note that the authors already provide a formal security analysis of CPaceOQUAKE [1]. Further work analyses the security of the underlying PAKE construction and hardens against timing attacks [2], and the hybrid PAKE combiner is analysed in [3]. The CFRG process provides an additional security review. Arguably one downside is that CPaceOQUAKE is still a fairly new security protocol, but at the same time, I am not aware of a better alternative.

 

Best regards,

Mathy

 

[1] https://eprint.iacr.org/2025/1343

[2] https://eprint.iacr.org/2025/1399

[3] https://eprint.iacr.org/2024/1621

 

From: Harkins, Dan <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: 15 October 2026 17:38
To: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBT] Fw: IEEE 802.11 liaison communication to IRTF regarding draft-vos-cfrg-pqpake

 

 

  Hi Tao Chun,

 

 

On 10/15/26, 1:36 AM, "TaoChun Lee (李道軍)" <000062f6c3142c4b-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

 

Hi all,

 

This IETF message seems to generate more doubts on basing PAKE on draft-vos-cfrg-pqpake: only an individual draft, not IETF standards, security analysis inconclusive, etc.

 

It is an individual draft right now. It will not stay that way. Yes, it will be an informational RFC not a standard. Know what other things we use that are informational RFCs and not standards? HKDF (RFC 5869), HMAC (RFC 2104), CCMP (RFC 3610), SIV (RFC 5297), AES Key Wrap (RFC 3394), ECDSA (RFC 6979). SAE wasn’t even based on an RFC. We have normative requirements in IEEE Std 802.11 that are based on informational RFCs all over the place. That should not be a determining factor in whether we adopt CPaceOQuake or not.

 

If the group still wants to leave option open for draft-vos-cfrg-pqpake, on security framework side, suggest to be agile or hybrid with other (native) options.

 

What do you mean leaving it open “on security framework side”? As opposed to what other side? What other option do you see on the security framework side? Also what do you mean “agile”? It’s already hybrid. Please explain what properties you’re looking for in a PAKE.

 

  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

 

--

Tao Chun Lee | Tech Manager, Standards | Communication System Design, MediaTek Inc.

Email: TaoChun.Lee@xxxxxxxxxxxx | Phone: +886 3 560 0868 | Website: www.mediatek.com

 

From: Stacey, Robert <robert.stacey@xxxxxxxxx>
Sent: Thursday, October 15, 2026 12:55 AM
To: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBT] Fw: IEEE 802.11 liaison communication to IRTF regarding draft-vos-cfrg-pqpake

 

Dear TGbt participants,

 

See below for a response to our liaison. Note in particular the last paragraph on providing more input to the CFRG.

 

Regards,

-Robert

Hi Robert, Peter,

Thanks for the liaison, and sorry for the slow reply. Here's where things stand on your three questions.

On adoption: draft-vos-cfrg-pqpake is still an individual draft. CFRG takes on work through a call for adoption on its mailing list, and we haven't run one for this draft, so we can't say yet whether it will be adopted. It was presented at IETF 126 in July, and discussion has continued on the list since then.

On timeline: we don't have dates, and CFRG doesn't work to fixed deadlines. If the draft is adopted, how long it takes to reach RG Last Call depends on how quickly the security analysis and reviews settle. After RG Last Call, the remaining steps (shepherd write-up, IRTF chair review, IRSG poll, IESG conflict review and RFC editing) typically take two months or more.

On stability: until a document has been adopted and has passed RG Last Call, its content can still change, including the wire format, so we wouldn't consider it stable enough for another SDO to reference before then. The draft lists some open research questions itself, and its security analysis is still being discussed on the list. Also note that CFRG documents aren't IETF standards. This one is intended as an Informational RFC.

The authors will present an update at the CFRG session at IETF 127 in San Francisco in November, and we'll discuss the draft there. 802.11 participants are welcome to join, in person or remotely.

It would help us to hear from 802.11, ideally on the CFRG list, about what P802.11bt needs: a balanced PAKE, where both sides hold the password as with SAE today, or an augmented one, where the access point or server stores only a verifier; whether it has to be hybrid; any limits on round trips or message sizes; and when TGbt needs a stable reference. That input will shape whether and how CFRG takes this on.

Best,
Nick, for the CFRG chairs

 

On Mon, Sep 28, 2026 03:05 PM, Russ Housley <housley@xxxxxxxxxxxx> wrote:

 

 

From: "Stacey, Robert" <robert.stacey@xxxxxxxxx>

Subject: IEEE 802.11 liaison communication to IRTF regarding draft-vos-cfrg-pqpake

Date: September 28, 2026 at 2:22:27 PM EDT

To: "alexey.melnikov@xxxxxxxxx" <alexey.melnikov@xxxxxxxxx>, Nick Sullivan <nicholas.sullivan+ietf@xxxxxxxxx>, "Stanislav V. Smyshlyaev" <smyshsv@xxxxxxxxx>, Russ Housley <housley@xxxxxxxxxxxx>

Cc: Alpesh Shah <sasecretary@xxxxxxxx>, "James P. K. Gilb" <gilb_ieee@xxxxxxxx>, Alfred Asterjadhi <asterjadhi@xxxxxxxxx>, "Stephen McCann" <mccann.stephen@xxxxxxxxx>, Stephen Orr <sorr@xxxxxxxxx>, Peter Yee <peter@xxxxxxxxxx>

 

Dear Alexey Melnikov, Nick Sullivan, and Stanislav V. Smyshlyaev:

 

The IEEE 802.11 working group is working on a project, P802.11bt, with the scope to “extend IEEE 802.11 security to support algorithms for post-quantum cryptography (PQC)”.  Part of this extension specifies “a password authenticated key exchange that uses PQC”. Some participants in IEEE 802.11 have taken particular interest in the work described in the individual draft draft-vos-cfrg-pqpake.

IEEE 802.11 would like to understand the status and expected direction of this work, and would be grateful if the CFRG could provide their opinion on:

1.      whether the CFRG anticipates adopting draft-vos-cfrg-pqpake as a research group document;

2.      the expected timeline toward RG Last Call and publication; and

3.      the point at which the CFRG would consider the specification sufficiently stable to be referenced by another standards development organisation.

This liaison conveys interest in the status of ongoing CFRG work. It does not constitute a decision by IEEE 802.11 to specify any particular mechanism, nor support of any individual Internet-Draft.

 

 

Sincerely,

Robert Stacey

Chair, IEEE 802.11 WLAN Working Group

 

Peter Yee

IETF Liaison, IEEE 802.11 WLAN Working Group

+1 415 215 7733

 

 

_______________________________________________
CFRG mailing list -- cfrg@xxxxxxxx
To unsubscribe send an email to cfrg-leave@xxxxxxxx

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 

************* MEDIATEK Confidentiality Notice ********************
The information contained in this e-mail message (including any 
attachments) may be confidential, proprietary, privileged, or otherwise
exempt from disclosure under applicable laws. It is intended to be 
conveyed only to the designated recipient(s). Any use, dissemination, 
distribution, printing, retaining or copying of this e-mail (including its 
attachments) by unintended recipient(s) is strictly prohibited and may 
be unlawful. If you are not an intended recipient of this e-mail, or believe 
that you have received this e-mail in error, please notify the sender 
immediately (by replying to this e-mail), delete any and all copies of 
this e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. Thank you!

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