Re: [Emu] draft-ietf-emu-bootstrapped-tls
Thanks Hannes for the detailed review, yes fully agree the language can be
cleaned up in the draft,
I'll get a draft-ietf-emu-bootstrapped-tls-03 out before the next meeting.
Cheers,
Owen
-Original Message-
From: Hannes Tschofenig
Sent: Tuesday 4 April 2023 15:51
To: Dan Harkins ; emu ; Owen Friel (ofriel)
Subject: Re: [Emu] draft-ietf-emu-bootstrapped-tls
Hi Owen, Hi Dan,
thanks for the response and for the clarification.
Here is my proposal for improving the wording of the document.
First, there is a little bit of inconsistency in the terminology.
The Bootstrap Key (BSK) is defined as the public and private key pair.
In Section 2 you use the term "Bootstrap Key Pair" to refer to the public and
the private key.
Here is my proposal:
FROM:
"
2. Bootstrap Key Pair
The mechanism for on-boarding of devices defined in this document relies on
bootstrap key pairs. A client device has an associated elliptic curve (EC)
bootstrap key pair (BSK).
"
TO:
"
2. Bootstrap Key
The mechanism for on-boarding of devices defined in this document relies on the
use of an elliptic curve (EC) bootstrap key (BSK).
"
Later an abbreviation for the BSK is used, namely BSKEY. I changed it for
improved readability, as you can see below.
Section 2 defines the format of the BSK quite loosely as:
"
If the BSK
public key, specifically the ASN.1 SEQUENCE SubjectPublicKeyInfo from
[RFC5280], can be shared in a trustworthy manner with a TLS server, a
form of "origin entity authentication" (the step from which all
subsequent authentication proceeds) can be obtained.
"
Later, in Section 3, the encoding is phrased more directly as:
"
As the BSK is an ASN.1 SEQUENCE SubjectPublicKeyInfo, the
client presents a raw public key certificate as specified in Using
Raw Public Keys in TLS and DTLS [RFC7250].
"
I would therefore suggest to use the following wording in Section 2:
FROM:
"
If the BSK
public key, specifically the ASN.1 SEQUENCE SubjectPublicKeyInfo from
[RFC5280], can be shared in a trustworthy manner with a TLS server, a
form of "origin entity authentication" (the step from which all
subsequent authentication proceeds) can be obtained.
"
TO:
"
The BSK public key MUST be encoded as the ASN.1 SEQUENCE
SubjectPublicKeyInfo from
[RFC5280] and if it can be shared in a trustworthy manner with a TLS
server, a
form of "origin entity authentication" (the step from which all
subsequent authentication proceeds) can be obtained.
"
Regarding "origin entity authentication" I believe the correct wording is
actually "entity authentication", if I consult the Handbook of Applied
Cryptography (see https://cacr.uwaterloo.ca/hac/about/chap10.pdf).
My confusion was mainly about the text in Section 3. Here is some new wording.
Note that I omitted the ImportedIdentity,
which I consider redundant since the epskid will, in form of the External
Identity, become part of the ImportedIdentity of the
PSK importer interface.
FROM:
"
3. Bootstrapping in TLS 1.3
Bootstrapping in TLS 1.3 leverages Certificate-Based Authentication
with an External Pre-Shared Key [RFC8773]. The External PSK (EPSK)
is derived from the BSK public key, and the EPSK is imported using
[RFC9258]. This BSK MUST be from a cryptosystem suitable for doing
ECDSA. As the BSK is an ASN.1 SEQUENCE SubjectPublicKeyInfo, the
client presents a raw public key certificate as specified in Using
Raw Public Keys in TLS and DTLS [RFC7250].
The TLS PSK handshake gives the client proof that the server knows
the BSK public key. Certificate based authentication of the client
by the server is carried out using the BSK, giving the server proof
that the client knows the BSK private key. This satisfies the proof
of ownership requirements outlined in Section 1.
3.1. External PSK Derivation
An [RFC9258] EPSK is made up of the tuple of (Base Key, External
Identity, Hash). The EPSK is derived from the BSK public key using
[RFC5869] with the hash algorithm from the ciphersuite:
epsk = HKDF-Expand(HKDF-Extract(<>, bskey),
"tls13-imported-bsk", L)
epskid = HKDF-Expand(HKDF-Extract(<>, bskey),
"tls13-bspsk-identity", L)
where:
- epsk is the EPSK Base Key
- epskid is the EPSK External Identity
- <> is a NULL salt
- bskey is the DER-encoded ASN.1 subjectPublicKeyInfo
representation of the BSK public key
- L is the length of the digest of the underlying hash
algorithm
The [RFC9258] ImportedIdentity structure is defined as:
struct {
opaque external_identity<1...2^16-1>;
opaque context<0..2^16-1>;
uint16 target_protocol;
ui
Re: [Emu] draft-ietf-emu-bootstrapped-tls
Hi Owen, Hi Dan,
thanks for the response and for the clarification.
Here is my proposal for improving the wording of the document.
First, there is a little bit of inconsistency in the terminology.
The Bootstrap Key (BSK) is defined as the public and private key pair.
In Section 2 you use the term "Bootstrap Key Pair" to refer to the
public and the private key.
Here is my proposal:
FROM:
"
2. Bootstrap Key Pair
The mechanism for on-boarding of devices defined in this document relies
on bootstrap key pairs. A client device has an associated elliptic
curve (EC) bootstrap key pair (BSK).
"
TO:
"
2. Bootstrap Key
The mechanism for on-boarding of devices defined in this document relies
on the use of an elliptic curve (EC) bootstrap key (BSK).
"
Later an abbreviation for the BSK is used, namely BSKEY. I changed it
for improved readability, as you can see below.
Section 2 defines the format of the BSK quite loosely as:
"
If the BSK
public key, specifically the ASN.1 SEQUENCE SubjectPublicKeyInfo from
[RFC5280], can be shared in a trustworthy manner with a TLS server, a
form of "origin entity authentication" (the step from which all
subsequent authentication proceeds) can be obtained.
"
Later, in Section 3, the encoding is phrased more directly as:
"
As the BSK is an ASN.1 SEQUENCE SubjectPublicKeyInfo, the
client presents a raw public key certificate as specified in Using
Raw Public Keys in TLS and DTLS [RFC7250].
"
I would therefore suggest to use the following wording in Section 2:
FROM:
"
If the BSK
public key, specifically the ASN.1 SEQUENCE SubjectPublicKeyInfo from
[RFC5280], can be shared in a trustworthy manner with a TLS server, a
form of "origin entity authentication" (the step from which all
subsequent authentication proceeds) can be obtained.
"
TO:
"
The BSK public key MUST be encoded as the ASN.1 SEQUENCE
SubjectPublicKeyInfo from
[RFC5280] and if it can be shared in a trustworthy manner with a TLS
server, a
form of "origin entity authentication" (the step from which all
subsequent authentication proceeds) can be obtained.
"
Regarding "origin entity authentication" I believe the correct wording
is actually
"entity authentication", if I consult the Handbook of Applied Cryptography
(see https://cacr.uwaterloo.ca/hac/about/chap10.pdf).
My confusion was mainly about the text in Section 3. Here is some new
wording. Note that I omitted the ImportedIdentity,
which I consider redundant since the epskid will, in form of the
External Identity, become part of the ImportedIdentity of the
PSK importer interface.
FROM:
"
3. Bootstrapping in TLS 1.3
Bootstrapping in TLS 1.3 leverages Certificate-Based Authentication
with an External Pre-Shared Key [RFC8773]. The External PSK (EPSK)
is derived from the BSK public key, and the EPSK is imported using
[RFC9258]. This BSK MUST be from a cryptosystem suitable for doing
ECDSA. As the BSK is an ASN.1 SEQUENCE SubjectPublicKeyInfo, the
client presents a raw public key certificate as specified in Using
Raw Public Keys in TLS and DTLS [RFC7250].
The TLS PSK handshake gives the client proof that the server knows
the BSK public key. Certificate based authentication of the client
by the server is carried out using the BSK, giving the server proof
that the client knows the BSK private key. This satisfies the proof
of ownership requirements outlined in Section 1.
3.1. External PSK Derivation
An [RFC9258] EPSK is made up of the tuple of (Base Key, External
Identity, Hash). The EPSK is derived from the BSK public key using
[RFC5869] with the hash algorithm from the ciphersuite:
epsk = HKDF-Expand(HKDF-Extract(<>, bskey),
"tls13-imported-bsk", L)
epskid = HKDF-Expand(HKDF-Extract(<>, bskey),
"tls13-bspsk-identity", L)
where:
- epsk is the EPSK Base Key
- epskid is the EPSK External Identity
- <> is a NULL salt
- bskey is the DER-encoded ASN.1 subjectPublicKeyInfo
representation of the BSK public key
- L is the length of the digest of the underlying hash
algorithm
The [RFC9258] ImportedIdentity structure is defined as:
struct {
opaque external_identity<1...2^16-1>;
opaque context<0..2^16-1>;
uint16 target_protocol;
uint16 target_kdf;
} ImportedIdentity;
and is created using the following values:
external_identity = epskid
context = "tls13-bsk"
target_protocol = TLS1.3(0x0304)
target_kdf = HKDF_SHA256(0x0001)
The EPSK and ImportedIdentity are used in the TLS handshake as
specified in [RFC9258].
A performance versus storage tradeoff a server can choose is to
precompute the identity of every bootstrapped key with every hash
algorithm that it uses in TLS and use that to quickly lookup the
bootstrap key and generate the PSK. Servers that choose not to
employ this optimization will
Re: [Emu] draft-ietf-emu-bootstrapped-tls
Yep thanks Hannes for the review. That optimizes the solution and removes the
unnecessary hashing of the BSK. Looking at the history, that BSK hashing was
there since a very early version of the draft before we incorporated RFC 9258,
and it never occurred to us to optimize that out once we started using RFC 9258.
We missed the IETF 116 draft cutoff date, but will get draft-03 out after the
meeting.
Thanks,
Owen
-Original Message-
From: Emu On Behalf Of Dan Harkins
Sent: Wednesday 22 March 2023 19:12
To: Hannes Tschofenig ; emu
Subject: Re: [Emu] draft-ietf-emu-bootstrapped-tls
Hi Hannes,
Sorry for the delay in responding
On 3/4/23 9:31 AM, Hannes Tschofenig wrote:
> Hi Owen, Hi Dan,
[snip]
> Here is what I have expected to see in the draft given that RFC 9258
> already defines the derivation of the epskx and the ipskx provided a
> few inputs. Here is what the RFC says:
>
>
> epskx = HKDF-Extract(0, epsk)
> ipskx = HKDF-Expand-Label(epskx, "derived psk",
> Hash(ImportedIdentity), L)
Yes, that takes the epsk and hashes it with the usage-specific goo to create
a binary blob with its entropy uniformly distributed across a fixed number of
bits.
>
> IMHO you only need to define
>
> (a) what the base epsk is, and
>
> (b) how to populate the ImportedIdentity structure.
>
>
> Regarding (a): You seem to be setting the base epsk (for the
> HKDF-Extract function above) to the DER-encoded ASN.1
> subjectPublicKeyInfo representation of the BSK public key (which is
> externally provided, for example by scanning a QR code).
>
> L is 32 since you seem to be mandating the use of HKDF-SHA256 as the KDF.
Yes, you're right. the espk can just be the DER-encoded
ASN.1 subjectPublicKeyInfo representation of the bootstrapping
key-- i.e. bskey.
> Regarding (b): RFC 9258 defines the ImportedIdentity structure as:
>
>
> struct {
> opaque external_identity<1...2^16-1>;
> opaque context<0..2^16-1>;
> uint16 target_protocol;
> uint16 target_kdf;
> } ImportedIdentity;
>
>
> You populate the ImportedIdentity structure based on the description
> in Section 3.1 as follows:
>
>
> - external_identity = epskid (which seems to be again the DER-encoded
> ASN.1 subjectPublicKeyInfo representation of the BSK public key)
> - context = "tls13-bsk"
> - target_protocol = TLS1.3(0x0304)
> - target_kdf = HKDF_SHA256(0x0001)
That would not work for the security model we're using which is based on the
Resurrecting Duckling [1]. It is assumed that a server who has knowledge of the
client's bskey is the legitimate "owner" and is therefore authorized to
provision/imprint it. So we can't send the bskey out naked in the ClientHello,
we have to send out something derived from the bskey.
>
> With this approach the text at the beginning of Section 3.1 is not
> needed.
Well, half of what's at the beginning of section 3.1 is still needed.
So what we're gonna do is change it to be:
epsk = bskey
epskid = HKDF-Expand(HKDF-Extract(<>, bskey), "tls13-bspsk-identity", L)
That way the raw DER-encoded ASN.1 will get hashed up by RFC 9258 to produce
the imported key and that key will be identified by something that is not the
raw DER-encoded ASN.1.
regards,
Dan.
[1] https://www.cl.cam.ac.uk/~fms27/duckling/
--
"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
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] draft-ietf-emu-bootstrapped-tls
Hi Hannes,
Sorry for the delay in responding
On 3/4/23 9:31 AM, Hannes Tschofenig wrote:
Hi Owen, Hi Dan,
[snip]
Here is what I have expected to see in the draft given that RFC 9258
already defines the derivation of the epskx and the ipskx provided a few
inputs. Here is what the RFC says:
epskx = HKDF-Extract(0, epsk)
ipskx = HKDF-Expand-Label(epskx, "derived psk",
Hash(ImportedIdentity), L)
Yes, that takes the epsk and hashes it with the usage-specific
goo to create a binary blob with its entropy uniformly distributed
across a fixed number of bits.
IMHO you only need to define
(a) what the base epsk is, and
(b) how to populate the ImportedIdentity structure.
Regarding (a): You seem to be setting the base epsk (for the
HKDF-Extract function above) to the DER-encoded ASN.1
subjectPublicKeyInfo representation of the BSK public key (which is
externally provided, for example by scanning a QR code).
L is 32 since you seem to be mandating the use of HKDF-SHA256 as the KDF.
Yes, you're right. the espk can just be the DER-encoded
ASN.1 subjectPublicKeyInfo representation of the bootstrapping
key-- i.e. bskey.
Regarding (b): RFC 9258 defines the ImportedIdentity structure as:
struct {
opaque external_identity<1...2^16-1>;
opaque context<0..2^16-1>;
uint16 target_protocol;
uint16 target_kdf;
} ImportedIdentity;
You populate the ImportedIdentity structure based on the description in
Section 3.1 as follows:
- external_identity = epskid (which seems to be again the DER-encoded
ASN.1 subjectPublicKeyInfo representation of the BSK public key)
- context = "tls13-bsk"
- target_protocol = TLS1.3(0x0304)
- target_kdf = HKDF_SHA256(0x0001)
That would not work for the security model we're using which is based
on the Resurrecting Duckling [1]. It is assumed that a server who has
knowledge of the client's bskey is the legitimate "owner" and is therefore
authorized to provision/imprint it. So we can't send the bskey out naked
in the ClientHello, we have to send out something derived from the bskey.
With this approach the text at the beginning of Section 3.1 is not
needed.
Well, half of what's at the beginning of section 3.1 is still needed.
So what we're gonna do is change it to be:
epsk = bskey
epskid = HKDF-Expand(HKDF-Extract(<>, bskey),
"tls13-bspsk-identity", L)
That way the raw DER-encoded ASN.1 will get hashed up by RFC 9258 to produce
the imported key and that key will be identified by something that is not
the raw DER-encoded ASN.1.
regards,
Dan.
[1] https://www.cl.cam.ac.uk/~fms27/duckling/
--
"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
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
[Emu] draft-ietf-emu-bootstrapped-tls
Hi Owen, Hi Dan,
Thanks for the recent -02 draft update, which addresses a few of my
remarks in my review
https://mailarchive.ietf.org/arch/msg/emu/VNCAFb4BTTOib27s1gIXUOEn_ng/
My question about the relationship with RFC 9258 was not answered and
hence I am giving it another try.
Here is what I have expected to see in the draft given that RFC 9258
already defines the derivation of the epskx and the ipskx provided a few
inputs. Here is what the RFC says:
epskx = HKDF-Extract(0, epsk)
ipskx = HKDF-Expand-Label(epskx, "derived psk",
Hash(ImportedIdentity), L)
IMHO you only need to define
(a) what the base epsk is, and
(b) how to populate the ImportedIdentity structure.
Regarding (a): You seem to be setting the base epsk (for the
HKDF-Extract function above) to the DER-encoded ASN.1
subjectPublicKeyInfo representation of the BSK public key (which is
externally provided, for example by scanning a QR code).
L is 32 since you seem to be mandating the use of HKDF-SHA256 as the KDF.
Regarding (b): RFC 9258 defines the ImportedIdentity structure as:
struct {
opaque external_identity<1...2^16-1>;
opaque context<0..2^16-1>;
uint16 target_protocol;
uint16 target_kdf;
} ImportedIdentity;
You populate the ImportedIdentity structure based on the description in
Section 3.1 as follows:
- external_identity = epskid (which seems to be again the DER-encoded
ASN.1 subjectPublicKeyInfo representation of the BSK public key)
- context = "tls13-bsk"
- target_protocol = TLS1.3(0x0304)
- target_kdf = HKDF_SHA256(0x0001)
With this approach the text at the beginning of Section 3.1 is not needed.
Tell me if I misreading the document and you are in fact adding another
layer of key derivation to produce the base epsk. If that's the case,
you might want to say why you are doing this.
Ciao
Hannes
PS: RFC 9258 also says that the ImportedIdentity.context MUST include a
channel binding. This appears to be missing. If you think it is
unnecessary, it might be worthwhile to state it.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
[Emu] draft-ietf-emu-bootstrapped-tls-01: Question about alignment with RFC 9258
Hi all, I have a question about the alignment between the text in Section 3.1 of draft-ietf-emu-bootstrapped-tls-01 and RFC 9258. RFC 9258 describes how to import external PSKs for use with TLS 1.3. It does so by defining a function with three inputs, namely an external identity, an EPSK, and an optional context. The output is then a derived epsk and an imported psk (ipsk). The identity of the ipsk is the serialized ImportedIdentity structure. Section 5.1 of RFC 9258 defines the functions as follows: epskx = HKDF-Extract(0, epsk) ipskx = HKDF-Expand-Label(epskx, "derived psk", Hash(ImportedIdentity), L) The epsk in RFC 9258 is defined as the a tuple of (Base Key, External Identity, Hash). I assume that the epsk parameter, which is input to the HKDF-Extract, is the private key. Now, coming to draft-ietf-emu-bootstrapped-tls-01. Here the derivations are defined as follows: epsk = HKDF-Expand(HKDF-Extract(<>, bskey), "tls13-imported-bsk", L) epskid = HKDF-Expand(HKDF-Extract(<>, bskey), "tls13-bspsk-identity", L) where: - epsk is the EPSK Base Key - epskid is the EPSK External Identity - <> is a NULL salt - bskey is the DER-encoded ASN.1 subjectPublicKeyInfo representation of the BSK public key - L is the length of the digest of the underlying hash algorithm Since the functions are different I am wondering whether the idea is to create another derivation before applying those inputs to the RFC 9258-defined functions. Is this the idea? Ciao Hannes PS: I noticed that in an earlier IETF presentation a point to a Github repo was provided. I looked at that code, which has now been reverted, and it did not match the content of the draft. Is there an implementation of this draft available somewhere? IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] draft-ietf-emu-bootstrapped-tls
Thanks, Owen. -Original Message- From: Owen Friel (ofriel) Sent: Friday, December 16, 2022 12:31 PM To: Hannes Tschofenig ; emu@ietf.org Subject: RE: draft-ietf-emu-bootstrapped-tls Thanks Hannes. These all make sense and are now all addressed in github and I will include in draft-02 And yes, the intention is that DPP is recommended for Wi-Fi as it also addresses the Wi-Fi SSID discovery problem. TLK-POK is recommended for wired. I have clarified this in the introduction. -Original Message- From: Emu On Behalf Of Hannes Tschofenig Sent: Tuesday 13 December 2022 10:14 To: emu@ietf.org Subject: [Emu] draft-ietf-emu-bootstrapped-tls Hi all, I have a simple question regarding draft-ietf-emu-bootstrapped-tls-01 Do you see the scope of this specification limited to the use for wired network access? In Section 2.1 you describe the story as "use DPP if the device bootstraps against a Wi-Fi network, or TLS-POK if the device bootstraps against a wired network." If that's the goal, I think it would be useful to move this text from Section 2.1 into the introduction. I was also wondering whether it would be better to change the title of the document from "Bootstrapped TLS Authentication" to something like "Bootstrapped TLS Authentication with Proof of Knowledge (TLS-POK)". Minor remarks: There is a reference to RFC 9528, which is marked as a broken reference. Most likely a typo and you mean RFC 9258 instead. You say: "Device on-boarding protocols such as the Device Provisioning Profile [DPP], also referred to as Wi-Fi Easy Connect, address this use case but they have drawbacks." Then, you only mention one drawback. Maybe you want to mention other drawbacks. The terminology section should contain the RFC 2119 boilerplate text. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] draft-ietf-emu-bootstrapped-tls
Thanks Hannes. These all make sense and are now all addressed in github and I will include in draft-02 And yes, the intention is that DPP is recommended for Wi-Fi as it also addresses the Wi-Fi SSID discovery problem. TLK-POK is recommended for wired. I have clarified this in the introduction. -Original Message- From: Emu On Behalf Of Hannes Tschofenig Sent: Tuesday 13 December 2022 10:14 To: emu@ietf.org Subject: [Emu] draft-ietf-emu-bootstrapped-tls Hi all, I have a simple question regarding draft-ietf-emu-bootstrapped-tls-01 Do you see the scope of this specification limited to the use for wired network access? In Section 2.1 you describe the story as "use DPP if the device bootstraps against a Wi-Fi network, or TLS-POK if the device bootstraps against a wired network." If that's the goal, I think it would be useful to move this text from Section 2.1 into the introduction. I was also wondering whether it would be better to change the title of the document from "Bootstrapped TLS Authentication" to something like "Bootstrapped TLS Authentication with Proof of Knowledge (TLS-POK)". Minor remarks: There is a reference to RFC 9528, which is marked as a broken reference. Most likely a typo and you mean RFC 9258 instead. You say: "Device on-boarding protocols such as the Device Provisioning Profile [DPP], also referred to as Wi-Fi Easy Connect, address this use case but they have drawbacks." Then, you only mention one drawback. Maybe you want to mention other drawbacks. The terminology section should contain the RFC 2119 boilerplate text. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] draft-ietf-emu-bootstrapped-tls
Hi all, I have a simple question regarding draft-ietf-emu-bootstrapped-tls-01 Do you see the scope of this specification limited to the use for wired network access? In Section 2.1 you describe the story as "use DPP if the device bootstraps against a Wi-Fi network, or TLS-POK if the device bootstraps against a wired network." If that's the goal, I think it would be useful to move this text from Section 2.1 into the introduction. I was also wondering whether it would be better to change the title of the document from "Bootstrapped TLS Authentication" to something like "Bootstrapped TLS Authentication with Proof of Knowledge (TLS-POK)". Minor remarks: There is a reference to RFC 9528, which is marked as a broken reference. Most likely a typo and you mean RFC 9258 instead. You say: "Device on-boarding protocols such as the Device Provisioning Profile [DPP], also referred to as Wi-Fi Easy Connect, address this use case but they have drawbacks." Then, you only mention one drawback. Maybe you want to mention other drawbacks. The terminology section should contain the RFC 2119 boilerplate text. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
