[Lake] Re: WG Last Call: draft-ietf-lake-edhoc-psk-08 (Ends 2026-07-15)

[Marco Tiloca <[e-mail]>]

Hi all,

I support the publication of this document.

Please find below some comments on this latest version.

Best,
/Marco



[Section 1]

* It says:

  > The PSK method retains mutual authentication, ephemeral asymmetric key exchange, and identity protection properties of [RFC9528].

  Like clarified already in the next paragraph, the identity protection is against passive attackers. With respect to the Initiator, that's a difference from RFC 9528.

  You can have a phrasing more aligned to that used in the abstract, like:

  > The PSK method provides mutual authentication, ephemeral asymmetric key exchange, and identity protection.


[Section 2]

* Expand "CBOR", "COSE", "CWT", and "CCS". Then there's no need to expand "CWT" and "CCS" in the later Section 3.1.2.


[Section 3.1.3]

* It says:

  > ... These optimizations MUST NOT be applied in COSE header parameters or in other contexts where the full map structure is required. For example:
  >
  > - { 4 : h'0f' } encoded as h'0f' (CBOR byte string)
  >
  > - { 4 : 21 } encoded as 0x15 (CBOR integer)

  The COSE header parameter 'kid' can only have bstr as value type, so the second case in the example is not valid.

  Also, the example is indeed showing to keep the value of kid as-is, but also to use that value alone instead of the whole map.

  To give examples for when the optimizations are not used, and based on what is defined in Sections 3.5.3.2 and 3.3.2 of RFC 9528, shouldn't the text say the following?

  > - { 4 : h'0f' } is encoded as 0xa104410f, instead of 0x410f (CBOR encoding of the CBOR byte string h'0f')
  >
  > - { 4 : h'15' } is encoded as 0xa1044115, instead of 0x15 (CBOR encoding of the CBOR integer 21)


[Section 3.2]

* It says:

  > If the Diffie-Hellman procedure is replaced by a KEM, then G_X and G_Y are encapsulation key and ciphertext, respectively, and the shared secret G_XY is derived by the KEM, see [I-D.spm-lake-pqsuites].

  I suggest to rephrase as:

  > If the Diffie-Hellman procedure is replaced by a KEM (e.g., see [I-D.spm-lake-pqsuites]), then G_X and G_Y are encapsulation key and ciphertext, respectively, and the shared secret G_XY is derived by the KEM.

  This should make it possible to have [I-D.spm-lake-pqsuites] as an informative reference, instead of normative (anyway to be replaced with a reference to draft-ietf-lake-pqsuites)


[Section 5.3.1]

* Aligned with the wording in Section 5.2.1:

  OLD
  Message 3 is formatted as specified in Section 5.4.1 of [RFC9528].

  NEW
  Message 3 is formatted as specified in Section 5.4.1 of [RFC9528], except that CIPHERTEXT_3 is replaced by CIPHERTEXT_3A.


[Section 5.3.3]

* The first bullet point is:

  > Derive K_3 and IV_3 as defined in Section 4.

  However, it can't really be performed at first, since that requires PRK_4e3m, which requires PRK, which the Responder can't retrieve right from the start.

  Suggested reordering/rephrasing of steps:

  OLD
  > * Derive K_3 and IV_3 as defined in Section 4.
  >
  > * Parse the structure of message_3, which consists of a stream-cipher encrypted structure, CIPHERTEXT_3A = PLAINTEXT_3A XOR KEYSTREAM_3A, where PLAINTEXT_3A = ( ID_CRED_PSK, CIPHERTEXT_3B ) and CIPHERTEXT_3B is the inner AEAD-encrypted object.
  >
  > * Generate KEYSTREAM_3A with the same method the Initiator used.
  >
  > * Decrypt CIPHERTEXT_3A using binary XOR with KEYSTREAM_3A to recover PLAINTEXT_3A.
  >
  > * Use ID_CRED_PSK to identify the authentication credentials and retrieve PSK, CRED_I, and CRED_R.
  >
  > * AEAD-decrypt ...

  NEW
  > * Generate KEYSTREAM_3A with the same method the Initiator used.
  >
  > * Decrypt CIPHERTEXT_3A using binary XOR with KEYSTREAM_3A to recover PLAINTEXT_3A.
  > * Parse the structure of PLAINTEXT_3A = ( ID_CRED_PSK, CIPHERTEXT_3B ), where CIPHERTEXT_3B is the inner AEAD-encrypted object.
  >
  > * Use ID_CRED_PSK to identify the authentication credentials and retrieve PSK, CRED_I, and CRED_R.
  >
  > * Derive K_3 and IV_3 as defined in Section 4.
  >
  > * AEAD-decrypt ...

