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)" <[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 [email protected]
--
"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
_______________________________________________
Emu mailing list -- [email protected]
To unsubscribe send an email to [email protected]
