[Emu] Re: Éric Vyncke's No Objection on draft-ietf-emu-bootstrapped-tls-08: (with COMMENT)

[Dan Harkins <[e-mail]>]

   Actually, let me correct the statement below. There is one comment we
did not address and would like to respectfully reject. That is Mike
Bishop's comment:

    Given that knowledge of the "public" key is being used as an
    identity proof on the network's part, it's inherently not public.
    Consider rephrasing throughout to use the term "asymmetric" since
    both keys are semi-secret, and using names other than public and
    private?


We felt that "asymmetric" didn't really make things clearer. While
*technically* it is correct that this "public key" needs to be kept
confidential, the keypair is still a public-private one and that
terminology is understood. We do feel that the confidential nature
of the bootstrapping key is adequately explained in the draft.
Hopefully Mike agrees.

   regards,

   Dan.

On 9/29/25 12:54 PM, Harkins, Dan wrote:
>
> 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)" <[e-mail]> 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 <[e-mail]>
> *Date: *Wednesday, 3 September 2025 at 19:30
> *To: *Eric Vyncke (evyncke) <[e-mail]>, The IESG <[e-mail]>
> *Cc: *[e-mail] 
> <[e-mail]>, [e-mail] 
> <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] 
> <[e-mail]>
> *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" <[e-mail]> 
> 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 [e-mail]
> To unsubscribe send an email [e-mail]

-- 
"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