* It says:

  > AEAD algorithm from cipher suite

  Like in Section 5.3.2, it can better say:

  > EDHOC AEAD algorithm of the selected cipher suite


[Section 6]

* It says:

  > * hash_length is the output size of the EDHOC hash algorithm associated with the PSK.

  To fully understand this, one has to get to the later text in Section 9.5.

  In this section, I suggest to extend the quoted text as below:

  > * hash_length is the output size of the EDHOC hash algorithm associated with the PSK, i.e, the EDHOC hash algorithm of the selected cipher suite used in the EDHOC session in which the resumption PSK is established.

* The paragraph "A peer that has successfully ..." says that a resumption key MAY be generated.

  Later on, it is said:

  > The Initiator MAY delete rPSK_i after successfully verifying the fourth message. At that point, the Initiator can be certain that the Responder already has derived the next resumption key, rPSK_(i+1).

  However, the Initiator doesn't have such strong certainties. Isn't it as below instead?

  > The Initiator MAY delete rPSK_i after successfully verifying the fourth message. At that point, the Initiator can be certain that the Responder is able to derive the next resumption key rPSK_(i+1), if the Responder wants to.

  Similarly, the next paragraph (currently swapping "Initiator" and "Responder" in its last sentence) should say:

  > ... At that point, the Responder can be certain that the Initiator is able to derive the next resumption key rPSK_(i+1), if the Initiator wants to.

* It says:

  > Support for resumption MAY be indicated using means defined in [I-D.ietf-lake-app-profiles].

  I suggest to rephrase as:

  > Support for resumption can be indicated, for example, by using means defined in [I-D.ietf-lake-app-profiles].

  This should make it possible to have [I-D.ietf-lake-app-profiles] as an informative reference, instead of a (mutually!) normative one as it is the case now.



[Section 8]

* It says:

  > ... but key confirmation of the Responder can instead be provided by a subsequent OSCORE response to the Initiator.

  I think it's better to say:

  > ... but key confirmation of the Responder is provided by a subsequent OSCORE response to the Initiator.

  See the MUST in https://www.rfc-editor.org/info/rfc9668/#section-3.3.1-3

* It says:

  > In EDHOC-PSK, authentication of the Responder is provided by message_4. Nonetheless, the combined delivery, described in Section 3 of [RFC9668], can still be applied to EDHOC-PSK.

  Based on Sections 3.2 and 5.4, I think you mean:

  > In EDHOC-PSK, authentication of the Responder is provided by EDHOC message_4 or another fourth message. Hence, the combined delivery described in Section 3 of [RFC9668] can be applied to EDHOC-PSK.


[Section 9.5]

* It says:

  > If a PSK is combined with a different hash algorithm, the Responder MUST reject the ongoing EDHOC session.

  I guess you mean "different" from that in the selected cipher suite of the ongoing session.

  Suggested rephrasing:

  > The Responder MUST abort the ongoing EDHOC session, if the PSK retrieved through ID_CRED_PSK is combined with a hash algorithm different from the one in the selected cipher suite used in the session.


[Section 9.10]

* It says:

  > Other implementations may replace message_4 with a protected application message. In this case, the following requirement applies: The Initiator SHALL NOT persistently store PRK_out or derived application keys until it has successfully verified message_4 or a message protected with an exported application key (e.g., an OSCORE message).

  "In this case" seems to point to the previous sentence where message_4 is replaced by something else. However, what follows defines the requirement in general terms. What about:

  OLD
  In this case, the following requirement applies:

  NEW
  In general, the following requirement applies:


[Section 9.11]

* As per a previous comment about about Section 3.2, rephrasing text there should allow to have the reference [I-D.spm-lake-pqsuites] simply informative (also to be replaced with a reference to draft-ietf-lake-pqsuites)

* As per a previous comment about about Section 5.4, rephrasing text there should allow to have the reference [I-D.ietf-lake-app-profiles] simply informative.


[Nits]

* Section 3.1.1
--- s/facilitate retrieval/facilitate the retrieval
--- Make a hyperlink for "Section 3.5.3.2 of [RFC9528]"

