| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Jay, I know there were several comments but no examples were given. That’s what I’m asking for. A problem with the submission that can be addressed. If a new authentication protocol requires new fields, they can be added and the key exchange that needs them will define the frame they reside in. In fact, that is *exactly* what I’m doing in my PAKE. I really think you should
take a look at the submissions I have created. I have a lovely framework that is extensible and have demonstrated its extensibility by adding: 1) a PAKE; 2) an unauthenticated exchange; 3) a signature-based PQC exchange; and 4) a PQC exchange that does authentication
without requiring signatures. This is a proof of concept of extensibility and forward compatibility. The way it works is the PAKE defines a new Authentication algorithm number and a new field—the “PQC Commit”. And the Authentication algorithm number plus the transaction sequence number tells the recipient whether it’s there or not and
the security profile number tells it how big it is. Kemeleon is deterministic and I will know how big a randomized encapsulation key will be so all I need to do is know what parameter set the key is from, which I will know. For my signature-based exchange
I defined a new field to hold the signature and specified (by transaction sequence number) which frames contain the new signature field and which do not. So it’s the same thing: the new signature-based Authentication algorithm number and the transaction sequence
number tells the recipient which frame holds a signature and signature field itself says how big it is. We could, and should, adopt my extensible framework for adding new protocols and then add a few. I know there is interest in a PAKE and I know there is interest in an unauthenticated exchange. I have defined both in 11-26/0089r4 and 11-26/0545r1,
respectively (soon to be an r5 and an r2, respectively, as soon as I see how the field vs. element arguments play out and whether my “misc cleanup” submission is adopted). It works. I’ve implemented it. It’s extensible. There are no compatibility issues. In
fact, I could even demonstrate forward compatibility by adding support for Classic McEliese in the authentication without signatures exchange since the ciphertexts for it are teeny and the encapsulation keys are prohibitively large. It would be trivial. The issue you bring up is not a problem with the framework being proposed or the submission discussed today.
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 6/17/26, 4:21 PM, "yang.zhijie@xxxxxxxxxx" <yang.zhijie@xxxxxxxxxx>
wrote: Hi Dan, Regarding to "compatibility issues", I think the group makes several comments on this points. during the call. I can provide an example for
this. If all the stuffs are defined as fields in PQC authentication frame(let's call them as PQC R1 authentication frame). You have to define PQC R2 authenticaiton frame once new field(s) added. That's the compatibility issues. While using current PQC parameter
element can well address such problem as you can add any new field(s) in this element in the future. 杨志杰10343608
Thanks
Best Regards
Jay Yang (杨志杰)
Original From: Harkins,Dan <daniel.harkins@xxxxxxx>
To: 杨志杰10343608;STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx
<STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx>; Date: 2026年06月18日
06:11 Subject: Re: [STDS-802-11-TGBT] 11-26/1163r2 Regarding “compatibility issues”, please state what they are. We do not need to worry about legacy devices as this is for PQC protocols and for forward compatibility I do not see what the issue is. What is “frame-by-frame design” and what issues are associated with it that affect 11-26/1163r2? 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 6/17/26, 12:44 PM, "Jay Yang" <yang.zhijie@xxxxxxxxxx> wrote: Hi Dan, Thank you for your efforts on this. I would like to understand the exact parsing issue if we design the PQC parameters as follows: Place the KEM Encapsulation key field and KEM
Ciphertext field immediately after the PQC Parameter element. |<-------------------------------PQC Parameter element-------------------------------à|
Octets: 1 1 1 1 1 variable variable variable The receiver parses it as follows:
1.
If the PQC element is not present, the KEM Encapsulation key and KEM ciphertext are also not present. The receiver does not need to decode the additional two fields if it cannot find the
PQC Parameter element based on the element PQC Parameter element's TLV information.
2.
If the PQC Parameter element is present, based on the indication in the
Content Presence field. For example, if the
Content Presence field indicates that the ML-KEM public key is included in the KEM Encapsulation
key field , the receiver will continue to decode the KEM Encapsulation key field after decoding the PQC Parameter element.
3.
If the PQC Parameter element is present, based on the indication in the
Content Presence field. For example, if the
Content Presence field indicates that the KEM Encapsulation key or KEM ciphertext are not present (e.g.,
Content Presence field equals 0 (No parameter present) ), the receiver will not decode the KEM Encapsulation key or
KEM ciphertext after finishing the decoding of the PQC Parameter element. Instead, it will continue to decode other elements based on the TLV information. If we proceed in this direction, we could address a number of comments (compatibility issues, frame-by-frame design issues, etc.) we received
during the call. Welcome to more insights from you and the group. 杨志杰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年06月18日
02:25 Subject: [STDS-802-11-TGBT] 11-26/1163r2 Po-kai, In the teleconference today you said that the changes I’m proposing in 11-26/1163r2 also require changes to the PQC Security Profile Number values but you didn’t say what they are. Can you explain what changes
my document is missing? Thanks. 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 |