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

[Elsa Lopez Perez <[e-mail]>]

Hi Erik!

Thanks for reviewing the document. I have acknowledge the comments and 
added them in the draft.

Regarding Section 3, I modified it as follows:

  * ID_CRED_PSK is a key identifier {{Section 3.1 of RFC8152}} formatted
    as a COSE header map containing header parameters that can be used
    to retrieve one or more pre-shared keys and associated information
    required for EDHOC processing.
  * The purpose of ID_CRED_PSK is to facilitate retrieval of the PSK and
    associated information required for EDHOC processing. While
    ID_CRED_PSK uses encoding and representation patterns from {{Section
    3.5.3.2 of RFC9528}}, it differs fundamentally in that it identifies
    a symmetric key rather than a public authentication key. A given
    ID_CRED_PSK value MAY correspond to more than one candidate PSK and
    associated information. In that case, all candidates associated with
    the value may need to be checked.

It might be better though to introduce directly a concept of PSK 
context? Not sure what can be more clear.

As for Section 7, regarding the last sentence on "Note that PSK 
authentication is not allowed on EAP-TLS", the point is that EAP-TLS 
requires certificate-based authentication, while EAP-EDHOC-PSK (renamed 
to EAP-EDHOC using PSK-based authentication), does allow the use of PSK.

BR,

Elsa


On 7/10/26 18:50, Erik Anderlind wrote:
> Hi all,
>
> I support the publication of this document.
>
> Please find below some comments on this latest version.
>
> Cheers
>   Erik
>
> Section 3.1.1:
>
> * Suggest add a reference to RFC8152 section 3.1 that defines a key 
> identifier and it’s properties
> kid: This parameter identifies one piece of data that can be used as 
> input to find the needed cryptographic key. The value of this 
> parameter can be matched against the 'kid' member in a COSE_Key 
> structure. Other methods of key distribution can define an equivalent 
> field to be matched. Applications MUST NOT assume that 'kid' values 
> are unique. There may be more than one key with the same 'kid' value, 
> so all of the keys associated with this 'kid' may need to be checked. 
> The internal structure of 'kid' values is not defined and cannot be 
> relied on by applications. Key identifier values are hints about which 
> key to use. This is not a security-critical field. For this reason, it 
> can be placed in the unprotected headers bucket.
> OLD>
> ID_CRED_PSK is a COSE header map containing header parameters that can 
> identify a pre-shared key.
>
> NEW>
> ID_CRED_PSK is a key identifier (RFC8152 section 3.1) formatted as a 
> COSE header map containing header parameters that can identify a 
> pre-shared key.
>
> OLD>
> The same PSK can be identified by different ID_CRED_PSK values in 
> different sessions, in particular when initiated by the other party.
>
> NEW>
> There may be more than one key with the same ID_CRED_PSK value, so all 
> of the keys associated with this value may need to be checked.
>
> * The ID_CRED_PSK is used to retrieve more than just a key. Might it 
> be useful to state it retrieves one or several candidate key 
> context(s), each consisting of {key value, ID_CRED_I, ID_CRED_R, EDHOC 
> Hash algorithm}?
> (In both of the above text proposals, would then suggest replace ‘key’ 
> with ‘key context’, perform similar substitutions elsewhere in 3.1.1
> and add a definition of key context.)
>
> * The last paragraph in section 3.1.1 is recommending ID_CRED_PSK be 
> either unique or stochastically generated. The required processing of 
> message 3 differs according to the chosen approach. I suggest spec 
> should adhere to the above COSE definition of a non-unique key 
> identifier and describe steps that need to be repeated for each 
> candidate key context. The paragraph starting with “It is RECOMMENDED 
> that ID_CRED_PSK …” would need to be adjusted accordingly.
>
> * Currently the text in 3.1.1 mentions the ‘kid’ but doesn’t require 
> it to be present. Might it be useful to state somewhere that the 
> application profile defines the COSE header map format(s) that must be 
> supported?
>
> Section 3.1.3:
>
> * Suggest remove third bullet, as it is an external system constraint 
> that can’t be guaranteed by an implementation:
>
> OLD>
>  * ID_CRED_PSK SHOULD uniquely identify the corresponding PSK to avoid 
> ambiguity. When ID_CRED_PSK contains a key identifier, care must be 
> taken to ensure that 'kid' is unique for the PSK.
> NEW>
> _
>
>
> Section 5.3.3:
>
> * Assuming the restructuring proposal from Marco is accepted, suggest 
> further clarify where reprocessing for each candidate key context is 
> necessary.  I am unsure whether EDHOC key hash algorithm should be 
> mentioned as a possible criteria to whittle down the set of candidate 
> keys.
>
> MARCO>
>>  * 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 …
>
> NEW>
> * Use ID_CRED_PSK to identify candidate authentication credentials and 
> retrieve corresponding PSK, CRED_I and CRED_R
>
> * Select first candidate
>
> * Derive K_3 and IV_3 as defined in Section 4.
>
> * AEAD-decrypt CIPHERTEXT_3B using:
>   (keep all the sub bullets as are)
>
> If AEAD verification fails, retry with a new candidate. If all 
> candidate authentication credential sets fail, this indicates a 
> processing problem or that the message was tampered with. If 
> verification succeeds with a candidate set, the Responder concludes ….
>
>
> Section 6:
>
> * Last paragraph before section 6.1 doesn’t reflect need to retain 
> CRED_X needed for key derivation. If a credential associated with a 
> resumption key expires, should retry either with external PSK or a 
> different METHOD.
>
> OLD>
>      When resumption PSKs are in use, implementations MAY retain
>      the credentials used for the original non-resumption authentication
>      (e.g., the external PSK, static DH keys, or certificates) alongside
>      the current resumption PSK to allow fallback if resumption fails. If
>      fallback authentication uses an external PSK, the Initiator selects
>      which PSK to present via ID_CRED_PSK. How long the original
>      authentication credentials are retained is determined by the
>     application profile or by the expiration time of the credential
>    (e.g., the exp claim in a CWT). Key lifetime and retention policy
>    are determined by the application profile.
>
> NEW>
> When resumption PSKs are in use, implementations MUST retain
> the ID_CRED_I, ID_CRED_R and EDHOC hash algorithm used for the original
> non-resumption authentication (e.g., the static DH public keys, or 
> certificates)
> and associate them with the current resumption PSK.
> Implementations MAY retain the external ID_CRED_PSK and associated PSK 
> to allow
> fallback if resumption fails. If fallback authentication uses an 
> external PSK, the Initiator
> selects which PSK to present via ID_CRED_PSK.  If a credential 
> associated with a
> resumption key expires, implementations SHOULD retry either with 
> external PSK
> or a different METHOD. How long the original authentication
> credentials are retained is determined by the application profile or 
> by the expiration time
> of the credential (e.g., the exp claim in a CWT). Key lifetime, 
> retention, and retry policy are
> determined by the application profile.
>
> Section 7:
>
> * The text mentions EAP-EDHOC and EAP-EDHOC-PSK. Are these the same 
> thing, or might the 2nd case better be expressed
>   as "EAP-EDHOC with an external PSK”?
>
> * EAP-TLS [RFC9190] describes use of PSK for resumption. Unclear what 
> the intent is of the last sentence in section 7.
>   If EAP-EDHOC is a different EAP method than EAP-PSK and EAP-TLS, 
> isn’t it already clear they are not substitutions?
>
>
>> On Jul 9, 2026, at 3:14 PM, Marco Tiloca 
>> <marco.tiloca=[e-mail]> wrote:
>>
>> 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 inhttps://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 
>> [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 [e-mail]
>> --
>> Lake mailing list [e-mail]
>> To unsubscribe send an email [e-mail]
>