* Section 5
--- s/that if any/that, if any

* Section 5.2.1
--- Make a hyperlink for "Section 5.3.1 of [RFC9528]"

* Section 5.2.2
--- s/C_R, EAD_2 are/C_R and EAD_2 are

* Section 5.3.2
--- s/of COSE_Encrypt0 object/of the COSE_Encrypt0 object
--- s/[RFC9528], with the EDHOC AEAD/[RFC9528], computed with the EDHOC AEAD

* Section 9.5
--- s/entropy, and MUST/entropy and MUST
--- s/the cipher suite selected in/the selected cipher suite used in

* Section 9.11
--- Make a hyperlink for "Section 9.2"


________________________________
From: Mališa Vučinić via Datatracker <[e-mail]>
Sent: Wednesday, July 1, 2026 5:32 PM
To: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: [Lake] WG Last Call: draft-ietf-lake-edhoc-psk-08 (Ends 2026-07-15)

This message starts a WG Last Call for:
draft-ietf-lake-edhoc-psk-08

This Working Group Last Call ends on 2026-07-15

Abstract:
   This document specifies a Pre-Shared Key (PSK) authentication method
   for the Ephemeral Diffie-Hellman Over COSE (EDHOC) Lightweight
   Authenticated Key Exchange (LAKE) protocol.  The PSK method provides
   mutual authentication, ephemeral key exchange, identity protection,
   and quantum resistance while incurring lower computational costs than
   the public-key authentication methods specified for EDHOC.  It is
   suited for systems where nodes share a PSK provided out-of-band
   (external PSK) and enables efficient session resumption with less
   computational overhead when the PSK is provided from a previous EDHOC
   session (resumption PSK).  This document details the PSK message
   flow, key derivation changes, message formatting, processing, and
   security considerations.

File can be retrieved from:

Please review and indicate your support or objection to proceed with the
publication of this document by replying to this email keeping [e-mail]
in copy. Objections should be explained and suggestions to resolve them are
highly appreciated.

Authors, and WG participants in general, are reminded of the Intellectual
Property Rights (IPR) disclosure obligations described in BCP 79 [1].
Appropriate IPR disclosures required for full conformance with the provisions
of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
Sanctions available for application to violators of IETF IPR Policy can be
found at [3].

Thank you.

[1] https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fbcp78%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cf2683847d11d4139c21908ded7862b2a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639185168452226195%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=P5y%2BRlx6oza8PwAHKl4n%2F33bMcx48mbQ9101bO8qAO4%3D&reserved=0<https://datatracker.ietf.org/doc/bcp78/>
[2] https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fbcp79%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cf2683847d11d4139c21908ded7862b2a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639185168452253807%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=pDyDwlH2mecnv9a0oTqbD6sbEgBQ%2F7x9s4F8yNGKD%2Bo%3D&reserved=0<https://datatracker.ietf.org/doc/bcp79/>
[3] https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Frfc6701%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cf2683847d11d4139c21908ded7862b2a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639185168452271336%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=arlEqlDhTIntKyT4iuUdhB4bjefczXnYQ%2F6mWHQx6SM%3D&reserved=0<https://datatracker.ietf.org/doc/rfc6701/>

The IETF datatracker status page for this Internet-Draft is:
https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lake-edhoc-psk%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cf2683847d11d4139c21908ded7862b2a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639185168452288781%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3XRUM4aGtCV9MOT4ow6ryc0%2FA4IhdDXNbAj5Qgif0gQ%3D&reserved=0<https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc-psk/>

There is also an HTML version available at:
https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-lake-edhoc-psk-08.html&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cf2683847d11d4139c21908ded7862b2a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639185168452305382%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Lo6wljdeFgcJY62hqhP1csw1wqqR8ecpHK6cEW5xhIU%3D&reserved=0<https://www.ietf.org/archive/id/draft-ietf-lake-edhoc-psk-08.html>

A diff from the previous version is available at:
https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-lake-edhoc-psk-08&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cf2683847d11d4139c21908ded7862b2a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639185168452321873%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=AnqRE2P%2BK1g94EZIx2Z1mV7I8WCPwraG1yYKL%2FLazDM%3D&reserved=0<https://author-tools.ietf.org/iddiff?url2=draft-ietf-lake-edhoc-psk-08>

--
Lake mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]