[Lake] Comments on draft-ietf-lake-edhoc-psk-03

[Marco Tiloca <[e-mail]>]

Hi all,

Please see below a few comments on draft-ietf-lake-edhoc-psk. Hope it helps!

Best,
/Marco

---------------


[Section 4]

* The labels for K_3 and IV_3 can simply be 3 and 4, respectively, like 
in Figure 6 of RFC 9528.

   (After all, they refer exactly to the same key and IV defined in RFC 
9528, only derived using a different first argument for EDHOC_KDF)

   That also means that you can remove the last two entries of the table 
in Section 8.3.


[Section 5.3.2]

Appendix G of RFC 9528 is now referred twice, about the case where 
PLAINTEXT_3A is too long.

It should be sufficient to refer to it only in the innermost bullet 
point starting with "If the length of PLAINTEXT_3A exceeds ..."


[Section 7]

* On resumption_psk_length and id_cred_psk_length, I suggest to follow 
the same approach used by RFC 9528 for the size of the OSCORE Master 
Secret and Master Salt.

   In practice, here it can be about:

   * Defining a default size, which can be overridden if the two peers 
rely on different agreement means that are out of the scope of this 
document.

   * The default size for resumption_psk_length can be the size of the 
key of the EDHOC AEAD Algorithm used in the EDHOC Session, i.e., in the 
session at the end of which EDHOC_Exporter is invoked.

   * The default size for id_cred_psk_length can be 2 or 3 bytes, 
although I believe that 2 bytes would be good enough. Clearly, there is 
a tension between communication overhead and likelihood of collision of 
PSK identifiers.


* From offline discussions, I understand that the following is intended 
to be admitted. I think that the document should mention it explicitly.

   At the end of a successful EDHOC session, it is always possible to 
derive a resumption PSK, irrespective of the method used in the present 
session. In particular:

      - After a first established session that used a method based on 
asymmetric authentication (e.g., one of the original methods 0-3), an 
EDHOC session is run as based on a PSK resumption key.

      - After an EDHOC session based on a PSK resumption key, a new 
resumption key is derived for a follow-up resumption.


* For simplicity and interoperability, I suggest to specify the following:

   When successfully completing an EDHOC session (irrespective of the 
method used and of being a resumption or not), a peer that support 
PSK-based resumption MUST derive a new resumption key to use for the 
next resumption in the present "session series".


* The previous point raises the question "When is it safe for a peer to 
delete an old resumption key?" This can be handled as below.

   - For the Initiator of a session: when that session uses a PSK K_i as 
resumption key, then the Initiator deletes K_i after having successfully 
verified EDHOC message_4.

     That is, the Responder will have derived the next K_(i+1), which 
the Initiator can know for sure, upon receiving EDHOC message_4.

   - For the Responder of a session: when a session uses a PSK K_i as 
resumption key, then the Responder deletes K_(i-1), if any, after having 
successfully sent EDHOC message_4.

     That is, upon receiving EDHOC message_3, the Responder knows for 
sure that the other peer did derive K_i at the end of the previous 
session in the "session series", thus making it safe to delete the 
previous resumption key K_(i-1).


[Section 7.1]

* It says:

   > If a resumption PSK is offered with a weaker ciphersuite than its 
original exchange, the recipient MUST reject the connection attempt.

   How is a ciphersuite defined to be "weaker" than another one? If 
there is no clear, general answer that can be followed, I suggest to 
change this to be something like:

   > If a resumption PSK is offered with a ciphersuite different from 
the one used in the original EDHOC session, the recipient can fail the 
present EDHOC session according to application-specific policies.


[Section 8.3]

* The label for KEYSTREAM_3 should be 11 (not 12), as previously 
indicated in Figure 2 of Section 4.


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