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

[Mališa Vučinić <[e-mail]>]

Hi Marco,

Thanks a million for this review. In response, we have created a Pull Request at [1] which integrates the changes to non-controversial points. I respond inline for each point, whether it has been addressed or the planned action to take. My comments are encapsulated within [MV] … [/MV] tags. 

Mališa

[1] https://github.com/EricssonResearch/EST-OSCORE/pull/8

> On Apr 29, 2023, at 12:04, Marco Tiloca <marco.tiloca=[e-mail]> wrote:
> 
> Hello ACE,
> 
> Please see below some comments on this document.
> 
> Best,
> /Marco
> 
> 
> [General]
> 
> * Replace RFC 7049 with RFC 8949

[MV] Fixed in https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/1947e005ca371cae08e80cf565ee18fba6809e4f [/MV]

> * Replace RFC 8152 with RFC 9052 and RFC 9053

[MV] Fixed in https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/519217505b23a6732ec33e85a9c789274fbcb006 [/MV]

> * When mentioning DTLS and referring to RFC 6347, refer also to RFC 9147

[MV] Fixed in https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/7789963a069e2be7311274e71f6653123ff87102 [/MV]
> 
> * 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?

[MV] As discussed in the meeting, the proposed action here is to add an explicit statement in Section 3 (Authentication) that the EST client MUST play the role of the EDHOC initiator. [/MV]


> [Section 1]
> 
> * s/secured HTTP/HTTP [RFC9110][RFC9112] and TLS [RFC8446]

[MV] Fixed in https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/a753faf2c9d44e8289cb186c68cc1a5879db3806 [/MV]

> * s/which protects the application layer message/which protects messages at the application layer
> 
> * s/multicast CoAP messages/CoAP group messages

[MV] Fixed in https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/5e021fd279c408a15f528de1244b084ff0506efe [/MV]
> 
> 
> [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"?


[MV] Replaced “redundant” with “not applicable” in https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/844d764ad07f1610fdd1b3b3518185e442be0c96 [/MV]


>    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.

[MV] 

Agreed: I believe that your statement is covered by the precedeing sentence in the section on “Operational Differences with EST-coaps”, which states:

"The EST payloads protected by OSCORE can be proxied between constrained networks supporting CoAP/CoAPs and non-constrained networks supporting HTTP/HTTPs with a CoAP-HTTP proxy protection without any security processing in the proxy (see {{proxying}}). "

[/MV] 

> [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".


[MV] The comments above are addressed in https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/49551af2d3142b5fb139852760548e8a4eb96d77 [/MV]

> [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.

[MV] We fixed this by replacing the example notion of x5t with x5u in https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/e4033cc7d644f38ced164bf4b58a08a1e7a6dc8e [/MV]


> [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)?


[MV] As discussed in the meeting, the proposed action here is to explicitly specify that EDHOC-Exporter-based channel binding is applicable only to cases where EDHOC is executed prior to enrollment and to state that the channel binding is not supported when pre-shared OSCORE context is used. [/MV]

> 
> * "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).

[MV] Yes, agreed. Similar to RFC 9148, we now specify the length of 32 bytes for edhoc-unique value. This is committed in https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/4fe0527f0ace8c3bd491fbac895164e225ee72a3
[/MV]


> [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?

[MV] As discussed in the meeting, the reason for not transporting PKCS objects within EAD fields of EDHOC is that we also consider re-enrollment where EDHOC is not necessarily executed. Therefore, proposed action is to informatively mention that not using EAD is intentional. [/MV]


> * 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.


[MV] The comments above were addressed in https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/69aadd5515277f82256e6ee1059018fb2c1ecc65 [/MV]

> [Section 4.1]
> 
> * In the shown example, the resource type should be rt="ace.est.sen" also in the link specified in the response.

[MV] This is fixed in https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/e03c708c36e92a70ecd322b3fe5b04d8e4014096 [/MV]


> * 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.*".

[MV] As discussed in the meeting, the proposed action here is to mandate the use of the attribute “osc” in links to EST resources. [/MV]

> [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).

[MV] As agreed in the meeting, we will specify that the response /skc can be PKCS #8 private key because OSCORE is used, and also specify the new Context-Format pair. [/MV]

> [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"

[MV] Fixed in https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/78f07ac2885e2b865647377924cd3566a789181c [/MV]

> 
> * 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.

[MV] As agreed in the meeting, we will specify explicitly Content-Format support and add a Table similar to RFC 9148 Table 3. [/MV]


> [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?

[MV] 
As discussed in the meeting, the action here is to avoid the use of normative keywords and rephrase to informatively discuss what is expected to be supported. This is now done in  https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/455ef9f7399619eaa9abfbb35f97864e69b88e72

[/MV]

> * "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.

[MV] As agreed in the meeting, we will explicitly mention that if DTLS is used, scheme is “coaps”. [/MV]

> [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

[MV] Comments above fixed in https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/e83c809ce105b50e6f7be1a1b13def7ceb9840e2 [/MV]
> 
> * "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.

[MV] As discussed in the meeting, we will replace this text with requirements similar to Section 4.6 of RFC 9148 on Block1 and Block2. [/MV]

> [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".

[MV] Fixed in https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/e83c809ce105b50e6f7be1a1b13def7ceb9840e2 [/MV]

> 
> 
> [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."

[MV] Comments above are fixed in https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/63d491225c85f5582e31d3de3df0ba4b865eb724 [/MV]
> 
> * 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/

[MV] As discussed in the meeting, the proposed action here is to informatively reference draft-tiloca-core-oscore-capable-proxies as a way to establish a secure association between the EST client and CoAP-to-HTTP proxy. [/MV]

> 
> [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

[MV] Nits above were fixed in https://github.com/EricssonResearch/EST-OSCORE/pull/8/commits/8337d01576f42e8ac17f267283690e550a347aeb [/MV]


> -- 
> 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 <https://www.ri.se/><OpenPGP_0xEE2664B40E58DA43.asc>_______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace