Subject: [Lake] Review of draft-ietf-lake-edhoc-12

From: Marco Tiloca <[email-masked]>
Date: Wed, 3 Nov 2021 17:26:08 +0100

Hi all,

As promised, please find below my review of EDHOC v -12.

Best,
/Marco

=============

[Section 1.1]

* "This specification focuses on referencing instead of transporting 
credentials to reduce message overhead."

    It is possible to transport credentials both by reference and by 
value. What suggests the case of transport by reference to be the 
"focus"? Perhaps you mean that it is possible and preferable/recommended 
to transport credentials by reference?

* "future algorithms and credentials targeting IoT"

    This probably means "future algorithms and identity credential types 
targeting IoT".

* s/compromise of the long-term keys/compromise of the long-term 
identity keys

[Section 1.3]

* s/the number of bytes in EDHOC + CoAP can be/the EDHOC message size in 
bytes when transferred in CoAP can be

[Section 1.5]

* "and CDDL [RFC8610]. The Concise Data Definition Language (CDDL) is 
used to express CBOR data structures [RFC8949]"

    can be rephrased as:

    "and the Concise Data Definition Language (CDDL) [RFC8610], which is 
used to express CBOR data structures [RFC8949]"

[Section 2]

* "Verification of a common preferred cipher suite"

    Shouldn't this say: "Verification of a commonly supported cipher 
suite which is most preferred by the Initiator" ?

[Section 3.2]

* In Figure 4, the second and third column can rather have labels 
"Initiator Authentication Key" and "Responder Authentication Key".

[Section 3.3]

* "or in a subsequent application protocol"

    can be expanded as:

    "or of an application/security context in a subsequent application 
protocol"

[Section 3.4.1]

* "EDHOC transports that do not inherently provide correlation across 
all messages of an exchange"

    can be rephrased as:

    "Transports that do not inherently provide correlation across all 
EDHOC messages of an exchange"

[Section 3.5.1]

* "The EDHOC implementation or the application must enforce information 
about ..."

    can be rephrased as:

    "The EDHOC implementation or the application must take a decision on 
allowing or not a connection based on information about ..."

* s/if it is allowed to communicate with/if it is allowed to communicate 
with those

[Section 4.3]

* The context can for example be the empty (zero-length) sequence or a 
single CBOR byte string.

    Isn't the context supposed to be just a single CBOR byte string? See 
how it is defined in Section 4.2 when introducing Expand.

* s/where H() is the hash function/where H() is the EDHOC hash algorithm

[Section 5.1]

* s/a second time for EDHOC processing/a second time for EDHOC 
processing within the same ongoing session

[Section 5.2.3]

* "If an error message is sent, the session MUST be discontinued."

    Is this sentence actually required? Regardless sending an error 
message or not, the session is discontinued if any processing step 
fails, which is the reason for possibly sending an error message. Or are 
there situations where an error message is sent even if no processing 
step fails?

[Section 5.3.1]

* "G_Y, the ephemeral public key of the Responder, and ..."

    Just to avoid any risk to interpret this as the concatenation of 
three elements, I suggest to rephrase as:

    "G_Y (i.e., the ephemeral public key of the Responder) and ..."

[Section 5.3.2]

* s/H() is the hash function in/H() is the EDHOC hash algorithm in

* "is the 'signature' field of a COSE_Sign1 object as defined in Section 
4.4 of [I-D.ietf-cose-rfc8152bis-struct] using the signature algorithm ..."

    should be rephrased as:

    "is the 'signature' field of a COSE_Sign1 object as defined in 
Section 4.2 of [I-D.ietf-cose-rfc8152bis-struct], computed as defined in 
Section 4.4 of [I-D.ietf-cose-rfc8152bis-struct] by using the signature 
algorithm ..."

[Section 5.3.3]

* "If an error message is sent, the session MUST be discontinued."

    Is this sentence actually required? Regardless sending an error 
message or not, the session is discontinued if any processing step 
fails, which is the reason for possibly sending an error message. Or are 
there situations where an error message is sent even if no processing 
step fails?

[Section 5.4.2]

