Hi Jiawei,
On 10/25/26, 8:42 PM, "wujiawei (E)" <wujiawei51@xxxxxxxxxxxxxx> wrote:
Hi Dan and Jay,
Here are my thoughts on this topic.
1. Regarding mapping to CPaceOQUAKE draft vs. writing our own version, there is also a timeline concern. As the CPaceOQUAKE draft has not been adopted
as a Working Group draft, an optimistic estimate on the time when it is published as RFC would be after ~3 years (according to the information provided by Mathy). Mapping to the IRTF draft means our draft relies on the IRTF draft. This raises the following
questions:
·
Q1: If TGbt is to finish its work within 3 years (as the current timeline suggests), do we accept that the final TGbt draft depends on an unpublished IRTF draft?
·
Q2: If the answer to Q1 is no, is TGbt willing to extend its timeline to wait for CPaceOQUAKE to stabilize?
First of all, I’d answer Q1 with yes. But I think it’s the wrong question.
Why do we care the date that TGbt finishes? Look at the PQC 802.1X stuff. That is being implemented today and it is going to be tested early next year. There will be certifications of correct implementations OF OUR DRAFT which, as you note,
is not final and is in a state of flux. But so what? If there was a catastrophic issue found with the current 802.1X text the draft would change but people feel it’s stable enough to implement so as far as PQC 802.1X is concerned, who cares when TGbt is published
as an official amendment to IEEE Std 802.11?
I feel the same way about the PAKE. We already know what the PQC PAKE is going to look like, it’s going to be CPace whose output is used to do OQuake(+) and the result of both will be mixed together to output (a) key(s). That’s the 10,000’
view and, yes, there’s lots of details the group needs to agree upon but none of those decisions change the general outline. We can, and should, have a specification of this PQC PAKE that is as faithful to the draft today as makes sense for 802.11 given what
we want and agree upon. If something catastrophic happens we can change to fix the spec and anyone who has implemented it will change as well. Such is life.
This whole thing about a draft vs an RFC I think is misguided. These are not protocol RFCs whose adherence is a must. If you diverge from an IPsec RFC then you don’t interoperate and you’re not IPsec-compliant. Same for TLS. But the drafts
we’re talking about are specifying tools, not protocols.
Look at hash-to-curve. 802.11 specified hash to curve from a CFRG I-D that was in flux because there was demand for fixing the hunting-and-pecking part of SAE (this was 2019). And what happened? The hash-to-curve stuff in 802.11 diverged
from what ended up becoming RFC 9380. Should we have waited? Well, we would’ve waited for 4 years because RFC 9380 was published in 2023. And wait for what? To be RFC compliant? So what? Is there a problem with the SAE hash-to-curve stuff? No. It’s different,
but it’s secure and waiting 4 years before we did anything about hunting-and-pecking would’ve been ridiculous—“oh, sorry, we can’t fix this unfortunate part of our PAKE because the solution is not an RFC yet, gotta wait 4 more years.”
There is strong demand for a PQC PAKE and there’s no reason to wait 3+ years to implement one. We can easily specify a hybrid PAKE using the existing literature. Will it end up diverging from what becomes an RFC in 3 or possibly 4 years?
Maybe. Probably. But, again, so what? There is no interoperability concern with abiding by the letter of this kind of RFC. The interoperability concern is with one 802.11 implementation interoperating with another 802.11 implementation. We can get that if
we specify a protocol using this tool in the TGbt draft.
If nobody cared about a PAKE that would be one thing. But they do care. We have already told 2 other organizations that we’re working on a PQC PAKE. They are expecting us to deliver something in a reasonable amount of time and not say,
“oh, about the PAKE? Forget it. We’re gonna wait 4 years. Get back to us then.” 3 or 4 years is not a reasonable amount of time. And the reason to wait 3 or 4 years is simply to be word for word compliant with an RFC when such compliance is not strictly necessary?
I don’t think that makes sense.
2. Regarding the aPAKE version CPaceOQUAKE+, I agree that TLS integrating aPAKE does not necessarily mean we should do the same. I try to list the
major benefits and costs of doing CPaceOQUAKE+ in 802.11 here for discussion
Benefit:
·
If the AP is broken or hacked, the adversary cannot impersonate a STA using the verifiers.
I would add to that that a STA can still be induced to connect to a rogue AP run by the attacker who hacked into the network. So the benefit is somewhat qualified in that it solely benefits the network. And it’s the network that already
got hacked. Is there possibly a better strategy? Yes! Secure your password database.
Network view: well I got hacked and lost the family jewels but I still have an assurance that only a trusted client can connect, in the mean time my network has been hacked and I’m changing all of the passwords so the client isn’t going
to be able to connect anyway.
Client view: I may be connecting to a rogue AP and a compromised network run by attackers which would be the case with a balance PAKE too. So why did I insist on an aPAKE again?
Cost:
·
One extra message. The challenge message contains KEM ciphertext (for X-WING, the ciphertext size is 1120 bytes)
·
Requires a mechanism for registration (can be out of band)
You mention X-Wing. So the other cost is implementing this extra stuff that we currently don’t implement, like x25519, and X-Wing, and scrypt. Granted that’s not onerous and, with the exception of the X-Wing KEM, is all available in your
standard crypto library, but this is extra primitives and there is a cost with defining their use in 802.11.
And it’s 2 extra messages, not 1, because the aPAKE requires the client to initiate OQuake+ since the server is required to send the ciphertext using the client’s encaps key. If you look at the -03 version of draft-vos you will see that
the balanced protocol is 3 messages and the asymmetric one is 5 messages.
Also, another cost is increase in memory due to the stretching requirements of scrypt which the balanced PAKE does not require. This may matter for small, constrained devices.
One final cost is in what are we going to do about AP-to-AP communication or mesh? Those compel a balanced approach. So we either say, we’re abandoning mesh and ignoring AP-to-AP, or we have to implement both an asymmetric PAKE for infrastructure
BSS and a balanced one for mesh, and IBSS, and AP-to-AP. Granted there is some overlap that can be had since there is great similarity in those two specifications but it would still come down to implementing 2 ways of doing the same thing. That is definitely
an additional added cost.
Finally, given all this concern of “divergence” from draft-vos, please look closely at the TLS draft that Jay sent a pointer to. IT DIVERGES FROM DRAFT-VOS!!! But you will notice the authors are not saying, “you know what? Let’s not specify
anything right now, let’s wait 4 years for draft-vos to become an RFC and then we’ll start talking about a PQC PAKE for TLS.” They’re trying to specify a version of this for TLS today. And it’s already diverged from draft-vos. That is the lesson we should
learn. It’s not to copy what is being proposed for TLS (that would not work for 802.11) it’s to follow their example of applying the tool that is being specified today in draft-vos appropriately for their protocol. We can, and should, do the same.
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
Best,
Jiawei
From: Harkins, Dan <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, October 26, 2026 1:50 AM
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
Hi Jay,
On 10/23/26, 6:06 AM, "Jay Yang" <yang.zhijie@xxxxxxxxxx> wrote:
Hi Taochun,
Thanks for sharing insight.
I would say the group should create a cryptography mapping subclause to show all the differences（including
some enhancement）between 802.11 and IETF draft/RFC when adapting
to 802.11. Rather than duplicating the whole PQC PAKE pake protocol defined by CFRG into 802.11 draft.
I’m not so sure about that. I think that subclause would result in more churn than if we just wrote our own version—as close as possible to the draft—of CPaceOQuake. That way the difference arise when we have a
compelling need to incorporate them and then we have draft churn. If we have a subclause of differences it will constantly change as the draft changes but we don’t need to. Every change made that really doesn’t matter to us would need to be mapped.
There is a good example in TLS to show how to integrate (PQC) PAKE into TLS 1.3 PAKE protocol: (draft-ietf-tls-pake-02
- A Password Authenticated Key Exchange Extension for TLS 1.3), please have a look.
I don’t think that integration is helpful for us. CPaceOQuake(+) cannot be used directly in TLS 1.3 because it requires more than 2 messages to complete and it has sequential requirements on multiple protocols.
That is why section 7 of the draft exists, to support these sorts of exchanges that cannot fit directly into the TLS handshake. What the draft specifies is:
“External PAKEs execute their complete protocol exchange outside of TLS, then integrate with TLS through External PSK Import [RFC9258].
This approach enables protocols that cannot be constrained to the two-message limit of Internal PAKEs.”
Which means you need some external out-of-band communications channel set up to run both CPace by itself, and then OQuake+ by itself. As the draft says:
“Both parties must support CPace and OQUAKE+ protocols for out-of-band execution. Applications configure out-of-band communication channels and TLS endpoints separately.”
So you need to run 2 separate protocols before you import the result (an “external PSK”) into TLS. That doesn’t sound like something we want to do. We, 802.11, are not an “application” that can assume any kind of
connectivity to run protocols out-of-band. Everything is done in 802.11 pre-association and it doesn’t seem like a good idea to attempt this kind of thing.
BTW, the hybrid PQC PAKE adapted by TLS 1.3 PAKE is CpaceOQUAKE+, it's natural for 802.11 to adopt the same protocol in the infrastructure
BSS senario.
Is it really? I don’t think so. It says, in 7.3.3, that the parties exchange OQuake+.Init and OQuake+.Respond and then derive the hybrid_secret. How does it do the asymmetric PAKE in 2 messages without OQuake+.Finish?
The client needs to confirm possession of the password via successful decapsulation of the ciphertext sent by the server. But without that message I don’t think it’s really doing the + version of the protocol.
Why do you think it is “natural to adopt the same protocol in the infrastructure BSS scenario”? I mean, there may be benefits to doing the + version but there are also costs. Are those benefits something we cannot
live without? Do those benefits for us outweigh the costs to us? What TLS does is up to TLS. But they have different requirements and different constraints. The decision making process of TLS is not ours and what they end up deciding really has
no bearing on what we do. We need to come to an agreement on what to do based on our requirement and our constraints.
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
杨志杰10343608
Thanks
Best Regards
Jay Yang (杨志杰)
Original
From: TaoChunLee(李道軍)
<000062f6c3142c4b-dmarc-request@xxxxxxxxxxxxxxxxx>
To: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx
<STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx>;
Date: 2026年10月23日
16:50
Subject: Re: [STDS-802-11-TGBT] Fw: IEEE 802.11 liaison communication to IRTF regarding draft-vos-cfrg-pqpake
Hi Dan,
Concur with the idea to shape the 802.11 version of CPaceOQuake, what else do you see are redundant besides lv_cat()? The group needs
to converge on a list of CPaceOQuake redundancy when adapting to 802.11.
--
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: Harkins, Dan <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, October 20, 2026 4:54 AM
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
|
External email : Please do not click links or open attachments until you have verified the sender or the content. |
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
From: Nick Sullivan <nicholas.sullivan@xxxxxxxxx>
Sent: Wednesday, October 14, 2026 9:49 AM
To: Stacey, Robert <robert.stacey@xxxxxxxxx>;
peter@xxxxxxxxxx <peter@xxxxxxxxxx>
Cc:cfrg-chairs@xxxxxxxx <cfrg-chairs@xxxxxxxx>;
housley@xxxxxxxxxxxx <housley@xxxxxxxxxxxx>;
sasecretary@xxxxxxxx <sasecretary@xxxxxxxx>;
gilb_ieee@xxxxxxxx <gilb_ieee@xxxxxxxx>;
asterjadhi@xxxxxxxxx <asterjadhi@xxxxxxxxx>;
mccann.stephen@xxxxxxxxx <mccann.stephen@xxxxxxxxx>;
sorr@xxxxxxxxx <sorr@xxxxxxxxx>
Subject: Re: IEEE 802.11 liaison communication to IRTF regarding draft-vos-cfrg-pqpake
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
_______________________________________________
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
************* 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