| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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 |