* s/H() is the hash function in/H() is the EDHOC hash algorithm in

* "is the 'signature' field of a COSE_Sign1 object as defined in Section 
4.4 of [I-D.ietf-cose-rfc8152bis-struct] using the signature algorithm ..."

    should be rephrased as:

    "is the 'signature' field of a COSE_Sign1 object as defined in 
Section 4.4 of [I-D.ietf-cose-rfc8152bis-struct], computed as defined in 
Section 4.4 of [I-D.ietf-cose-rfc8152bis-struct] by using the signature 
algorithm ..."

* s/as defined in Section 5.3 of [I-D.ietf-cose-rfc8152bis-struct]/as 
defined in Sections 5.2 and 5.3 of [I-D.ietf-cose-rfc8152bis-struct]

[Section 5.4.3]

* s/or the prepended C_I/or the prepended C_R

* s/as defined in Section 5.3 of [I-D.ietf-cose-rfc8152bis-struct]/as 
defined in Sections 5.2 and 5.3 of [I-D.ietf-cose-rfc8152bis-struct]

* "If an error message is sent, the session MUST be discontinued."

    Is this sentence actually required? Regardless sending an error 
message or not, the session is discontinued if any processing step 
fails, which is the reason for possibly sending an error message. Or are 
there situations where an error message is sent even if no processing 
step fails?

* s/no other party than the Responder/no other party than the Initiator

[Section 5.5]

* "In deployments where no protected application message is sent from 
the Responder to the Initiator, the Responder MUST send message_4."

    Consider to rephrase as:

    "In deployments where no protected application message is sent from 
the Responder to the Initiator, message_4 MUST be supported and the 
Responder MUST send message_4"

[Section 5.5.2]

* s/as defined in Section 5.3 of [I-D.ietf-cose-rfc8152bis-struct]/as 
defined in Sections 5.2 and 5.3 of [I-D.ietf-cose-rfc8152bis-struct]

[Section 5.5.3]

* s/as defined in Section 5.3 of [I-D.ietf-cose-rfc8152bis-struct]/as 
defined in Sections 5.2 and 5.3 of [I-D.ietf-cose-rfc8152bis-struct]

* "If an error message is sent, the session MUST be discontinued."

    Is this sentence actually required? Regardless sending an error 
message or not, the session is discontinued if any processing step 
fails, which is the reason for possibly sending an error message. Or are 
there situations where an error message is sent even if no processing 
step fails?

[Section 6]

* s/error SHALL be/An error message SHALL be

[Section 6.3]

* "Error code 2 MUST only be used in a response to message_1 ..."

    can be rephrased as:

    "Error code 2 MUST only be used when replying to message_1" , 
avoiding to use words like "request" and "response".

[Section 6.3.2]

* s/the Responder shall only accept message_1 if/the Responder SHALL 
accept message_1 only if

* The last two paragraph are not further comments on the examples, but 
are rather related to the cipher suite negotiation. I think they better 
fit as last paragraphs of Section 6.3.1.

[Section 8]

* "Compromise of PRK_4x3m leads to compromise of all exported keying 
material derived after the last invocation of the EDHOC-KeyUpdate function."

    I suggest to expand as follows:

    "Compromise of PRK_4x3m leads to compromise of all exported keying 
material derived from that key through the EDHOC-Exporter function. If 
the EDHOC-KeyUpdate function has been used to renew PRK_4x3m, the 
compromise is limited to the exported keying material derived from the 
PRK_4x3m installed after the last invocation of the EDHOC-KeyUpdate 
function."

[Section 8.6]

* The way the first paragraph starts is probably a remnant of when CoAP 
was still part of the document body rather than in Appendix A. Also, as 
later discussed in Appendix A.3, the Echo exchange is started by a CoAP 
server, regardless if it acts exactly as Responder. I suggest to 
rephrase the paragraph as follows.

    "EDHOC itself does not provide countermeasures against 
