> Le 27 août 2025 à 16:42, Owen Friel (ofriel) <ofriel@xxxxxxxxx> a écrit :
>
> 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.
Again, I'm no security expert, so I'll let you/wg decide what is best.
Regards, Marc.
>
> 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
