When mentioning DTLS and referring to RFC 6347, refer also to RFC 9147
As expected, the draft focuses on the EDHOC forward message flow, as it better maps against the EST expected workflow and ensures to protect the identity of the EST client. That said, can the use of the EDHOC reverse message flow be explicitly ruled out altogether?
[Section 1]
s/secured HTTP/HTTP [RFC9110][RFC9112] and TLS [RFC8446]
s/which protects the application layer message/which protects messages at the application layer
s/multicast CoAP messages/CoAP group messages
[Section 1.1]
"The concept "Registrar" and its required trust relation with EST server as described in Section 5 of [RFC9148] is therefore redundant."
Do you really mean "redundant"? Isn't it actually "inapplicable"?
In the presence of end-to-end security through OSCORE between the EST client and server, an hypothetical Registrar cannot perform its task as it does instead in RFC 9148. In this case instead, an intermediary would be simply limited to be a (cross-)proxy, on which indeed less trust needs to be put.
[Section 3.0]
"This specification replaces the DTLS handshake in EST-coaps with the lightweight authenticated key exchange protocol EDHOC [I-D.ietf-lake-edhoc]."
However, Section 1 talks about possible co-existence of OSCORE and DTLS, rather than of replacement. I think you mean "replaces or complements", like said in the previous sections.
"... and establish the OSCORE security context with which the EST payloads are protected."
This should be "... Security Context used to protect the messages conveying the EST payloads."
I suggest to split the second paragraph into two parts.
The first part ends with the current "The server MUST authenticate the client". The text can highlight that all those requirements are fulfilled when specifically using EDHOC.
The second part would say "The server MUST also provide relevant information to the CA for decision about issuing a certificate".
[Section 3.1]
"or a pointer such as a URI to the credential (e.g., x5t, see [I-D.ietf-cose-x509])"
This is mixing a type of credential reference with the abbreviated name of a different reference type. Either say a hash and then the parameter x5t, or a URI and then the parameter x5u.
[Section 3.3]
Section 1 says: "pre-shared OSCORE keying material would also be an option."
In such a case, is channel binding simply not achievable?
Or is it somehow possible as long as the OSCORE keying material was established through some sort of interactive protocol (e.g., like the OSCORE profile of ACE, see RFC 9203)?
"length equals the desired length of the edhoc-unique byte string"
I think it's better to specify a length of the byte string to use, unless otherwise indicated/advertised (e.g., in a used EDHOC application profile). RFC 9148 considers 32 bytes (see its Section 3).
[Section 3.4]
In scenarios using message_4, wouldn't it make sense to have the PKCS#10 request and response transported in an EAD_3 and EAD_4 item, respectively?
s/The certificate MAY be referenced/The client certificate MAY be referenced
s/response to the PKCS#10 request MAY be/response to the PKCS#10 request MAY specify
[Section 4.0]
"OSCORE [RFC8613] is used to protect the EST payloads."
This should be "OSCORE [RFC8613] is used to protect the messages conveying the EST payloads."
s/DTLS handshake is replaced with EDHOC/The DTLS handshake is complemented by or replaced with EDHOC
Then the following sentence can clarify that the architecture shown in Figure 6 does not consider the additional use of DTLS.
[Section 4.1]
In the shown example, the resource type should be rt="ace.est.sen" also in the link specified in the response.
Per Section 9 of RFC 8613, the "osc" attribute is optionally included in a link to specify that a resource has to be accessed with OSCORE. Should it remain optional here too?
Consider a setup where OSCORE and DTLS are combined. Especially when discovering EST resources on a non-default port number, the links to those resources would have URI scheme "coaps". Then, the absence of the "osc" attribute might wrongly suggest that the EST server is actually using EST-coaps.
Therefore, it might be worth mandating the use of the attribute "osc" in links to EST resources accessed as in this specification.
An alternative would be defining a new set of EST-OSCORE-related Resource Type values, such as "ace.est.osc.*".
[Section 4.2]
Regarding the response from /skc, is it possible to deviate from what is defined in RFC 9148 and not encrypt the private key? After all, end-to-end encryption of the whole EST payload is ensured by OSCORE.
If yes, that might open for a new Content-Format pair (284, 287), i.e., an unencrypted PKCS #8 private key together with a single certificate (not a PKCS#7 container).
[Section 4.3]
"EST-oscore uses the same CoAP Content-Format Options to transport EST requests and responses"
I think you mean: "EST-oscore uses the same CoAP Content-Format identifiers when transferring EST requests and responses".
The caption of Table 2 should be: "EST functions and the associated CoAP Content-Format identifiers"
I suppose your intention is for the EST client and server to support Content-Formats just like in RFC 9148, i.e.:
"Content-Format 281 MUST be supported by EST-coaps servers. Servers MAY also support Content-Format 287. It is up to the client to support only Content-Format 281, 287 or both."
I think it is good to have an explicit statement here too.
Like RFC 9148 does in its Table 3, it is good to also recap the Content-Format identifiers used for the different parts of the responses from /skg and /skc.
[Section 4.4]
The list of requirements is preceded by "It is RECOMMENDED that". However, isn't it a MUST for (at least) the CoAP options OSCORE and Uri-Path?
"The EST URLs based on https:// are translated to coap://, but with mandatory use of the CoAP OSCORE option."
The scheme "coap" is the translation target only if DTLS is not additionally used.
[Section 4.6]
"such as CBOR-encoded payloads ([I-D.ietf-cose-cbor-encoded-cert])"
Perhaps you meant to refer to RFC 8949?
s/reconstitution/reassembly
"this specification mandates the implementation of CoAP option Block1 and Block2 fragmentation mechanism [RFC7959]"
This is good, but it contradicts the text in Section 4.4 where the support of the CoAP option Block1 and Block2 is only RECOMMENDED.
[Section 4.8]
"The EST client prepares the PKCS #10 object and signs it by following the steps in Section 4 of [RFC6955]."
Even though Section 4 of RFC 6955 does use the words "The value to be signed", it is quite confusing to read "signs it" in this section, which correctly starts with saying that a Diffie-Hellman key pair cannot be used for signing operations.
I think that here it is worth saying "and computing a MAC" instead of "and signs it".
[Section 5]
"the EST payloads can be protected end-to-end"
This should be "the messages conveying the EST payloads can be protected end-to-end"
"Therefore the concept "Registrar" and its required trust relation with EST server as described in Section 5 of [RFC9148] is redundant."
See a previous comment about Section 1.1, on the word "redundant".
"The use of TLS and DTLS is optional."
Proposed rephrasing: "The additional use of TLS or DTLS is optional."
Section 1
--- s/of underlying transport/of the underlying transport
--- s/needs to be kept/need to be kept
--- s/between EST-oscore client/between the EST-oscore client
Section 1.1
--- s/replaced, or complemented, with OSCORE/replaced by, or complemented with, OSCORE
--- s/replaced, or complemented, with the lightweight/replaced by, or complemented with, the lightweight
--- s/relation with EST/relation with the EST
Section 3
--- s/initial enrollment the EST-oscore/initial enrollment, the EST-oscore
--- s/EST-oscore clients and/The EST-oscore clients and
Section 3.2
--- s/between EST client and/between the EST client and
Section 3.4
--- s/e.g. using/e.g., using
Section 4
--- s/Instead of DTLS record/Instead of the DTLS record
Section 4.2.1
--- s/e.g. using/e.g., using
Section 4.6
--- s/depending on application/depending on the application
--- s/than available frame size resulting/than the available frame size thus resulting
--- s/implementation of CoAP option/implementation of the CoAP option
--- s/fragmentation mechanism/to enforce the fragmentation mechanism defined in
Section 5
--- s/between EST client and EST server independent/between the EST client and EST server, irrespective
malishav
commented
1 year ago
[General]
Replace RFC 7049 with RFC 8949
Replace RFC 8152 with RFC 9052 and RFC 9053
When mentioning DTLS and referring to RFC 6347, refer also to RFC 9147
As expected, the draft focuses on the EDHOC forward message flow, as it better maps against the EST expected workflow and ensures to protect the identity of the EST client. That said, can the use of the EDHOC reverse message flow be explicitly ruled out altogether?
[Section 1]
s/secured HTTP/HTTP [RFC9110][RFC9112] and TLS [RFC8446]
s/which protects the application layer message/which protects messages at the application layer
s/multicast CoAP messages/CoAP group messages
[Section 1.1]
"The concept "Registrar" and its required trust relation with EST server as described in Section 5 of [RFC9148] is therefore redundant."
Do you really mean "redundant"? Isn't it actually "inapplicable"?
In the presence of end-to-end security through OSCORE between the EST client and server, an hypothetical Registrar cannot perform its task as it does instead in RFC 9148. In this case instead, an intermediary would be simply limited to be a (cross-)proxy, on which indeed less trust needs to be put.
[Section 3.0]
"This specification replaces the DTLS handshake in EST-coaps with the lightweight authenticated key exchange protocol EDHOC [I-D.ietf-lake-edhoc]."
However, Section 1 talks about possible co-existence of OSCORE and DTLS, rather than of replacement. I think you mean "replaces or complements", like said in the previous sections.
"... and establish the OSCORE security context with which the EST payloads are protected."
This should be "... Security Context used to protect the messages conveying the EST payloads."
I suggest to split the second paragraph into two parts.
The first part ends with the current "The server MUST authenticate the client". The text can highlight that all those requirements are fulfilled when specifically using EDHOC.
The second part would say "The server MUST also provide relevant information to the CA for decision about issuing a certificate".
[Section 3.1]
"or a pointer such as a URI to the credential (e.g., x5t, see [I-D.ietf-cose-x509])"
This is mixing a type of credential reference with the abbreviated name of a different reference type. Either say a hash and then the parameter x5t, or a URI and then the parameter x5u.
[Section 3.3]
Section 1 says: "pre-shared OSCORE keying material would also be an option."
In such a case, is channel binding simply not achievable?
Or is it somehow possible as long as the OSCORE keying material was established through some sort of interactive protocol (e.g., like the OSCORE profile of ACE, see RFC 9203)?
"length equals the desired length of the edhoc-unique byte string"
I think it's better to specify a length of the byte string to use, unless otherwise indicated/advertised (e.g., in a used EDHOC application profile). RFC 9148 considers 32 bytes (see its Section 3).
[Section 3.4]
In scenarios using message_4, wouldn't it make sense to have the PKCS#10 request and response transported in an EAD_3 and EAD_4 item, respectively?
s/The certificate MAY be referenced/The client certificate MAY be referenced
s/response to the PKCS#10 request MAY be/response to the PKCS#10 request MAY specify
[Section 4.0]
"OSCORE [RFC8613] is used to protect the EST payloads."
This should be "OSCORE [RFC8613] is used to protect the messages conveying the EST payloads."
s/DTLS handshake is replaced with EDHOC/The DTLS handshake is complemented by or replaced with EDHOC
Then the following sentence can clarify that the architecture shown in Figure 6 does not consider the additional use of DTLS.
[Section 4.1]
In the shown example, the resource type should be rt="ace.est.sen" also in the link specified in the response.
Per Section 9 of RFC 8613, the "osc" attribute is optionally included in a link to specify that a resource has to be accessed with OSCORE. Should it remain optional here too?
Consider a setup where OSCORE and DTLS are combined. Especially when discovering EST resources on a non-default port number, the links to those resources would have URI scheme "coaps". Then, the absence of the "osc" attribute might wrongly suggest that the EST server is actually using EST-coaps.
Therefore, it might be worth mandating the use of the attribute "osc" in links to EST resources accessed as in this specification.
An alternative would be defining a new set of EST-OSCORE-related Resource Type values, such as "ace.est.osc.*".
[Section 4.2]
Regarding the response from /skc, is it possible to deviate from what is defined in RFC 9148 and not encrypt the private key? After all, end-to-end encryption of the whole EST payload is ensured by OSCORE.
If yes, that might open for a new Content-Format pair (284, 287), i.e., an unencrypted PKCS #8 private key together with a single certificate (not a PKCS#7 container).
[Section 4.3]
"EST-oscore uses the same CoAP Content-Format Options to transport EST requests and responses"
I think you mean: "EST-oscore uses the same CoAP Content-Format identifiers when transferring EST requests and responses".
The caption of Table 2 should be: "EST functions and the associated CoAP Content-Format identifiers"
I suppose your intention is for the EST client and server to support Content-Formats just like in RFC 9148, i.e.:
"Content-Format 281 MUST be supported by EST-coaps servers. Servers MAY also support Content-Format 287. It is up to the client to support only Content-Format 281, 287 or both."
I think it is good to have an explicit statement here too.
Like RFC 9148 does in its Table 3, it is good to also recap the Content-Format identifiers used for the different parts of the responses from /skg and /skc.
[Section 4.4]
The list of requirements is preceded by "It is RECOMMENDED that". However, isn't it a MUST for (at least) the CoAP options OSCORE and Uri-Path?
"The EST URLs based on https:// are translated to coap://, but with mandatory use of the CoAP OSCORE option."
The scheme "coap" is the translation target only if DTLS is not additionally used.
[Section 4.6]
"such as CBOR-encoded payloads ([I-D.ietf-cose-cbor-encoded-cert])"
Perhaps you meant to refer to RFC 8949?
s/reconstitution/reassembly
"this specification mandates the implementation of CoAP option Block1 and Block2 fragmentation mechanism [RFC7959]"
This is good, but it contradicts the text in Section 4.4 where the support of the CoAP option Block1 and Block2 is only RECOMMENDED.
[Section 4.8]
"The EST client prepares the PKCS #10 object and signs it by following the steps in Section 4 of [RFC6955]."
Even though Section 4 of RFC 6955 does use the words "The value to be signed", it is quite confusing to read "signs it" in this section, which correctly starts with saying that a Diffie-Hellman key pair cannot be used for signing operations.
I think that here it is worth saying "and computing a MAC" instead of "and signs it".
[Section 5]
"the EST payloads can be protected end-to-end"
This should be "the messages conveying the EST payloads can be protected end-to-end"
"Therefore the concept "Registrar" and its required trust relation with EST server as described in Section 5 of [RFC9148] is redundant."
See a previous comment about Section 1.1, on the word "redundant".
"The use of TLS and DTLS is optional."
Proposed rephrasing: "The additional use of TLS or DTLS is optional."
If a secure association is needed between the EST Client and the CoAP-to-HTTP Proxy, this may alternatively and more conveniently rely on OSCORE as well, see https://datatracker.ietf.org/doc/draft-tiloca-core-oscore-capable-proxies/
[Nits]
Section 1 --- s/of underlying transport/of the underlying transport --- s/needs to be kept/need to be kept --- s/between EST-oscore client/between the EST-oscore client
Section 1.1 --- s/replaced, or complemented, with OSCORE/replaced by, or complemented with, OSCORE --- s/replaced, or complemented, with the lightweight/replaced by, or complemented with, the lightweight --- s/relation with EST/relation with the EST
Section 3 --- s/initial enrollment the EST-oscore/initial enrollment, the EST-oscore --- s/EST-oscore clients and/The EST-oscore clients and
Section 3.2 --- s/between EST client and/between the EST client and
Section 3.4 --- s/e.g. using/e.g., using
Section 4 --- s/Instead of DTLS record/Instead of the DTLS record
Section 4.2.1 --- s/e.g. using/e.g., using
Section 4.6 --- s/depending on application/depending on the application --- s/than available frame size resulting/than the available frame size thus resulting --- s/implementation of CoAP option/implementation of the CoAP option --- s/fragmentation mechanism/to enforce the fragmentation mechanism defined in
Section 5 --- s/between EST client and EST server independent/between the EST client and EST server, irrespective