Eric, and other ADs, 802.15.4 would have the same discovery issues that 802.11 has. DPP solved that problem for 802.11 but without 802.15.4 doing something similar, it cannot directly use DPP or TLS-POK. I have modified the text to be more "wireless" and less "Wi-Fi" and hopefully that language will be inclusive of 802.15.4 in your mind without having to expressly bring in 802.15.4. We have also made a nod to PQC and noted that if/when DPP is updated to support a PQC crypto system that "this memo" can also be updated.
Anyway, I believe we have addressed all the DISCUSS comments. Owen will be publishing a new version the next time he sits down in front of a computer. Please take a look and let us know if we have addressed your comments to your satisfaction. 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 9/29/25, 5:19 AM, "Eric Vyncke (evyncke)" <[email protected]<mailto:[email protected]>> wrote: Hello Dan, Thanks for your patience waiting for my reply... About IETF vs. IEEE question (linked to Roman’s DISCUSS ballot), Roman’s point is about the use of normative language (and I agree with him) for non-IETF protocols, while my own COMMENT is not about normative language but more on why this IETF EAP protocol ‘extension’ cannot be used on the top on IEEE protocols such as 802.15.4, i.e., a sentence like “this protocol could also be used on non-wired technologies”. About PQC, your comment is reasonable, so, may I suggest to add this explanation/justification to the I-D ? I.e., just QR code size is not practicable to PQC/hybrid method. (now it makes me wonder how this could be fixed in the coming 10+ years) Regards -éric From: Harkins, Dan <[email protected]> Date: Wednesday, 3 September 2025 at 19:30 To: Eric Vyncke (evyncke) <[email protected]>, The IESG <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: Éric Vyncke's No Objection on draft-ietf-emu-bootstrapped-tls-08: (with COMMENT) Hi Eric, There are 2 comments here that I do not believe we have addressed, the others are in pull requests on github. And I'd like to see if we can do it in email and not have to edit the document. First, 802.15.4. DPP defines a bootstrapping mechanism for 802.11 (aka Wi-Fi) only, it won't work in a wired port where you plug in the ethernet cable and get an 802.1X authenticator saying, "who are you?". DPP addresses the Wi-Fi discovery issue using frames defined in 802.11, it does not address how to do zero touch on-boarding in 802.15.4, that is a problem for 802.15.4 to solve. But I am a little puzzled now in how to address this comment because Roman is objecting to us mentioning that DPP being RECOMMENDED for Wi-Fi since Wi-Fi is not an IETF specification and you are asking for us to comment on another protocol that is not an IETF specification. So I do not think it is possible to make both of you happy. Owen and I will propose some text to Roman in a subsequent email to address his comment (Mohamed has a similar one) and we hope that we can just call your 802.15.4 comment resolved with no change. Does that work for you? Second, hybrid PQC or RSA. The mandatory bootstrapping mechanism for DPP, and therefore for TLS-POK, is scanning a QR code in which a public key is embedded. Compressed ECDH public keys fit wonderfully. I've tried to generate an ML-KEM-512 QR code and it's not really usable. It's too big to be in a sticker on the backside of an IoT device but might be OK to be included in a device's bill of sale paperwork (ML-KEM-1024 is pretty much unusable). Hybrid makes it even bigger. And RSA is out of the question for a key of any decent size. The QR code is massive. Also, DPP does not define fragmentation/reassembly and we are not defining Yet Another Fragmentation Scheme For EAP (!!!) in TLS-POK and the authentication exchange in DPP cannot be done with RSA keys without fragmentation. There is a proposal to add PQC algorithms to DPP and once the bootstrapping and authentication issues with these massive keys is worked out and there is a PQC DPP, there will probably be a TLS-POK-bis. But as I mentioned to Deb, given the current factoring capabilities of PQ computers there's no rush, and given that DPP is not CNSA 2.0 there are no customers saying they won't buy existing DPP product after 2030. So I'm hoping we can resolve this comment as well with no change. Does that work for you? 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 8/28/25, 10:29 PM, "Éric Vyncke via Datatracker" <[email protected]> wrote: Éric Vyncke has entered the following ballot position for draft-ietf-emu-bootstrapped-tls-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NpxR!ilS7gxR9VbDmjQbrHBenJO-LIeb5aBKi0P5R-SATQr9z1D5heORJT0kCezgMfzYJXKpKOPT2PcmJGLvc$<https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NpxR!ilS7gxR9VbDmjQbrHBenJO-LIeb5aBKi0P5R-SATQr9z1D5heORJT0kCezgMfzYJXKpKOPT2PcmJGLvc$> for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-emu-bootstrapped-tls/__;!!NpxR!ilS7gxR9VbDmjQbrHBenJO-LIeb5aBKi0P5R-SATQr9z1D5heORJT0kCezgMfzYJXKpKOPT2PdjchrG3$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-emu-bootstrapped-tls/__;!!NpxR!ilS7gxR9VbDmjQbrHBenJO-LIeb5aBKi0P5R-SATQr9z1D5heORJT0kCezgMfzYJXKpKOPT2PdjchrG3$> ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-emu-bootstrapped-tls-08 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). Special thanks to Peter Yee for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## COMMENTS (non-blocking) ### Abstract Like Gorry, expanding the less-known DPP would be welcome. As this I-D is related to EAP, should the terms "EAP peer" and "EAP server" be used ? "Boostrap" or "on-boarding" for the title ? The latter is clearer IMHO. ### Section 1 `This poses a catch-22` is hard to understand for non-English speakers. Also later in the text. What about non-wired networks that are not Wi-Fi ? E.g., IEEE 802.15.4 ### Section 1.2 Is the usefulness of this document limited to EC only ? I.e., no plain RSA or PQC hybrid systems ? Who is the "we" in `which we refer to as`? The authors ? The WG ? The IETF ? Please refrain from using "we". I find the use of "network" in this section rather vague... possibly because could be a layer-2 switch or a BRAS or ... and further text uses "server" (e.g., in section 2), this is somehow confusing. Suggest using only one term and defining it in the terminology section. ### Section 2 Should there be an informative reference to `"entity authentication"`? ### Section 4 `Authenticator on an 802.1X-protected port` another term for "network" (see my related comment about section 1.2); suggest using the terminology section to establish that these terms are related or even identical. ## NITS (non-blocking / cosmetic) ### Use of SVG graphics To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-) ### Section 7 s/TLS sever on-boarding/TLS server on-boarding/ ? Suggest running a spell checker on the text.
_______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