Denial-of-Service attacks. In particular, by sending a number of new or 
replayed message_1 an attacker may cause the Responder to allocate 
state, perform cryptographic operations, and amplify messages. To 
mitigate such attacks, an implementation SHOULD rely on lower layer 
mechanisms. For instance, when EDHOC is transferred  as an exchange of 
CoAP messages, the CoAP server can use the Echo option defined in 
[I-D.ietf-core-echo-request-tag], which forces the CoAP client to 
demonstrate its reachability at its apparent network address."

[Section 8.7]

* "... but intended to simplify ..."

    Since "security context" is mentioned in the following sentences, it 
is better to explicitly mention that they are referring to the 
application protocol and not to EDHOC anymore.

[Appendix A.3]

* "EDHOC message_2 or the EDHOC error message is sent from the server to 
the client in the payload of a 2.04 (Changed) response. EDHOC message_3 
or the EDHOC error message is sent from the client to the server's 
resource in the payload of a POST request. If needed, an EDHOC error 
message is sent from the server to the client in the payload of a 2.04 
(Changed) response."

    This text should also be a remnant of old versions. When using EDHOC 
for OSCORE, EDHOC error messages as CoAP responses are sent as error 
responses, see the first paragraph in Appendix A.3.1. The text above can 
rather, more generically, be:

    "The server sends to the client EDHOC message_2 in the payload of a 
2.04 (Changed) response, or an EDHOC error message in the payload of a 
response. If needed, the client sends to the server an EDHOC error 
message in the payload of a POST request. Otherwise, the client sends to 
the server EDHOC message_3 in the payload of a POST request. If needed, 
the server sends to the client an EDHOC error message in the payload of 
a response."

[Appendix A.3.1]

* The last sentence can be extended, to mention what additionally is 
defined in draft-ietf-core-oscore-edhoc, besides the EDHOC+OSCORE 
request. This includes especially: a deterministic and efficient 
conversion from OSCORE Sender/Recipient IDs to EDHOC connection 
identifiers; web-linking and target attributes for discovering of EDHOC 
resources.

[Nits]

* Three instances of "key material" should be "keying material" for 
consistency.

* Section 3.3.1, s/and sends in message_2/and sends it in message_2

* Section 3.3.2, s/and a EDHOC connection/and an EDHOC connection

* Section 3.6
--- s/pre-defined int label/pre-defined integer label
--- s/Implementation can either use/Implementations can either use

* Section 3.7, s/requires an 'y' parameter/requires a 'y' parameter

* Section 3.8, s/protected out of scope of EDHOC/whose protection is out 
of the scope of EDHOC

* Section 3.9
--- s/verifying cipher suite/verifying a cipher suite
--- s/know identity of Responder/know identity of the Responder
--- s/know identity of Initiator/know identity of the Initiator

* Section 4.3, s/same key kan be/same key can be

* Section 5.1, s/then process according to Section 6, else process 
as/then process it according to Section 6, else process it as

* Section 5.3.2, s/facilitate retrieval of/facilitate the retrieval of

* Section 5.4.2
--- s/facilitate retrieval of/facilitate the retrieval of
--- s/intialization vector/initialization vector
--- s/or derived application keys/or derive application keys

* Section 5.4.2, s/intialization vector/initialization vector

* Section 6.3.2, s/then Responder MUST discontinue/then the Responder 
MUST discontinue

* Section 8, s/protection is provided/protection are provided

* Section 8.2
--- s/and instead rely/and instead relies
--- s/the Responders identity/the Responder's identity
--- s/Requirement for how/Requirements for how

* Section 8.6
--- s/forces the initiator/forces the Initiator

* Section 9.6, s/an CWT Claims Set/a CWT Claims Set

* Section 9.14, s/is defined as/are defined as

* Appendix A.3, s/using resource directory/using a resource directory

* Appendix B, s/compatibily/compatibility

* Appendix C.1, s/dignostic/diagnostic

* Appendix E
--- s/which does not handle/which do not handle
--- s/with respect the current/with respect to the current

* Appendix F, s/for message 1/for message_1

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital System
Department: Computer Science
Unit: Cybersecurity

RISE Research Institutes of Sweden
https://www.ri.se

Phone: +46 (0)70 60 46 501
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)