Hi Marc,
See inline. I will point you to some github PRs for you to peek at before we release draft-09.
There are two inline comments where we would appreciate some mailer feedback.
Thanks for the review.
Owen
-----Original Message-----
From: Harkins, Dan <daniel.harkins@xxxxxxx>
Sent: Monday 14 July 2025 19:31
To: Marc Blanchet <marc.blanchet@xxxxxxxxxxx>; art@xxxxxxxx
Cc: draft-ietf-emu-bootstrapped-tls.all@xxxxxxxx; emu@xxxxxxxx; last-call@xxxxxxxx
Subject: Re: draft-ietf-emu-bootstrapped-tls-08 ietf last call Artart review
Hi Marc,
Thank you very much for your detailed review. I will discuss your comments with my co-author and we will produce a new version to address them (and others we will get in the LC).
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 7/12/25, 2:21 PM, "Marc Blanchet via Datatracker" <noreply@xxxxxxxx> wrote:
Document: draft-ietf-emu-bootstrapped-tls
Title: Bootstrapped TLS Authentication with Proof of Knowledge (TLS-POK)
Reviewer: Marc Blanchet
Review result: Ready with Nits
Hello,
I've been asked to provide a review of draft-ietf-emu-bootstrapped-tls
From the ART directorate. I'm no security expert. During that review,
I did not follow the references, nor verified the test vectors.
---------------------------
---------------------------
Substantive comments
- I'm no security expert, so the following comment may be irrelevant.
Section 3.1 says to use SHA-256 hash algo: "of the BSK public key using
[RFC5869] with the SHA-256 hash algorithm
[sha2]" ...
I did not see a way to specify another hash algorithm
for crypto algorithm agility. It may not be relevant here,
But should the hash algorithm be specified somewhere so that
It could be replaced another one later. Or maybe I missed it.
Just asking.
[ofriel] Dan and I went back and forth on this one. We came up with 3 different options here:
1. Always use SHA256
2. Use a SHA length that depends on the BSK prime key length
3. Use a SHA length that matches the target_kdf"
For simplicity we went with 1, but maybe we should have gone with 2. We are open to suggestions from the mailer.
- Figure 1 handshake description contains the last line as "Application Data".
{Finished} -------->
[Application Data] <-------> [Application Data]
Maybe it is obvious for people in the field, but I thought from reading that
after the authentication handshake, nothing else will happen with the server
and the client as the client now has access to the network. Therefore, I'm not
sure what would be the application data between the client and server after
the handshake. Maybe it is obvious. If it is not, then maybe either remove
or explain a bit more what that application data is, since it is not defined
or referenced anywhere else in the draft.
[ofriel] Updated in https://github.com/upros/tls-pok/pull/24
- again, I'm no security expert, so the following comment may be irrelevant.
In section 7. Security Considerations, I was expecting (and even within the
draft Itself) some discussion on DOS on the server by sending a lot of queries
by one or Many devices on the network. Should rate-limiting be used, and if
yes, what is the Right values, and maybe by device identified by their mac
addresss?
[ofriel] Again, I'd look for some guidance from the mailer here. There are no statements made about DOS protection in any of RFC3748, RFC5216 or RFC9190. So Dan and I decided to follow the precedence of those 3 EAP RFCs and not include any specific statements about DOS. Should there be errata raised against those RFCs? Should we add something about DOS to our draft?
Moreover, I was expecting some discussion or recommendation that the device
manufacturers should not use the same keypair for all (or more than one)
device. That may look obvious to a security person, but given manufacturing
context, it creates more work, so costs, so unwillingness to have specific
keypairs for each device.
[ofriel] Updated in https://github.com/upros/tls-pok/pull/24
---------------------------
---------------------------
English/nits/improvements
[ofriel] The majority of these nits have been addressed in https://github.com/upros/tls-pok/pull/22. There were some suggestions where we believe the existing text is better.
caveat: English is not my first language,
so maybe some comments related to language are actually not right.
- general comment: there is a bit of repetition about the general
description of the mechanism in too many sections (abstract, intro, section 2,
... Some could be cut to make the draft smaller and to the point.
- "knows the private key. The mechanism leverages existing DPP and TLS"
s/knows/has|owns|possesses/ ?
In my book, knows does not mean it has it.
- "On-boarding of devices with no, or limited, user interface can be
s/On-boarding of devices/On-boarding devices/
- "difficult. Typically, a credential is needed to access the network,"
I find "Typically" here too strong. At least, that is not my personal
Experience in the context of this draft (aka EAP/...).
S/Typically/Sometimes/
- "Thus, the intention is that DPP is the
RECOMMENDED mechanism for bootstrapping against Wi-Fi networks, and
TLS-POK is the RECOMMENDED mechanism for bootstrapping against wired
networks."
s/.../Thus, DPP SHOULD be used for bootstrapping against Wi-Fi networks, and
TLS-POK SHOULD be used for bootstrapping against wired
networks
- "The following terminology is used throughout this document."
Suggestion: add "NAI" as it is not expanded but used later.
- "into a Certification Authority to allow them to authenticate using"
s/into/with/ ?
- "This document defines a boostrapping mechanism that results in a"
S/boostrapping mechanism that results/booTstrapping mechanism resulting/
- "subsequent network access. Therefore, an EAP method that supports"
S/that supports/supporting the/
- "used with TEAP, including defining a suitable NAI."
Either expand here (on first use) or put it in the terminology section,
As suggested above.
- "If future EAP methods are defined that support certificate"
s/that support/supporting/
- "provisioning, then TLS-POK could potentially be used with those"
s/could potentially be used/may be used/
- "The mechanism for on-boarding of devices defined in this document"
s/on-boarding of devices/device on-boarding/
- "The definition of the BSK public key aligns with that given in [DPP].
s/that given in//
- "A performance versus storage tradeoff a server can choose is to
precompute the identity of every bootstrapped key with every hash"
I find this sentence a bit difficult to parse. It took me to repeat
it two times until I got it.
Maybe: s/.../A server can choose a tradeoff between performance and storage
by precomputing the .../
- "algorithm that it uses in TLS and use that to quickly lookup the"
s/that is uses in/used/
s/use that to quickly/use it/
- "handshake with an alert. If the server found the matching BSK public"
s/found/finds/
- "ServerHello and verified the TLS key schedule. The PSK proof has
completed at this stage,"
a/has completed/is completed/
- "When the server processes the client's Certificate it MUST ensure"
s/Certificate/Certificate,/
- "An attack on the bootstrapping method which substitutes the public
key of a corrupted device for the public key of an honest device can
result in the TLS sever on-boarding and trusting the corrupted
device."
Is "corrupted" the right word here? Corrupted means to me that the device
Internal filesystem is broken for example.
S/corrupted/tampered/?
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
