Subject: [Lake] Updated issues

From: Göran Selander <[email-masked]>
Date: Fri, 6 Nov 2020 13:33:24 +0000

We also updated the Github issues:

https://github.com/lake-wg/edhoc/issues

It now includes all input known to us, and with specific questions that needs to be answered, summarized below.

We would appreciate additional feedback to progress the specification. Please provide your preferences, either in the issue tracker or by responding to this mail. Thanks!

  1.  Use of SHA-512 and MTI ciphersuite

We propose not to replace SHA-256 with SHA-512 in cipher suites 0/1. Any disagreement?

Which option for MTI cipher suite do you prefer:

  1.  Change to ECDSA-based
  2.  Keep EdDSA with SHA-512/accept that it may not be implemented
  3.  Define a new EdDSA-based cipher suite using SHA-256
     *   Do you think that would be deployed?

Related issues:

  *   Ciphersuites requiring multiple SHA (#2)
  *   Use of SHA-512 in constrained IoT (#21)
  *   Mandatory to implement cipher suite (#22)

  1.  Future-proofing EDHOC

Shall we specify the key exchange as a KEM? (#17)

Shall we replace HKDF with a more general extract-and-expand to allow KMAC? (#19)

  1.  Rekeying AEAD

Shall we solve rekeying of AEAD within EDHOC, or let the data protection protocol, e.g. OSCORE, handle it more efficiently?  (#20)

  1.  Agreement/negotiation of parameters/options

Are we happy with the assumptions on which parameters to negotiate and which are agreed beforehand?

Related issues:

  *   Agreement/negotiation of parameters/options (#23)
  *   Agreement of method (#11)

  1.  Verification of intended peer

Should the “subject name” in raw public keys be recommended or even mandatory? (#8)

  1.  Injective agreement

Should EDHOC introduce a fourth (optional) message?

Related issues:

  *   Optional message_4 for key confirmation (#18)
  *   Injective agreement issue (was: G_IY in session key material) (#10)

  1.  Resumption

Is there any need for a resumption mechanism in EDHOC? (#25)

  1.  Forward and backward secrecy

Is there a need for a more lightweight protocol component that provides both forward and backward secrecy or is it sufficient with PK-based ECDHE and PSK-FS? (#24)

We would like to discuss these at IETF 109.

Göran