[Ace] Review of draft-ietf-ace-coap-est-oscore-00

[Marco Tiloca <[e-mail]>]

Hello ACE,

Please see below some comments on this document.

Best,
/Marco


[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


-- 
Marco Tiloca
Ph.D., Senior Researcher

Phone: [phone]

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se