Re: [auth48] [IANA #1361342] [IANA] Re: AUTH48: RFC-to-be 9528 <draft-ietf-lake-edhoc-23> for your review

[Alanna Paloma <[e-mail]>]

Hi David,

Thank you for the quick turnaround! The changes look good.

Best regards,
RFC Editor/ap

> On Mar 15, 2024, at 12:39 PM, David Dong via RT <[e-mail]> wrote:
> 
> Hi Alanna,
> 
> These changes are complete:
> 
> -24 to 23 Standards Action
> 
> 0 Reserved for success
> 1 tstr Unspecified error
> 
> Please see:
> https://www.iana.org/assignments/edhoc/
> 
> Best regards,
> 
> David Dong
> IANA Services Sr. Specialist
> 
> On Fri Mar 15 16:36:39 2024, [e-mail] wrote:
>> IANA,
>> 
>> Please make the following updates to the "EDHOC Error Codes” registry
>> <https://www.iana.org/assignments/edhoc/edhoc.xhtml> to match what is
>> in the document.
>> 
>> The diff file can be seen here: https://www.rfc-
>> editor.org/authors/rfc9528-diff.html
>> 
>> 1) Please update the following values of the Description column as
>> follows, i.e., update “Reserved” to be “Reserved for success” and
>> change to lowercase "e” in “Error”.
>> 
>> OLD:
>> ERR_CODE        ERR_INFO Type   Description
>> 0                                                       Reserved
>> 1                       tstr                            Unspecified
>> Error
>> 
>> NEW:
>> ERR_CODE        ERR_INFO Type   Description
>> 0                                                       Reserved for
>> success
>> 1                       tstr                            Unspecified
>> error
>> 
>> 2) Please update the following range in the Registration Procedures to
>> expand it from “-20 to 23” to “-24 to 23”.
>> 
>> Old:
>> -20 to 23  Standards Action
>> 
>> New:
>> -24 to 23  Standards Action
>> 
>> Best regards,
>> RFC Editor/ap
>> 
>>> On Mar 14, 2024, at 5:52 PM, Paul Wouters <[e-mail]>
>>> wrote:
>>> 
>>> 
>>>> On Mar 15, 2024, at 05:50, Alanna Paloma <[e-mail]> wrote:
>>>> 
>>>> Hi Göran and Paul*,
>>>> 
>>>> *Paul - Please review and approve of the following updates.
>>>> 
>>>> - Section 3.4: added text
>>>> - Section 3.5: added text
>>>> - Section 3.5.2: added key word
>>>> - Section 3.6: updated text
>>>> - Section 6.3.1: added key word
>>>> - Section 11.2: added reference
>>>> 
>>>> These changes can be seen in this diff file:
>>>> https://www.rfc-editor.org/authors/rfc9528-ad-diff.html
>>> 
>>> Approved.
>>> 
>>> Paul
>>> 
>>>> 
>>>> Göran - We have incorporated your suggestions into the files. Please
>>>> let us know if any further updates are needed
>>>> 
>>>> The files have been posted here (please refresh):
>>>> https://www.rfc-editor.org/authors/rfc9528.xml
>>>> https://www.rfc-editor.org/authors/rfc9528.txt
>>>> https://www.rfc-editor.org/authors/rfc9528.html
>>>> https://www.rfc-editor.org/authors/rfc9528.pdf
>>>> 
>>>> The relevant diff files have been posted here:
>>>> https://www.rfc-editor.org/authors/rfc9528-diff.html (comprehensive
>>>> diff)
>>>> https://www.rfc-editor.org/authors/rfc9528-auth48diff.html (AUTH48
>>>> changes)
>>>> https://www.rfc-editor.org/authors/rfc9528-lastdiff.html (htmlwdiff
>>>> diff between last version and this)
>>>> https://www.rfc-editor.org/authors/rfc9528-lastrfcdiff.html (rfcdiff
>>>> between last version and this)
>>>> 
>>>> Thank you,
>>>> RFC Editor/ap
>>>> 
>>>>> On Mar 14, 2024, at 12:04 PM, Göran Selander
>>>>> <[e-mail]> wrote:
>>>>> 
>>>>> Hi Alanna, and all,  When I was checking the updates I found some
>>>>> two more nits and a proposed change. I apologize for late input.
>>>>> 3.6
>>>>> ORIGINAL
>>>>> IEEE CCM* mode
>>>>> OLD
>>>>> IEEE Counter with CBC-MAC (CCM)*
>>>>> NEW
>>>>> IEEE AES-CCM* mode of operation which is an extension of the CCM
>>>>> mode, defined in [IEEE Std 802.15.4‐2015, Annex B].
>>>>> GS: New reference needed.
>>>>> 9.1.
>>>>> ORIGINAL
>>>>> EDHOC also adds selection of connection identifiers
>>>>> OLD
>>>>> EDHOC also adds a selection of connection identifiers
>>>>> NEW
>>>>> EDHOC also adds the selection of connection identifiers
>>>>> Acknowledgments
>>>>> OLD
>>>>> intermediate draft versions of this document. We are especially
>>>>> indebted …
>>>>> NEW
>>>>> intermediate draft versions of this document.
>>>>> We are especially indebted …
>>>>> GS: Please insert a new paragraph.
>>>>> Thanks!
>>>>> Göran
>>>>> From: Alanna Paloma <[e-mail]>
>>>>> Date: Thursday, 14 March 2024 at 18:13
>>>>> To: Göran Selander <[e-mail]>, Paul Wouters
>>>>> <paul.wouters=[e-mail]>
>>>>> Cc: Mališa Vučinić <[e-mail]>, John Mattsson
>>>>> <[e-mail]>, Francesca Palombini
>>>>> <[e-mail]>, Sandy Ginoza
>>>>> <[e-mail]>, RFC Editor <[e-mail]>, lake-
>>>>> [e-mail] <[e-mail]>, [e-mail]<lake-
>>>>> [e-mail]>, [e-mail] <auth48archive@rfc-
>>>>> editor.org>
>>>>> Subject: [AD] Re: AUTH48: RFC-to-be 9528 <draft-ietf-lake-edhoc-23>
>>>>> for your review
>>>>> Hi Göran and Paul*,
>>>>> 
>>>>> *Paul - As the AD, the review and approve of the following updates.
>>>>> 
>>>>> - Section 3.4: added text
>>>>> - Section 3.5: added text
>>>>> - Section 3.5.2: added key word
>>>>> - Section 6.3.1: added key word
>>>>> 
>>>>> These changes can be seen in this diff file:
>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>> editor.org%2Fauthors%2Frfc9528-ad-
>>>>> diff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915827805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=xcPOEsEeUuIspxGrvm6FjANullsyhtWKkzsHAELGvFk%3D&reserved=0
>>>>> 
>>>>> Göran - Thank you for your reply. The files have been updated per
>>>>> your suggestion, and we have noted your approval on the AUTH48
>>>>> status page:
>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>> editor.org%2Fauth48%2Frfc9528&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915837351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=c%2B1sUMVJVViyLit05hZgiYxXqICFsOkGxkN70QVWYU0%3D&reserved=0
>>>>> 
>>>>> The files have been posted here (please refresh):
>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>> editor.org%2Fauthors%2Frfc9528.xml&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915843983%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=vNjwGD3yDseST1TDWgZMPIyulNevLmloPm3JT1kRhqU%3D&reserved=0
>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>> editor.org%2Fauthors%2Frfc9528.txt&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915849128%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=U8M2iHLtxMPoqzjxIB4oQ1OpKF0uOzYlNhbvQcZEO2Q%3D&reserved=0
>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>> editor.org%2Fauthors%2Frfc9528.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915853501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=nZuIOxGmKxg7r8cnCqgRim8%2BGKVe9%2FpqCwHMzMl6J9I%3D&reserved=0
>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>> editor.org%2Fauthors%2Frfc9528.pdf&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915857792%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=U4SWxkbhB5F45U80FZNz%2FNxHCLZKTnkMER4rhbvi9Fw%3D&reserved=0
>>>>> 
>>>>> The relevant diff files have been posted here:
>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>> editor.org%2Fauthors%2Frfc9528-
>>>>> diff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915862059%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Ev6Ycb5d1daHl%2BVVgDQKiFkNBwXe7C9ocM8m249Ru0E%3D&reserved=0
>>>>> (comprehensive diff)
>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>> editor.org%2Fauthors%2Frfc9528-
>>>>> auth48diff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915866331%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=HFKUS5DZDI4qteTJDpsDkp3e1XapYDTfOxbB6cFyc08%3D&reserved=0
>>>>> (AUTH48 changes)
>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>> editor.org%2Fauthors%2Frfc9528-
>>>>> lastdiff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915870674%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=se%2BdDwJtiqcvJkGnyNy6shx9GTFDAayRQo%2F2U4L5b8E%3D&reserved=0
>>>>> (htmlwdiff diff between last version and this)
>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>> editor.org%2Fauthors%2Frfc9528-
>>>>> lastrfcdiff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915874925%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=VNgT0y06dOnkFZGfoBDN8ePnPv1%2FRE6uHeSXjL%2FOZy8%3D&reserved=0
>>>>> (rfcdiff between last version and this)
>>>>> 
>>>>> Once we have received Paul’s approval, we will ask IANA to update
>>>>> their registry accordingly. After the IANA updates are complete, we
>>>>> will move forward with the publication process.
>>>>> 
>>>>> Thank you,
>>>>> RFC Editor/ap
>>>>> 
>>>>>>> On Mar 13, 2024, at 2:12 PM, Göran Selander
>>>>>>> <[e-mail]> wrote:
>>>>>> 
>>>>>> Hi again Alanna, and all
>>>>>> Sorry for the spam. I learnt a better formulation in the proposed
>>>>>> update to Section 6.3.1,  which is a minor change to the text
>>>>>> previously proposed:
>>>>>> NEW2
>>>>>> After receiving SUITES_R, the Initiator can determine which cipher
>>>>>> suite to select (if any) for the next EDHOC run with the
>>>>>> Responder. The Initiator SHOULD remember which selected cipher
>>>>>> suite to use until the next message_1 has been sent; otherwise,
>>>>>> the Initiator and Responder will run into an infinite loop where
>>>>>> the Initiator selects its most preferred cipher suite and the
>>>>>> Responder sends an error with supported cipher suites.
>>>>>> After a completed EDHOC session, the Initiator MAY remember the
>>>>>> selected cipher suite to use in future EDHOC sessions with a
>>>>>> particularthis Responder. Note that if the Initiator or Responder
>>>>>> is updated with new cipher suite policies, any cached information
>>>>>> may be outdated.
>>>>>> In other words, compared to the previous proposal the NEW2 text
>>>>>> is:
>>>>>> NEW
>>>>>> a particular
>>>>>> NEW2
>>>>>> this
>>>>>> Thanks
>>>>>> Göran
>>>>>> From: Göran Selander <[e-mail]>
>>>>>> Date: Wednesday, 13 March 2024 at 21:19
>>>>>> To: Alanna Paloma <[e-mail]>, Mališa Vučinić
>>>>>> <[e-mail]>, Paul Wouters
>>>>>> <paul.wouters=[e-mail]>, John Mattsson
>>>>>> <[e-mail]>, Francesca Palombini
>>>>>> <[e-mail]>
>>>>>> Cc: Sandy Ginoza <[e-mail]>, RFC Editor <rfc-editor@rfc-
>>>>>> editor.org>, [e-mail] <[e-mail]>, lake-
>>>>>> [e-mail] <[e-mail]>, auth48archive@rfc-
>>>>>> editor.org <[e-mail]>
>>>>>> Subject: Re: AUTH48: RFC-to-be 9528 <draft-ietf-lake-edhoc-23> for
>>>>>> your review
>>>>>> Hi Alanna, and all,
>>>>>> Here are some additional comments.
>>>>>> General
>>>>>> "CCS [RFC8392]" (multiple occurences)
>>>>>> GS: Note that while CWT and CWT Claims Set are defined in RFC
>>>>>> 8392, the abbreviation CCS is not. This is the reason why the
>>>>>> original text always spells out CCS when making the reference the
>>>>>> RFC 8392: "CWT Claims Set (CCS) [RFC8392]".  This is just for your
>>>>>> information, no action is required unless you think it is an
>>>>>> issue.
>>>>>> Abstract
>>>>>> OLD
>>>>>> lightweight authenticated Diffie-Hellman (DH) key exchange
>>>>>> NEW
>>>>>> lightweight authenticated Diffie-Hellman key exchange
>>>>>> GS: While the expansion of COSE, CoAP and CBOR makes sense in the
>>>>>> abstract, the abbreviation of Diffie-Hellman as DH makes less
>>>>>> sense to me. The abbreviation is not needed to understand the
>>>>>> abstract, and a person reading the abbreviation DH in the body of
>>>>>> the document (which only occurs in the combination "static DH")
>>>>>> would probably not look in the abstract for the definition. I
>>>>>> propose to move this definition of DH to Section 1:
>>>>>> 1.
>>>>>> OLD
>>>>>> static Diffie-Hellman public keys
>>>>>> NEW
>>>>>> static Diffie-Hellman (DH) public keys
>>>>>> 1.1  OLD
>>>>>> The IETF has acknowledged this problem by standardizing a range of
>>>>>> lightweight protocols and enablers designed for the IoT, including
>>>>>> the CoAP [RFC7252], CBOR [RFC8949], and Static Context Header
>>>>>> Compression (SCHC) [RFC8724].
>>>>>> NEW
>>>>>> The IETF has acknowledged this problem by standardizing a range of
>>>>>> lightweight protocols and enablers designed for the IoT, including
>>>>>> CoAP [RFC7252], CBOR [RFC8949], and Static Context Header
>>>>>> Compression (SCHC) [RFC8724].
>>>>>> 2
>>>>>> OLD
>>>>>> In order to create a "full-fledged" protocol, some additional
>>>>>> protocol elements are needed. EDHOC adds:
>>>>>> NEW
>>>>>> In order to create a "full-fledged" protocol, some additional
>>>>>> protocol elements are needed. This specification adds:
>>>>>>  GS: The old formulation gives the impression that new
>>>>>> specifications (e.g. new methods) would not be EDHOC.
>>>>>> ORIGINAL
>>>>>> * selection of connection identifiers
>>>>>> OLD
>>>>>> * a selection of connection identifiers
>>>>>> GS: To me this reads as "a set of connection identifier", whereas
>>>>>> the original text is highlighting the selection capability of the
>>>>>> protocol. Please revert to the original formulation with "*
>>>>>> selection", or use "* the selection", or other formulation that
>>>>>> highlights that that the protocol includes a selection procedure.
>>>>>> OLD
>>>>>> To simplify for implementors, the use of CBOR and COSE in EDHOC is
>>>>>> summarized in Appendix C.
>>>>>> NEW
>>>>>> To simplify for implementors, the use of CBOR, CDDL and COSE in
>>>>>> EDHOC is summarized in Appendix C.
>>>>>> 3.2
>>>>>> OLD
>>>>>> EDHOC supports authentication with signature or
>>>>>> NEW
>>>>>> EDHOC currently supports authentication with signature or
>>>>>> GS: Support for PSK based authentication is in the new charter.
>>>>>> 3.4
>>>>>> OLD
>>>>>> There is no maximum message size specified by the protocol; for
>>>>>> example, this is dependent on the size of the authentication
>>>>>> credentials (if they are transported, see Section 3.5).
>>>>>> NEW
>>>>>> There is no maximum message size specified by the protocol; for
>>>>>> example, this is dependent on the size of the authentication
>>>>>> credentials (if they are transported, see Section 3.5). The
>>>>>> encryption of very large content in message_2 when using certain
>>>>>> hash algorithms is described in [Appendix G].
>>>>>> 3.5
>>>>>> OLD
>>>>>> EDHOC supports various settings for how the other endpoint's
>>>>>> authentication (public) key may be transported, identified, and
>>>>>> trusted.
>>>>>> NEW
>>>>>> EDHOC supports various settings for how the other endpoint's
>>>>>> public key for authentication may be transported, identified, and
>>>>>> trusted. We shall use the term "authentication key" to mean key
>>>>>> used for authentication in general, or specifically, the public
>>>>>> key, when there is no risk for confusion.
>>>>>> GS: This replaces and expands on the explanation removed in the
>>>>>> following change:
>>>>>> 3.5.1
>>>>>> OLD
>>>>>> The authentication key (i.e., the public key used for
>>>>>> authentication) MUST be a signature key or a static Diffie-Hellman
>>>>>> key.
>>>>>> NEW
>>>>>> The authentication key MUST be a signature key or a static Diffie-
>>>>>> Hellman key.
>>>>>> OLD
>>>>>> Note that for most signature algorithms, the signature is
>>>>>> determined by the signature algorithm and the authentication key
>>>>>> algorithm together.
>>>>>> NEW
>>>>>> Note that for most signature algorithms, the signature is
>>>>>> determined jointly by the signature algorithm and the
>>>>>> authentication key algorithm.
>>>>>> GS: Proposed rephrasing
>>>>>> OLD
>>>>>> For X.509 certificates, the authentication key is represented by a
>>>>>> SubjectPublicKeyInfo field. For CWT and CCS (see Section 3.5.2),
>>>>>> the authentication key is represented by a 'cnf' claim [RFC8747]
>>>>>> containing a COSE_Key [RFC9052]. In EDHOC, a raw public key (RPK)
>>>>>> is an authentication key encoded as a COSE_Key wrapped in a CCS.
>>>>>> NEW
>>>>>> For X.509 certificates, the authentication key is represented by a
>>>>>> SubjectPublicKeyInfo field, which also contains information about
>>>>>> authentication key algorithm. For CWT and CCS (see Section 3.5.2),
>>>>>> the authentication key is represented by a 'cnf' claim [RFC8747]
>>>>>> containing a COSE_Key [RFC9052], which contains information about
>>>>>> authentication key algorithm. In EDHOC, a raw public key (RPK) is
>>>>>> an authentication key encoded as a COSE_Key wrapped in a CCS, an
>>>>>> example is given in [Figure 4].
>>>>>> GS: This gives the reader more examples on authentication key
>>>>>> /algorithm/.
>>>>>> 3.5.2
>>>>>> OLD
>>>>>> The Initiator and Responder SHOULD use an available authentication
>>>>>> credential (transported in EDHOC or otherwise provisioned) without
>>>>>> re-encoding. If for some reason re-encoding of an authentication
>>>>>> credential passed by reference may occur, then a potential common
>>>>>> encoding for CBOR-based credentials is deterministically encoded
>>>>>> CBOR, as specified in Sections 4.2.1 and 4.2.2 of [RFC8949].
>>>>>> Authentication credentials passed by value are used as is without
>>>>>> re-encoding.
>>>>>> NEW
>>>>>> The Initiator and Responder SHOULD use an available authentication
>>>>>> credential without re-encoding, i.e. an authentication credential
>>>>>> transported in EDHOC by value, or otherwise provisioned, SHOULD be
>>>>>> used as is. If for some reason re-encoding of an authentication
>>>>>> credential passed by reference may occur, then a potential common
>>>>>> encoding for CBOR-based credentials is deterministically encoded
>>>>>> CBOR, as specified in Sections 4.2.1 and 4.2.2 of [RFC8949].
>>>>>> GS: Merge first and last sentences of this excerpt since they talk
>>>>>> about the same thing.
>>>>>>  OLD
>>>>>> Naked COSE_Keys are thus dressed as CCS when used in EDHOC in its
>>>>>> simplest form by prefixing the COSE_Key with 0xA108A101 (a map
>>>>>> with a 'cnf' claim).
>>>>>> NEW
>>>>>> Naked COSE_Keys are thus dressed as CCS when used in EDHOC, in its
>>>>>> simplest form by prefixing the COSE_Key with 0xA108A101 (a map
>>>>>> with a 'cnf' claim).
>>>>>> GS: I added a comma to clarify that the end of the sentence is an
>>>>>> example.
>>>>>> 3.6
>>>>>> OLD
>>>>>> Just like in (D)TLS 1.3 [RFC8446] [RFC9147] and IKEv2 [RFC7296], a
>>>>>> signature in COSE is determined by the signature algorithm and the
>>>>>> authentication key algorithm together; see Section 3.5.1.
>>>>>> NEW
>>>>>> Just like in (D)TLS 1.3 [RFC8446] [RFC9147] and IKEv2 [RFC7296], a
>>>>>> signature in COSE is determined jointly by the signature algorithm
>>>>>> and the authentication key algorithm; see Section 3.5.1.
>>>>>> GS: Proposed rephrasing.
>>>>>> OLD
>>>>>> Cipher suites 0-3, based on AES-CCM, are intended for constrained
>>>>>> IoT where a message overhead is a very important factor.
>>>>>> NEW
>>>>>> Cipher suites 0-3, based on AES-CCM, are intended for constrained
>>>>>> IoT where message overhead is a very important factor.
>>>>>> GS: "message overhead" refers to a property such as "delay",
>>>>>> "latency", etc. where it doesn't make sense here to use indefinite
>>>>>> article. Please revert to the original formulation without "a".
>>>>>>  4.1.1.1
>>>>>> OLD
>>>>>> Example: Assuming the use of SHA-256, the extract phase of the Key
>>>>>> Derivation Function (HKDF) produces PRK_2e as follows:
>>>>>> NEW
>>>>>> Example: Assuming the use of SHA-256, the extract phase of the key
>>>>>> derivation function is HKDF-Extract, which produces PRK_2e as
>>>>>> follows:
>>>>>> GS: More details to the example.
>>>>>> 5.2.1
>>>>>> ORIGINAL
>>>>>> C_I - variable-length connection identifier
>>>>>> OLD
>>>>>> C_I is the variable-length connection identifier
>>>>>> NEW
>>>>>> C_I is a variable-length connection identifier
>>>>>> GS: "the" gives the impression that it is unique. Similarly:
>>>>>> ORIGINAL
>>>>>> EAD_1 - external authorization data
>>>>>> OLD
>>>>>> EAD_1 is the external authorization data
>>>>>> NEW
>>>>>> EAD_1 is external authorization data
>>>>>> 5.2.2
>>>>>> ORIGINAL
>>>>>> if the Initiator previously received from the Responder an error
>>>>>> message with error code 2 containing SUITES_R (see Section 6.3)
>>>>>> indicating cipher suites supported by the Responder,
>>>>>> OLD
>>>>>> if the Initiator previously received from the Responder has an
>>>>>> error message with error code 2 containing SUITES_R (see Section
>>>>>> 6.3) indicating cipher suites supported by the Responder,
>>>>>> GS: There is something wrong with this sentence, I can't parse it
>>>>>> with the added "has". Did you intend to change the original into:
>>>>>> "if the Initiator *has* previously received from the Responder an
>>>>>> error message ..."? Either that, or revert to original, or other
>>>>>> formulation where it is clear that this is a conditional statement
>>>>>> about the Initiator having received an error message.
>>>>>> 5.3.2
>>>>>> ORIGINAL
>>>>>> ID_CRED_R - identifier to facilitate the retrieval of CRED_R
>>>>>> OLD
>>>>>> ID_CRED_R is the identifier to facilitate the retrieval of CRED_R
>>>>>> NEW
>>>>>> ID_CRED_R is an identifier to facilitate the retrieval of CRED_R
>>>>>> GS: "the" gives the impression that it is unique. Similarly:
>>>>>> OLD
>>>>>> CRED_R is the CBOR item containing
>>>>>> NEW
>>>>>> CRED_R is a CBOR item containing
>>>>>> OLD
>>>>>> EAD_2 is the external authorization data
>>>>>> NEW
>>>>>> OLD
>>>>>> EAD_2 is external authorization data
>>>>>> 5.4.2
>>>>>> OLD
>>>>>> ID_CRED_I is the identifier to facilitate the retrieval of CRED_I
>>>>>> NEW
>>>>>> ID_CRED_I is an identifier to facilitate the retrieval of CRED_I
>>>>>> OLD
>>>>>> CRED_I is the CBOR item containing
>>>>>> NEW
>>>>>> CRED_I is a CBOR item containing
>>>>>> OLD
>>>>>> EAD_3 is the external authorization data
>>>>>> NEW
>>>>>> OLD
>>>>>> EAD_3 is external authorization data
>>>>>> 5.5.2
>>>>>> OLD
>>>>>> EAD_4 is the external authorization data
>>>>>> NEW
>>>>>> OLD
>>>>>> EAD_4 is external authorization data
>>>>>> 6.
>>>>>> OLD
>>>>>> ERR_INFO is the error information
>>>>>> NEW
>>>>>> ERR_INFO is error information
>>>>>> 6.3.1
>>>>>> OLD
>>>>>> After receiving SUITES_R, the Initiator can determine which cipher
>>>>>> suite to select (if any) for the next EDHOC run with the
>>>>>> Responder.
>>>>>> The Initiator needs to remember which selected cipher suite to use
>>>>>> until the next message_1 has been sent; otherwise, the Initiator
>>>>>> and Responder will run into an infinite loop where the Initiator
>>>>>> selects its most preferred cipher suite and the Responder sends an
>>>>>> error with supported cipher suites. After a completed EDHOC
>>>>>> session, the Initiator MAY remember the selected cipher suite to
>>>>>> use in future EDHOC sessions. Note that if the Initiator or
>>>>>> Responder is updated with new cipher suite policies, any cached
>>>>>> information may be outdated.
>>>>>> NEW
>>>>>> After receiving SUITES_R, the Initiator can determine which cipher
>>>>>> suite to select (if any) for the next EDHOC run with the
>>>>>> Responder. The Initiator SHOULD remember which selected cipher
>>>>>> suite to use until the next message_1 has been sent; otherwise,
>>>>>> the Initiator and Responder will run into an infinite loop where
>>>>>> the Initiator selects its most preferred cipher suite and the
>>>>>> Responder sends an error with supported cipher suites.
>>>>>> After a completed EDHOC session, the Initiator MAY remember the
>>>>>> selected cipher suite to use in future EDHOC sessions with a
>>>>>> particular Responder. Note that if the Initiator or Responder is
>>>>>> updated with new cipher suite policies, any cached information may
>>>>>> be outdated.
>>>>>> GS: Propose to reverting to the SHOULD from the original text.
>>>>>> Please note the change in paragraph break, emphasizing the
>>>>>> different actions in the different message processing phases.
>>>>>> 9.1
>>>>>> ORIGINAL
>>>>>> EDHOC also adds selection of connection identifiers and downgrade
>>>>>> protected negotiation of cryptographic parameters
>>>>>> OLD
>>>>>> EDHOC also adds selection of connection identifiers and downgrades
>>>>>> protected negotiation of cryptographic parameters
>>>>>> NEW
>>>>>> EDHOC also adds selection of connection identifiers and downgrade-
>>>>>> protected negotiation of cryptographic parameters
>>>>>> GS: This refers to protecting the negotiation against downgrade of
>>>>>> cryptographic parameters.
>>>>>> 9.5
>>>>>> OLD
>>>>>> Note that even if ead_value is encrypted outside of EDHOC, the
>>>>>> ead_labels in EAD_1 is revealed to passive attackers and the
>>>>>> ead_labels in EAD_2 is revealed to active attackers.
>>>>>> NEW
>>>>>> Note that even if ead_value is encrypted outside of EDHOC, the
>>>>>> ead_labels in EAD_1 are revealed to passive attackers and the
>>>>>> ead_labels in EAD_2 are revealed to active attackers.
>>>>>> 10.5  OLD
>>>>>> Table 11: Registration procedures for EDHOC EAD Labels
>>>>>> NEW
>>>>>> Table 11: Registration Procedures for EDHOC EAD Labels
>>>>>> 10.11
>>>>>> "Expert reviewers should take into consideration the following
>>>>>> points:
>>>>>> - - -
>>>>>> "
>>>>>> ORIGINAL
>>>>>> Even for "Expert Review" specifications are recommended.
>>>>>> OLD
>>>>>> The fact that even "Expert Review" specifications are recommended.
>>>>>> NEW
>>>>>> It is recommended to have a specification even if the registration
>>>>>> procedure is "Expert Review".
>>>>>> GS: Proposed rephrasing.
>>>>>> OLD
>>>>>> When specifications are not provided for a request where Expert
>>>>>> Review is the assignment policy, the description provided needs to
>>>>>> have sufficient information to verify the code points above.
>>>>>> NEW
>>>>>> When specifications are not provided for a request where Expert
>>>>>> Review is the assignment policy, the description provided needs to
>>>>>> have sufficient information to verify the code points as above.
>>>>>>  Appendix G
>>>>>> ORIGINAL with SHA-256 as EDHOC hash algorithm
>>>>>> OLD
>>>>>> with SHA-256 as an EDHOC hash algorithm
>>>>>> NEW
>>>>>> with SHA-256 as the EDHOC hash algorithm
>>>>>> GS: The EDHOC hash algorithm is determined by the cipher suite so
>>>>>> it is fixed in this example.
>>>>>>  Acknowledgements
>>>>>> ORIGINAL
>>>>>> We are especially indebted to the late Jim Schaad for his
>>>>>> continuous reviewing and implementation of early versions of this
>>>>>> and other drafts.
>>>>>> OLD
>>>>>> We are especially indebted to the late Jim Schaad for his
>>>>>> continuous reviewing and implementation of early draft versions of
>>>>>> this document.
>>>>>> NEW
>>>>>> We are especially indebted to the late Jim Schaad for his
>>>>>> continuous review and implementation of draft versions of this
>>>>>> document, as well as his work on other technologies such as COSE
>>>>>> and OSCORE without which EDHOC would not have been.
>>>>>> GS: As the original formulation indicates our gratitude extends
>>>>>> beyond this document.
>>>>>> With these changes, I approve publication.
>>>>>> Thanks,
>>>>>> Göran
>>>>>> From: Alanna Paloma <[e-mail]>
>>>>>> Date: Tuesday, 12 March 2024 at 17:23
>>>>>> To: Göran Selander <[e-mail]>, Mališa Vučinić
>>>>>> <[e-mail]>, Paul Wouters
>>>>>> <paul.wouters=[e-mail]>, John Mattsson
>>>>>> <[e-mail]>, Francesca Palombini
>>>>>> <[e-mail]>
>>>>>> Cc: Sandy Ginoza <[e-mail]>, RFC Editor <rfc-editor@rfc-
>>>>>> editor.org>, [e-mail] <[e-mail]>, lake-
>>>>>> [e-mail] <[e-mail]>, auth48archive@rfc-
>>>>>> editor.org <[e-mail]>
>>>>>> Subject: Re: AUTH48: RFC-to-be 9528 <draft-ietf-lake-edhoc-23> for
>>>>>> your review
>>>>>> Authors and Paul*,
>>>>>> 
>>>>>> Thank you for your replies. We have updated the text per Mališa’s
>>>>>> suggestion and inserted the now assigned IANA values.
>>>>>> 
>>>>>> The files have been posted here (please refresh):
>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>> editor.org%2Fauthors%2Frfc9528.xml&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915879280%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=UX5yQ156vTwY2ZXcmmhjYJylIUv%2FVFWOpX1iBSXJZaE%3D&reserved=0
>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>> editor.org%2Fauthors%2Frfc9528.txt&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915883962%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=XKlCLbn5KO0gFOK4ulscZchJQp64lXql4l6kxHtqMl8%3D&reserved=0
>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>> editor.org%2Fauthors%2Frfc9528.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915889439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=UxtA%2BX4BkxhuMJozdNBKFu6Zk15l2amS5jf0XlRvRL0%3D&reserved=0
>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>> editor.org%2Fauthors%2Frfc9528.pdf&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915894203%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=rnXY6%2F8aOslmmR0Y%2BEseLE55mR%2FeorKHQ6VtY%2B%2FR%2F6g%3D&reserved=0
>>>>>> 
>>>>>> The relevant diff files have been posted here:
>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>> editor.org%2Fauthors%2Frfc9528-
>>>>>> diff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915898532%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=cueH%2BU43pWM0%2FwpO%2BdRO9zYkfNd4MqcJfBCWs9Oaqhg%3D&reserved=0
>>>>>> (comprehensive diff)
>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>> editor.org%2Fauthors%2Frfc9528-
>>>>>> auth48diff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915902829%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Ev%2FbYAdLO4J%2FapfE2T8X6qhRYxa9wQtvvSWPsLTMmDo%3D&reserved=0
>>>>>> (AUTH48 changes)
>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>> editor.org%2Fauthors%2Frfc9528-
>>>>>> lastdiff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915907199%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=k%2Bq3MRtlkm8UyYvHTmXPepx7ULfFTpGG6oEMrgBEXgI%3D&reserved=0
>>>>>> (htmlwdiff diff between last version and this)
>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>> editor.org%2Fauthors%2Frfc9528-
>>>>>> lastrfcdiff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915912252%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=KB0aw8n341HE15HWhbElVd7nzdZ3FzlU7%2BMtFPcTaEQ%3D&reserved=0
>>>>>> (rfcdiff between last version and this)
>>>>>> 
>>>>>> *Paul’s approval has been noted on the AUTH48 status page:
>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>> editor.org%2Fauth48%2Frfc9528&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915916595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Nxsn9kkg1wmi8WrgzlOZasozJrgd31Zqgnh%2F7faGgyw%3D&reserved=0
>>>>>> 
>>>>>> Once we have received approvals from Göran and Francesca, we will
>>>>>> move this document forward in the publication process.
>>>>>> 
>>>>>> Thank you,
>>>>>> RFC Editor/ap
>>>>>> 
>>>>>>> On Mar 12, 2024, at 7:21 AM, Göran Selander
>>>>>>> <[e-mail]> wrote:
>>>>>>> 
>>>>>>> Hi Mališa, and all,
>>>>>>> The authors are fine with the text.
>>>>>>> Thanks,
>>>>>>> Göran
>>>>>>> From: Mališa Vučinić <[e-mail]>
>>>>>>> Date: Monday, 11 March 2024 at 22:26
>>>>>>> To: Göran Selander <[e-mail]>
>>>>>>> Cc: John Mattsson <[e-mail]>, Paul Wouters
>>>>>>> <paul.wouters=[e-mail]>, Alanna Paloma
>>>>>>> <[e-mail]>, Francesca Palombini
>>>>>>> <[e-mail]>, Sandy Ginoza
>>>>>>> <[e-mail]>, RFC Editor <[e-mail]>, lake-
>>>>>>> [e-mail] <[e-mail]>, [e-mail]<lake-
>>>>>>> [e-mail]>, [e-mail]
>>>>>>> <[e-mail]>
>>>>>>> Subject: Re: [AD] Re: AUTH48: RFC-to-be 9528 <draft-ietf-lake-
>>>>>>> edhoc-23> for your review
>>>>>>> Hi all,
>>>>>>> It seems that we have consensus, including Paul, on the following
>>>>>>> text, without the addition of the new references.
>>>>>>> NEW:
>>>>>>> Note that the security properties depend on the type of context
>>>>>>> and the number of KeyUpdate iterations.
>>>>>>> @Authors and Paul: please confirm whether this is OK by you.
>>>>>>> Mališa
>>>>>>> —————————
>>>>>>> Mališa Vučinić
>>>>>>> Research Scientist, Inria
>>>>>>> Co-chair, IETF LAKE
>>>>>>> 
>>>>>>> 
>>>>>>> On Mar 10, 2024, at 09:08, Göran Selander
>>>>>>> <[e-mail]> wrote:
>>>>>>>  Hi Paul and all,
>>>>>>> I understand the issue how it is perceived that John adds these
>>>>>>> references in AUTH48.
>>>>>>> However, this was discussed in the latest LAKE WG interim meeting
>>>>>>> on Feb 13, where John did propose to add  these pointers in the
>>>>>>> security considerations.
>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fminutes-
>>>>>>> interim-2024-lake-01-
>>>>>>> 202402131400%2F&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915920870%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=BVnQXznbwpZ8BBr2n5rf6S4MmScKp1mqfOW5ba1gR70%3D&reserved=0
>>>>>>> “JPM: Will mail TLS group, and MLS, and QUIC, and CoRE, once
>>>>>>> published. It's in pre-print. No immediate action needed, small
>>>>>>> seccons is way to go
>>>>>>> SF: Might be interesting, before we do seccons, to know what
>>>>>>> people think in the TLS/QUIC context.
>>>>>>> JPM: Can just point to those in seccons, would be uncontroversial
>>>>>>> addition.
>>>>>>> SF: Maybe also text into MT's draft.”
>>>>>>> My recollection is, and the “also” in the last quoted line
>>>>>>> indicates, that Stephen in the end didn’t disagree with the
>>>>>>> proposal (please speak up if I’m wrong). No other proposal on
>>>>>>> this topic has been noted.
>>>>>>> So it seems to me that the WG has agreed to this, or at least not
>>>>>>> disagreed to add security considerations, which of course can be
>>>>>>> done with or without references.
>>>>>>> As John writes, this is a minor remark, the priority is to not
>>>>>>> delay publication.
>>>>>>> And in any case, since one of the papers is quite recent and not
>>>>>>> yet reviewed, we should not draw any definitive conclusion based
>>>>>>> on that. But to formulate a concern / caveat related to the use
>>>>>>> of the key update mechanism seems prudent, given the inputs we
>>>>>>> have today.
>>>>>>> John’s proposed text:
>>>>>>> Note that the security properties depends on the type of context
>>>>>>> and the number of KeyUpdate iterations [1][2].
>>>>>>> NEW1:
>>>>>>> Recent results indicate that the security properties may depend
>>>>>>> on the type of context and the number of KeyUpdate iterations
>>>>>>> iterations.
>>>>>>> However, this may be too inspecific to guide the reader. Making a
>>>>>>> reference to a paper would have been the obvious thing to do in
>>>>>>> this security consideration, had it not been for  the author of
>>>>>>> the paper also being an author of the draft. I think NEW1 is
>>>>>>> sufficiently vague, and in combination with that it has been
>>>>>>> discussed at a WG meeting, to allow the inclusion of the
>>>>>>> references:
>>>>>>> NEW2:
>>>>>>> Recent results indicate that the security properties may depend
>>>>>>> on the type of context and the number of KeyUpdate iterations
>>>>>>> iterations [1][2].
>>>>>>> Göran
>>>>>>> From: John Mattsson <[e-mail]>
>>>>>>> Date: Saturday, 9 March 2024 at 17:48
>>>>>>> To: Paul Wouters <paul.wouters=[e-mail]>, Alanna
>>>>>>> Paloma <[e-mail]>, Göran Selander
>>>>>>> <[e-mail]>
>>>>>>> Cc: Francesca Palombini <[e-mail]>, Sandy
>>>>>>> Ginoza <[e-mail]>, RFC Editor <rfc-editor@rfc-
>>>>>>> editor.org>, [e-mail] <[e-mail]>, lake-
>>>>>>> [e-mail] <[e-mail]>,
>>>>>>> [e-mail]<[e-mail]>,
>>>>>>> [e-mail] <[e-mail]>
>>>>>>> Subject: Re: [AD] Re: AUTH48: RFC-to-be 9528 <draft-ietf-lake-
>>>>>>> edhoc-23> for your review
>>>>>>>> I do not approve of a single author adding two new references
>>>>>>>> citing himself to the document in AUTH48, without a confirmation
>>>>>>>> of >the WG.
>>>>>>> That sounds reasonable. Göran or Francesca, can you suggest
>>>>>>> something (as long as it does not delay publication). You are not
>>>>>>> authors of the referenced papers. Göran, I got the feeling you
>>>>>>> wanted more changes than I suggested.  I think it would be good
>>>>>>> to give some information to the reader in RFC 9528. The first
>>>>>>> reference is peer reviewed, it shows that the number of
>>>>>>> iterations matters. The second is not peer reviewed yet and shows
>>>>>>> that the type of context matters.
>>>>>>> I don’t think the statement  “Note that the security properties
>>>>>>> depends on the type of context and the number of KeyUpdate
>>>>>>> iterations.” should be controversial. I avoided any detailed text
>>>>>>> that could be controversial.
>>>>>>> 
>>>>>>> One option could be to just skip the references. I really don’t
>>>>>>> need citations. But there are no other references to cite as far
>>>>>>> as I know. MLS and KUDOS use different types of context but does
>>>>>>> not say why. KUDOS likely added the random context for other
>>>>>>> reasons. MLS very likely added a counter for the reason to avoid
>>>>>>> short repetitive cycles. That is a very standard approach in
>>>>>>> cryptographic design.
>>>>>>> 
>>>>>>> An earlier version of the EDHOC document had the excellent text:
>>>>>>> “The EDHOC-KeyUpdate takes a nonce as input to guarantee that
>>>>>>> there are no short cycles.  The Initiator and the Responder need
>>>>>>> to agree on the nonce, which can e.g., be a counter or a random
>>>>>>> number.”
>>>>>>> My main priority is to publish the RFC. Companies that have
>>>>>>> already deployed EDHOC is eager for that. KeyUpdate is not so
>>>>>>> important, I don’t think anybody is planning on using it and the
>>>>>>> WG considered to completely remove it. If needed just skip any
>>>>>>> futher changes to the KeyUpdate section.
>>>>>>> Cheers,
>>>>>>> John
>>>>>>> From: Paul Wouters <paul.wouters=[e-mail]>
>>>>>>> Date: Saturday, 9 March 2024 at 16:18
>>>>>>> To: Alanna Paloma <[e-mail]>
>>>>>>> Cc: John Mattsson <[e-mail]>, Francesca
>>>>>>> Palombini <[e-mail]>, Sandy Ginoza
>>>>>>> <[e-mail]>, RFC Editor <[e-mail]>, Göran
>>>>>>> Selander <[e-mail]>, [e-mail] <lake-
>>>>>>> [e-mail]>, [e-mail] <[e-mail]>,
>>>>>>> [e-mail]<[e-mail]>,
>>>>>>> [e-mail] <[e-mail]>
>>>>>>> Subject: Re: [AD] Re: AUTH48: RFC-to-be 9528 <draft-ietf-lake-
>>>>>>> edhoc-23> for your review
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I do not approve of a single author adding two new references
>>>>>>> citing himself to the document in AUTH48, without a confirmation
>>>>>>> of the WG.
>>>>>>> 
>>>>>>> The other changes are fine.
>>>>>>> 
>>>>>>> Paul
>>>>>>> 
>>>>>>> Sent using a virtual keyboard on a phone
>>>>>>> 
>>>>>>>> On Mar 8, 2024, at 17:59, Alanna Paloma <[e-mail]>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> Hi John and Paul*,
>>>>>>>> 
>>>>>>>> *Paul - As the AD, please review and approve of the following
>>>>>>>> updates:
>>>>>>>> 
>>>>>>>> - Section 1.2: added text
>>>>>>>> - Section 6.3.1: updated text
>>>>>>>> - Appendix H: added text
>>>>>>>> 
>>>>>>>> John - Thank you for your reply. We have updated the files per
>>>>>>>> your request. Please see our notes below.
>>>>>>>> 
>>>>>>>> Additionally, your approval on the AUTH48 status page. We assume
>>>>>>>> assent to changes from your coauthors unless we hear otherwise.
>>>>>>>> 
>>>>>>>>> OLD:
>>>>>>>>>    +==========+===============+===============================+
>>>>>>>>>    | ERR_CODE | ERR_INFO Type | Description
>>>>>>>>> |
>>>>>>>>>    +==========+===============+===============================+
>>>>>>>>>    |        0 |               | Reserved
>>>>>>>>> |
>>>>>>>>>    +----------+---------------+-------------------------------
>>>>>>>>> +
>>>>>>>>>    |        1 | tstr          | Unspecified error
>>>>>>>>> |
>>>>>>>>>    +----------+---------------+-------------------------------
>>>>>>>>> +
>>>>>>>>>    |        2 | suites        | Wrong selected cipher suite
>>>>>>>>> |
>>>>>>>>>    +----------+---------------+-------------------------------
>>>>>>>>> +
>>>>>>>>>    |        3 | true          | Unknown credential referenced
>>>>>>>>> |
>>>>>>>>>    +----------+---------------+-------------------------------
>>>>>>>>> +
>>>>>>>>>    |       23 |               | Reserved
>>>>>>>>> |
>>>>>>>>>    +----------+---------------+-------------------------------
>>>>>>>>> +
>>>>>>>>> NEW:
>>>>>>>>>    +==========+===============+===============================+
>>>>>>>>>    | ERR_CODE | ERR_INFO Type | Description
>>>>>>>>> |
>>>>>>>>>    +==========+===============+===============================+
>>>>>>>>>    |        0 |               | Reserved for success
>>>>>>>>> |
>>>>>>>>>    +----------+---------------+-------------------------------
>>>>>>>>> +
>>>>>>>>>    |        1 | tstr          | Unspecified error
>>>>>>>>> |
>>>>>>>>>    +----------+---------------+-------------------------------
>>>>>>>>> +
>>>>>>>>>    |        2 | suites        | Wrong selected cipher suite
>>>>>>>>> |
>>>>>>>>>    +----------+---------------+-------------------------------
>>>>>>>>> +
>>>>>>>>>    |        3 | true          | Unknown credential referenced
>>>>>>>>> |
>>>>>>>>>    +----------+---------------+-------------------------------
>>>>>>>>> +
>>>>>>>>>    |       23 |               | Reserved
>>>>>>>>> |
>>>>>>>>>    +----------+---------------+-------------------------------
>>>>>>>>> +
>>>>>>>>> (I think it is good to differentiate the 0 reserved from the 23
>>>>>>>>> reserved)
>>>>>>>> 
>>>>>>>> ) Please note that this is not how it appears in the IANA
>>>>>>>> registry. Based on your reply, we have updated the document to
>>>>>>>> "Reserved for success" and will send a separate mail to request
>>>>>>>> that IANA update the registry
>>>>>>>> (https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fedhoc%2Fedhoc.xhtml%23edhoc-
>>>>>>>> error-
>>>>>>>> codes&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915925133%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=T8msrDujpbrdiIQZdFgUZpwC0iCF8AVZseJlJYTyBMU%3D&reserved=0)
>>>>>>>> accordingly.
>>>>>>>> 
>>>>>>>>> John: Unclear to me why only one of the rows has a reference to
>>>>>>>>> 9528.
>>>>>>>>> Feels like it should be none or all.
>>>>>>>>>      +-------------+------------------------------+-----------
>>>>>>>>> +
>>>>>>>>>     | 2-22        | Unassigned                   |           |
>>>>>>>>>     +-------------+------------------------------+-----------+
>>>>>>>>>     | 23          | Reserved                     | RFC 9528  |
>>>>>>>>>     +-------------+------------------------------+-----------+
>>>>>>>>>     | 24-32767    | Unassigned                   |           |
>>>>>>>>>     +-------------+------------------------------+-----------+
>>>>>>>>>     | 32768-65535 | Reserved for Private Use     |           |
>>>>>>>>>     +-------------+------------------------------+-----------+
>>>>>>>> 
>>>>>>>> ) This table matches how it appears in the IANA registry
>>>>>>>> (https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fedhoc%2Fedhoc.xhtml%23edhoc-
>>>>>>>> exporter-
>>>>>>>> labels&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915929275%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=c5ZrK4%2Bbjare9f8V1HOLtpaVLStK1CfRmRA9NTyXiCA%3D&reserved=0)
>>>>>>>> Typically, IANA registries do not list a reference for
>>>>>>>> unassigned values.
>>>>>>>> 
>>>>>>>>> OLD:
>>>>>>>>> | 3     | Array: 30,     | AES-CCM-16-128-128,         | RFC
>>>>>>>>> 9528  |
>>>>>>>>> |       | -16, 16, 1,    | SHA-256, 16, P-256, ES256,  |
>>>>>>>>> |
>>>>>>>>> |       | -7, 10, -16    | AES-CCM-16-64-128, SHA-256  |
>>>>>>>>> |
>>>>>>>>> +-------+----------------+-----------------------------
>>>>>>>>> +-----------+
>>>>>>>>> | 4     | Array: 24,     | ChaCha20/Poly1305, SHA-256, | RFC
>>>>>>>>> 9528  |
>>>>>>>>> |       | -16, 16, 4,    | 16, X25519, EdDSA,          |
>>>>>>>>> |
>>>>>>>>> |       | -8, 24, -16    | ChaCha20/Poly1305, SHA-256  |
>>>>>>>>> |
>>>>>>>>> NEW:
>>>>>>>>> | 3     | 30, -16, 16,   | AES-CCM-16-128-128,         | RFC
>>>>>>>>> 9528  |
>>>>>>>>> |       | 1, -7, 10, -16 | SHA-256, 16, P-256, ES256,  |
>>>>>>>>> |
>>>>>>>>> |       |                | AES-CCM-16-64-128, SHA-256  |
>>>>>>>>> |
>>>>>>>>> +-------+----------------+-----------------------------
>>>>>>>>> +-----------+
>>>>>>>>> | 4     | 24, -16, 16,   | ChaCha20/Poly1305, SHA-256, | RFC
>>>>>>>>> 9528  |
>>>>>>>>> |       | 4, -8, 24, -16 | 16, X25519, EdDSA,          |
>>>>>>>>> |
>>>>>>>>> |       |                | ChaCha20/Poly1305, SHA-256  |
>>>>>>>>> |
>>>>>>>>> (To align with the other rows)
>>>>>>>>> -----------
>>>>>>>> 
>>>>>>>> ) This has been udpated as requested (to remove "Array:"), which
>>>>>>>> matches the IANA registry. Our mistake for not catching that
>>>>>>>> earlier.
>>>>>>>> 
>>>>>>>>> *  by a hash value with the 'x5t' or 'c5t' parameters,
>>>>>>>>> respectively:
>>>>>>>>>   -  ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R and
>>>>>>>>>   -  ID_CRED_x = { TBD3 : COSE_CertHash }, for x = I or R,
>>>>>>>>> *  or by a URI with the 'x5u' or 'c5u' parameters,
>>>>>>>>> respectively:
>>>>>>>>>   -  ID_CRED_x = { 35 : uri }, for x = I or R, and
>>>>>>>>>   -  ID_CRED_x = { TBD4 : uri }, for x = I or R.
>>>>>>>>> John: TDB3 and TDB4 still exist in Appendix C.3
>>>>>>>> 
>>>>>>>> ) Once the values have been confirmed by the COSE chairs, we
>>>>>>>> will insert them into the document.
>>>>>>>> 
>>>>>>>>> OLD:
>>>>>>>>> The EDHOC_KeyUpdate takes the context as input to enable
>>>>>>>>> binding of
>>>>>>>>> the updated PRK_out to some event that triggered the key
>>>>>>>>> update.  The
>>>>>>>>> Initiator and Responder need to agree on the context, which
>>>>>>>>> can,
>>>>>>>>> e.g., be a counter, a pseudorandom number, or a hash.  To
>>>>>>>>> provide
>>>>>>>>> forward secrecy, the old PRK_out and keys derived from it (old
>>>>>>>>> PRK_exporter and old application keys) must be deleted as soon
>>>>>>>>> as
>>>>>>>>> they are not needed.  When to delete the old keys and how to
>>>>>>>>> verify
>>>>>>>>> that they are not needed is up to the application.
>>>>>>>>> NEW
>>>>>>>>> The EDHOC_KeyUpdate takes the context as input to enable
>>>>>>>>> binding of
>>>>>>>>> the updated PRK_out to some event that triggered the key
>>>>>>>>> update.  The
>>>>>>>>> Initiator and Responder need to agree on the context, which
>>>>>>>>> can,
>>>>>>>>> e.g., be a counter, a pseudorandom number, or a hash.  To
>>>>>>>>> provide
>>>>>>>>> forward secrecy, the old PRK_out and keys derived from it (old
>>>>>>>>> PRK_exporter and old application keys) must be deleted as soon
>>>>>>>>> as
>>>>>>>>> they are not needed.  When to delete the old keys and how to
>>>>>>>>> verify
>>>>>>>>> that they are not needed is up to the application. Note that
>>>>>>>>> the
>>>>>>>>> security properties depends on the type of context and the
>>>>>>>>> number
>>>>>>>>> of KeyUpdate iterations [1][2].
>>>>>>>>> [1]
>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D31323334-
>>>>>>>>> 501d5122-313273af-454445555731-
>>>>>>>>> dc22bfcd594b44db%26q%3D1%26e%3Ddf791691-0ab0-48aa-9818-
>>>>>>>>> b117e83cee3f%26u%3Dhttps%253A%252F%252Feprint.iacr.org%252F2023%252F913&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915933841%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2BE4e6hzn94jtfMhBhNh0z1DcpNVWnph4sHvUrtoNUA4%3D&reserved=0
>>>>>>>>> [2]
>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D31323334-
>>>>>>>>> 501d5122-313273af-454445555731-
>>>>>>>>> 238b27209f91355d%26q%3D1%26e%3Ddf791691-0ab0-48aa-9818-
>>>>>>>>> b117e83cee3f%26u%3Dhttps%253A%252F%252Feprint.iacr.org%252F2024%252F220&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915940176%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=fsIhY4Mv7eV9uYjxpDO6ItfrM6LuwLxt4dhPEgfTuIk%3D&reserved=0
>>>>>>>> 
>>>>>>>> ) As this document does not use numbered references, we have
>>>>>>>> added the following reference entries to the Informative
>>>>>>>> References sections.
>>>>>>>> 
>>>>>>>> [PreußMattsson23]
>>>>>>>>                 Preuß Mattsson, J., "Hidden Stream Ciphers and
>>>>>>>> TMTO
>>>>>>>>                 Attacks on TLS 1.3, DTLS 1.3, QUIC, and
>>>>>>>> Signal”,
>>>>>>>>                DOI 10.1007/978-981-99-7563-1_12, December 2023,
>>>>>>>>                <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D31323334-
>>>>>>>> 501d5122-313273af-454445555731-
>>>>>>>> dc22bfcd594b44db%26q%3D1%26e%3Ddf791691-0ab0-48aa-9818-
>>>>>>>> b117e83cee3f%26u%3Dhttps%253A%252F%252Feprint.iacr.org%252F2023%252F913&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915944717%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=fRHQ3gKoAzG%2BMtj%2BrEeiNoAOnnjrAwE5yaNPfO%2B94DE%3D&reserved=0>.
>>>>>>>> 
>>>>>>>> [PreußMattsson24]
>>>>>>>>                 Preuß Mattsson, J., "Security of Symmetric
>>>>>>>> Ratchets and
>>>>>>>>                 Key Chains - Implications for Protocols like
>>>>>>>> TLS 1.3,
>>>>>>>>                 Signal, and PQ3", February 2024,
>>>>>>>>                 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D31323334-
>>>>>>>> 501d5122-313273af-454445555731-
>>>>>>>> 238b27209f91355d%26q%3D1%26e%3Ddf791691-0ab0-48aa-9818-
>>>>>>>> b117e83cee3f%26u%3Dhttps%253A%252F%252Feprint.iacr.org%252F2024%252F220&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915949360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=FaH06DsKIgtR4KDJt5c9aFNgQJVbiVFgzk%2F5Rbggo9I%3D&reserved=0>.
>>>>>>>> ...
>>>>>>>> The files have been posted here (please refresh):
>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>> editor.org%2Fauthors%2Frfc9528.xml&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915953752%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ZVFubgX5o9sjfyACfi9y9mDp7bhdaTu9wP3fbhjCY%2Bk%3D&reserved=0
>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>> editor.org%2Fauthors%2Frfc9528.txt&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915958099%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=D6o3SspNLav2JCHgVwQh9X8Q5S%2BlWOlTmU%2BJh54XHqM%3D&reserved=0
>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>> editor.org%2Fauthors%2Frfc9528.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915962386%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=1vMDqbMeJZoNbUqJ8xfFM8nCnNI2uklM%2BL67MWSUwsk%3D&reserved=0
>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>> editor.org%2Fauthors%2Frfc9528.pdf&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915966592%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=I5i8O1V74ogYeg%2F0fvZpf3Sft5%2F3PP%2FJn%2FyDksn6qz4%3D&reserved=0
>>>>>>>> 
>>>>>>>> The relevant diff files have been posted here:
>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>> editor.org%2Fauthors%2Frfc9528-
>>>>>>>> diff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915970818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=F90HfllY5OfaykHupAdFIVDfsrTXSwC2U9bceHvz1oI%3D&reserved=0
>>>>>>>> (comprehensive diff)
>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>> editor.org%2Fauthors%2Frfc9528-
>>>>>>>> auth48diff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915975078%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=63E0VIfVV1ZIDfOxzkOOdI1VPmXEkTaMQPKr4HmM2iQ%3D&reserved=0
>>>>>>>> (AUTH48 changes)
>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>> editor.org%2Fauthors%2Frfc9528-
>>>>>>>> lastdiff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915979294%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=8U%2BqAuKPhzz9uKaktor0jc1qd7DO6KHmqfClIRZOFWQ%3D&reserved=0
>>>>>>>> (htmlwdiff diff between last version and this)
>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>> editor.org%2Fauthors%2Frfc9528-
>>>>>>>> lastrfcdiff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915983513%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=utML07TG4g6QstzcSOerRA9zjHzw%2BHmW5Fl7gUKVC7g%3D&reserved=0
>>>>>>>> (rfcdiff between last version and this)
>>>>>>>> 
>>>>>>>> For the AUTH48 status of this document, please see:
>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>> editor.org%2Fauth48%2Frfc9528&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915987708%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=2HlFleo7fBcPUmDgx8X9AVTr%2BdZLE6WiLRrKo2vidHQ%3D&reserved=0
>>>>>>>> 
>>>>>>>> Thank you,
>>>>>>>> RFC Editor/ap
>>>>>>>> 
>>>>>>>>> On Mar 8, 2024, at 6:10 AM, John Mattsson
>>>>>>>>> <john.mattsson=[e-mail]> wrote:
>>>>>>>>> 
>>>>>>>>> Dear RFC Editor,I have reviewed the whole document in detail. I
>>>>>>>>> have the suggestions below:
>>>>>>>>> I approve publication.
>>>>>>>>> -----------
>>>>>>>>> OLD: ERR_CODE is sn error code encoded as an integer.
>>>>>>>>> NEW: ERR_CODE is an error code encoded as an integer.
>>>>>>>>> -----------
>>>>>>>>> OLD: Based on the cryptographic algorithms requirements
>>>>>>>>> NEW: Based on the cryptographic algorithm requirements
>>>>>>>>> -----------
>>>>>>>>> OLD:Any dependencies on security applications with previously
>>>>>>>>> registered EAD items needs to be documented
>>>>>>>>> NEW:Any dependencies on security applications with previously
>>>>>>>>> registered EAD items need to be documented
>>>>>>>>> -----------
>>>>>>>>> OLD: high performance algorithms
>>>>>>>>> NEW: high-performance algorithms
>>>>>>>>> -----------
>>>>>>>>> OLD:
>>>>>>>>> Examples of EDHOC message sizes are shown in Table 1, which
>>>>>>>>> use
>>>>>>>>> different kinds of authentication keys and COSE header
>>>>>>>>> parameters for
>>>>>>>>> identification, i.e., static Diffie-Hellman keys or signature
>>>>>>>>> keys,
>>>>>>>>> either in CWT/CCS [RFC8392] identified by a key identifier
>>>>>>>>> using
>>>>>>>>> 'kid' [RFC9052] or in X.509 certificates identified by a hash
>>>>>>>>> value
>>>>>>>>> using 'x5t' [RFC9360]. As a comparison, in the case of RPK
>>>>>>>>> NEW:
>>>>>>>>> Examples of EDHOC message sizes are shown in Table 1, which use
>>>>>>>>> different kinds of authentication keys and COSE header
>>>>>>>>> parameters for
>>>>>>>>> identification, i.e., static Diffie-Hellman keys or signature
>>>>>>>>> keys,
>>>>>>>>> either in CWT/CCS [RFC8392] identified by a key identifier
>>>>>>>>> using
>>>>>>>>> 'kid' [RFC9052] or in X.509 certificates identified by a hash
>>>>>>>>> value
>>>>>>>>> using 'x5t' [RFC9360]. EDHOC always uses ephemeral-ephemeral
>>>>>>>>> key exchange.
>>>>>>>>> As a comparison, in the case of RPK
>>>>>>>>> (clarification to avoid misunderstanding such as the secdir
>>>>>>>>> review)
>>>>>>>>> -----------
>>>>>>>>> OLD:
>>>>>>>>> SIGn-and-MAc (SIGMA) is a family of theoretical protocols with
>>>>>>>>> a
>>>>>>>>> large number of variants [SIGMA].
>>>>>>>>> NEW:
>>>>>>>>> SIGn-and-MAc (SIGMA) is a family of theoretical protocols with
>>>>>>>>> a
>>>>>>>>> number of variants [SIGMA].
>>>>>>>>> (large number is maybe overstating it)
>>>>>>>>> -----------
>>>>>>>>> OLD: passed by the value are used as is without re-encoding.
>>>>>>>>> NEW: passed by value are used as is without re-encoding.
>>>>>>>>> ("by value" is the standard term used in other parts of the
>>>>>>>>> document.)
>>>>>>>>> -----------
>>>>>>>>> OLD:
>>>>>>>>> EDHOC since the authentication credentials are integrity
>>>>>>>>> protected.
>>>>>>>>> NEW:
>>>>>>>>> EDHOC since the authentication credentials are integrity
>>>>>>>>> protected
>>>>>>>>> by the Signature_or_MAC field.
>>>>>>>>> (Clarification. The paragraph also talks about that the
>>>>>>>>> credential is transported to the endpoints)
>>>>>>>>> -----------
>>>>>>>>> OLD: (when with public key cryptography)
>>>>>>>>> NEW: (when used with public key cryptography)
>>>>>>>>> -----------
>>>>>>>>> OLD:
>>>>>>>>>    +==========+===============+===============================+
>>>>>>>>>    | ERR_CODE | ERR_INFO Type | Description
>>>>>>>>> |
>>>>>>>>>    +==========+===============+===============================+
>>>>>>>>>    |        0 |               | Reserved
>>>>>>>>> |
>>>>>>>>>    +----------+---------------+-------------------------------
>>>>>>>>> +
>>>>>>>>>    |        1 | tstr          | Unspecified error
>>>>>>>>> |
>>>>>>>>>    +----------+---------------+-------------------------------
>>>>>>>>> +
>>>>>>>>>    |        2 | suites        | Wrong selected cipher suite
>>>>>>>>> |
>>>>>>>>>    +----------+---------------+-------------------------------
>>>>>>>>> +
>>>>>>>>>    |        3 | true          | Unknown credential referenced
>>>>>>>>> |
>>>>>>>>>    +----------+---------------+-------------------------------
>>>>>>>>> +
>>>>>>>>>    |       23 |               | Reserved
>>>>>>>>> |
>>>>>>>>>    +----------+---------------+-------------------------------
>>>>>>>>> +
>>>>>>>>> NEW:
>>>>>>>>>    +==========+===============+===============================+
>>>>>>>>>    | ERR_CODE | ERR_INFO Type | Description
>>>>>>>>> |
>>>>>>>>>    +==========+===============+===============================+
>>>>>>>>>    |        0 |               | Reserved for success
>>>>>>>>> |
>>>>>>>>>    +----------+---------------+-------------------------------
>>>>>>>>> +
>>>>>>>>>    |        1 | tstr          | Unspecified error
>>>>>>>>> |
>>>>>>>>>    +----------+---------------+-------------------------------
>>>>>>>>> +
>>>>>>>>>    |        2 | suites        | Wrong selected cipher suite
>>>>>>>>> |
>>>>>>>>>    +----------+---------------+-------------------------------
>>>>>>>>> +
>>>>>>>>>    |        3 | true          | Unknown credential referenced
>>>>>>>>> |
>>>>>>>>>    +----------+---------------+-------------------------------
>>>>>>>>> +
>>>>>>>>>    |       23 |               | Reserved
>>>>>>>>> |
>>>>>>>>>    +----------+---------------+-------------------------------
>>>>>>>>> +
>>>>>>>>> (I think it is good to differentiate the 0 reserved from the 23
>>>>>>>>> reserved)
>>>>>>>>> -----------
>>>>>>>>> OLD:
>>>>>>>>> If the Initiator intends to contact the Responder in the
>>>>>>>>> future, the
>>>>>>>>> Initiator SHOULD remember which selected cipher suite to use
>>>>>>>>> until
>>>>>>>>> the next message_1 has been sent; otherwise, the Initiator and
>>>>>>>>> Responder will likely run into an infinite loop where the
>>>>>>>>> Initiator
>>>>>>>>> selects its most preferred cipher suite and the Responder sends
>>>>>>>>> an
>>>>>>>>> error with supported cipher suites.  After a completed EDHOC
>>>>>>>>> session,
>>>>>>>>> the Initiator MAY remember the selected cipher suite to use in
>>>>>>>>> future
>>>>>>>>> EDHOC sessions.
>>>>>>>>> NEW:
>>>>>>>>> The Initiator need to remember which selected cipher suite to
>>>>>>>>> use until
>>>>>>>>> the next message_1 has been sent; otherwise, the Initiator and
>>>>>>>>> Responder will run into an infinite loop where the Initiator
>>>>>>>>> selects its most preferred cipher suite and the Responder sends
>>>>>>>>> an
>>>>>>>>> error with supported cipher suites.  After a completed EDHOC
>>>>>>>>> session,
>>>>>>>>> the Initiator MAY remember the selected cipher suite to use in
>>>>>>>>> future
>>>>>>>>> EDHOC sessions.
>>>>>>>>> (I think this paragraph is quite confusing and needs to be
>>>>>>>>> improved.)
>>>>>>>>> -----------
>>>>>>>>> OLD:
>>>>>>>>> The same authentication credential MAY be used for both the
>>>>>>>>> Initiator
>>>>>>>>> and Responder roles.  As noted in Section 12 of [RFC9052], the
>>>>>>>>> use of
>>>>>>>>> a single key for multiple algorithms is strongly discouraged
>>>>>>>>> unless
>>>>>>>>> proven secure by a dedicated cryptographic analysis.  In
>>>>>>>>> particular,
>>>>>>>>> this recommendation applies to using the same private key for
>>>>>>>>> static
>>>>>>>>> Diffie-Hellman authentication and digital signature
>>>>>>>>> authentication.
>>>>>>>>> A preliminary conjecture is that a minor change to EDHOC may be
>>>>>>>>> sufficient to fit the analysis of a secure shared signature and
>>>>>>>>> ECDH
>>>>>>>>> key usage in [Degabriele11] and [Thormarker21].
>>>>>>>>> NEW:
>>>>>>>>> The same authentication credential MAY be used for both the
>>>>>>>>> Initiator
>>>>>>>>> and Responder roles.  As noted in Section 12 of [RFC9052], the
>>>>>>>>> use of
>>>>>>>>> a single key for multiple algorithms is strongly discouraged
>>>>>>>>> unless
>>>>>>>>> proven secure by a dedicated cryptographic analysis.  In
>>>>>>>>> particular,
>>>>>>>>> this recommendation applies to using the same private key for
>>>>>>>>> static
>>>>>>>>> Diffie-Hellman authentication and digital signature
>>>>>>>>> authentication.
>>>>>>>>> A preliminary conjecture is that a minor change to EDHOC may be
>>>>>>>>> sufficient to fit the analysis of a secure shared signature and
>>>>>>>>> ECDH
>>>>>>>>> key usage in [Degabriele11] and [Thormarker21]. Note that
>>>>>>>>> Section
>>>>>>>>> 5.6.3.2 of [SP-800-56A] allows a key agreement key pair to be
>>>>>>>>> used
>>>>>>>>> with a signature algorithm in certificate requests.
>>>>>>>>> (I think the added piece of information is very important for
>>>>>>>>> users
>>>>>>>>> of the document. Otherwise they might get the idea that this
>>>>>>>>> cannot be
>>>>>>>>> done. The new sentence just notes that NIST allows this.)
>>>>>>>>> -----------
>>>>>>>>> OLD: [DET-ECC-SIGS]
>>>>>>>>> OLD: [HEDGED-ECC-SIGS]
>>>>>>>>> (The CFRG draft has changes name. Also DET-ECC-SIGS gives the
>>>>>>>>> wrong idea.)
>>>>>>>>> -----------
>>>>>>>>> John: Unclear to me why only one of the rows has a reference to
>>>>>>>>> 9528.
>>>>>>>>> Feels like it should be none or all.
>>>>>>>>>      +-------------+------------------------------+-----------
>>>>>>>>> +
>>>>>>>>>     | 2-22        | Unassigned                   |           |
>>>>>>>>>     +-------------+------------------------------+-----------+
>>>>>>>>>     | 23          | Reserved                     | RFC 9528  |
>>>>>>>>>     +-------------+------------------------------+-----------+
>>>>>>>>>     | 24-32767    | Unassigned                   |           |
>>>>>>>>>     +-------------+------------------------------+-----------+
>>>>>>>>>     | 32768-65535 | Reserved for Private Use     |           |
>>>>>>>>>     +-------------+------------------------------+-----------+
>>>>>>>>> -----------
>>>>>>>>> OLD:
>>>>>>>>> | 3     | Array: 30,     | AES-CCM-16-128-128,         | RFC
>>>>>>>>> 9528  |
>>>>>>>>> |       | -16, 16, 1,    | SHA-256, 16, P-256, ES256,  |
>>>>>>>>> |
>>>>>>>>> |       | -7, 10, -16    | AES-CCM-16-64-128, SHA-256  |
>>>>>>>>> |
>>>>>>>>> +-------+----------------+-----------------------------
>>>>>>>>> +-----------+
>>>>>>>>> | 4     | Array: 24,     | ChaCha20/Poly1305, SHA-256, | RFC
>>>>>>>>> 9528  |
>>>>>>>>> |       | -16, 16, 4,    | 16, X25519, EdDSA,          |
>>>>>>>>> |
>>>>>>>>> |       | -8, 24, -16    | ChaCha20/Poly1305, SHA-256  |
>>>>>>>>> |
>>>>>>>>> NEW:
>>>>>>>>> | 3     | 30, -16, 16,   | AES-CCM-16-128-128,         | RFC
>>>>>>>>> 9528  |
>>>>>>>>> |       | 1, -7, 10, -16 | SHA-256, 16, P-256, ES256,  |
>>>>>>>>> |
>>>>>>>>> |       |                | AES-CCM-16-64-128, SHA-256  |
>>>>>>>>> |
>>>>>>>>> +-------+----------------+-----------------------------
>>>>>>>>> +-----------+
>>>>>>>>> | 4     | 24, -16, 16,   | ChaCha20/Poly1305, SHA-256, | RFC
>>>>>>>>> 9528  |
>>>>>>>>> |       | 4, -8, 24, -16 | 16, X25519, EdDSA,          |
>>>>>>>>> |
>>>>>>>>> |       |                | ChaCha20/Poly1305, SHA-256  |
>>>>>>>>> |
>>>>>>>>> (To align with the other rows)
>>>>>>>>> -----------
>>>>>>>>> OLD:
>>>>>>>>> [SP-800-108]
>>>>>>>>>           Chen, L., "Recommendation for Key Derivation Using
>>>>>>>>>           Pseudorandom Functions", NIST Special Publication
>>>>>>>>> 800-108
>>>>>>>>>           Revision 1, DOI 10.6028/NIST.SP.800-108r1, August
>>>>>>>>> 2022,
>>>>>>>>>           <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoi.org%2F10.6028%2FNIST.SP.800-
>>>>>>>>> 108r1&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915991941%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=1%2Fk6%2FnEC4KoCyUUmX3fWwYDps1gRNm3zhUAwssWiibw%3D&reserved=0>.
>>>>>>>>> NEW:
>>>>>>>>> [SP-800-108]
>>>>>>>>>           Chen, L., "Recommendation for Key Derivation Using
>>>>>>>>>           Pseudorandom Functions", NIST Special Publication
>>>>>>>>> 800-108
>>>>>>>>>           Revision 1, DOI 10.6028/NIST.SP.800-108r1-upd1,
>>>>>>>>> August 2022,
>>>>>>>>>           <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoi.org%2F10.6028%2FNIST.SP.800-
>>>>>>>>> 108r1-
>>>>>>>>> upd1&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331915996135%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=k06%2F3D0DWNBAG2qLhHRyGGlOhSqS2UJKFMo%2FCHuSMg8%3D&reserved=0>.
>>>>>>>>> (NIST has done a very minor update to the SP)
>>>>>>>>> -----------
>>>>>>>>> OLD:
>>>>>>>>> A full validation according to Section 5.6.2.3.3 of
>>>>>>>>> [SP-800-56A] can be achieved by also checking that 0 ≤ x < p
>>>>>>>>> and that
>>>>>>>>> y^2 ≡ x^3 + a ⋅ x + b (mod p).
>>>>>>>>> NEW:
>>>>>>>>> A full validation according to Section 5.6.2.3.3 of
>>>>>>>>> [SP-800-56A] is done by also checking that 0 ≤ x < p and that
>>>>>>>>> y^2 ≡ x^3 + a ⋅ x + b (mod p).
>>>>>>>>> (Comment from Scott in TLS WG that the original text makes it
>>>>>>>>> unclear
>>>>>>>>> if validation needs to be done)
>>>>>>>>> -----------
>>>>>>>>> *  by a hash value with the 'x5t' or 'c5t' parameters,
>>>>>>>>> respectively:
>>>>>>>>>   -  ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R and
>>>>>>>>>   -  ID_CRED_x = { TBD3 : COSE_CertHash }, for x = I or R,
>>>>>>>>> *  or by a URI with the 'x5u' or 'c5u' parameters,
>>>>>>>>> respectively:
>>>>>>>>>   -  ID_CRED_x = { 35 : uri }, for x = I or R, and
>>>>>>>>>   -  ID_CRED_x = { TBD4 : uri }, for x = I or R.
>>>>>>>>> John: TDB3 and TDB4 still exist in Appendix C.3
>>>>>>>>> -----------
>>>>>>>>> OLD:
>>>>>>>>> When EDHOC_KeyUpdate is called, a new PRK_out is calculated as
>>>>>>>>> a
>>>>>>>>> "hash" of the old PRK_out using the EDHOC_Expand function as
>>>>>>>>> illustrated by the following pseudocode.  The change of PRK_out
>>>>>>>>> causes a change to PRK_exporter, which enables the derivation
>>>>>>>>> of new
>>>>>>>>> application keys superseding the old ones, using
>>>>>>>>> EDHOC_Exporter; see
>>>>>>>>> Section 4.2.1.
>>>>>>>>> NEW:
>>>>>>>>> When EDHOC_KeyUpdate is called, a new PRK_out is calculated as
>>>>>>>>> the output of the EDHOC_Expand function with the old PRK_out as
>>>>>>>>> input. The change of PRK_out causes a change to PRK_exporter,
>>>>>>>>> which enables the derivation of new application keys
>>>>>>>>> superseding
>>>>>>>>> the old ones, using EDHOC_Exporter; see Section 4.2.1. The
>>>>>>>>> process is illustrated by the following pseudocode.
>>>>>>>>> (I think it is good to remove "hash" as that that has the worst
>>>>>>>>> security properties. Also I think it is good to have the
>>>>>>>>> pseudocode
>>>>>>>>> sentence last in the paragraph.)
>>>>>>>>> -----------
>>>>>>>>> OLD:
>>>>>>>>> The EDHOC_KeyUpdate takes the context as input to enable
>>>>>>>>> binding of
>>>>>>>>> the updated PRK_out to some event that triggered the key
>>>>>>>>> update.  The
>>>>>>>>> Initiator and Responder need to agree on the context, which
>>>>>>>>> can,
>>>>>>>>> e.g., be a counter, a pseudorandom number, or a hash.  To
>>>>>>>>> provide
>>>>>>>>> forward secrecy, the old PRK_out and keys derived from it (old
>>>>>>>>> PRK_exporter and old application keys) must be deleted as soon
>>>>>>>>> as
>>>>>>>>> they are not needed.  When to delete the old keys and how to
>>>>>>>>> verify
>>>>>>>>> that they are not needed is up to the application.
>>>>>>>>> NEW
>>>>>>>>> The EDHOC_KeyUpdate takes the context as input to enable
>>>>>>>>> binding of
>>>>>>>>> the updated PRK_out to some event that triggered the key
>>>>>>>>> update.  The
>>>>>>>>> Initiator and Responder need to agree on the context, which
>>>>>>>>> can,
>>>>>>>>> e.g., be a counter, a pseudorandom number, or a hash.  To
>>>>>>>>> provide
>>>>>>>>> forward secrecy, the old PRK_out and keys derived from it (old
>>>>>>>>> PRK_exporter and old application keys) must be deleted as soon
>>>>>>>>> as
>>>>>>>>> they are not needed.  When to delete the old keys and how to
>>>>>>>>> verify
>>>>>>>>> that they are not needed is up to the application. Note that
>>>>>>>>> the
>>>>>>>>> security properties depends on the type of context and the
>>>>>>>>> number
>>>>>>>>> of KeyUpdate iterations [1][2].
>>>>>>>>> [1]
>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D31323334-
>>>>>>>>> 501d5122-313273af-454445555731-
>>>>>>>>> dc22bfcd594b44db%26q%3D1%26e%3Ddf791691-0ab0-48aa-9818-
>>>>>>>>> b117e83cee3f%26u%3Dhttps%253A%252F%252Feprint.iacr.org%252F2023%252F913&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916000226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=f4%2B6ktMoCXI8AewtMalTEIK%2FU%2BcpLTnXDrz0QWwzb7E%3D&reserved=0
>>>>>>>>> [2]
>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D31323334-
>>>>>>>>> 501d5122-313273af-454445555731-
>>>>>>>>> 238b27209f91355d%26q%3D1%26e%3Ddf791691-0ab0-48aa-9818-
>>>>>>>>> b117e83cee3f%26u%3Dhttps%253A%252F%252Feprint.iacr.org%252F2024%252F220&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916004531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=8B%2FMpkqSVLpt453glAzQ753XiYWCGdLXVr9Pp8C%2Bf5c%3D&reserved=0
>>>>>>>>> -----------
>>>>>>>>> Cheers,
>>>>>>>>> John Preuß Mattsson
>>>>>>>>> From: Francesca Palombini
>>>>>>>>> <francesca.palombini=[e-mail]>
>>>>>>>>> Date: Friday, 8 March 2024 at 08:43
>>>>>>>>> To: Sandy Ginoza <[e-mail]>
>>>>>>>>> Cc: John Mattsson <[e-mail]>, RFC Editor
>>>>>>>>> <[e-mail]>, Göran Selander
>>>>>>>>> <[e-mail]>, [e-mail] <lake-
>>>>>>>>> [e-mail]>, [e-mail] <[e-mail]>,
>>>>>>>>> [e-mail]
>>>>>>>>> <[e-mail]>,[e-mail]
>>>>>>>>> <[e-mail]>, auth48archive@rfc-
>>>>>>>>> editor.org<[e-mail]>
>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9528 <draft-ietf-lake-edhoc-23>
>>>>>>>>> for your review
>>>>>>>>> Hi Sandy!
>>>>>>>>> (with my author’s hat on only, of course) I understand, thank
>>>>>>>>> you for the heads up. I am reviewing RFC 7120 and realize we
>>>>>>>>> missed one step, we requested the AD and IANA for early
>>>>>>>>> allocation, but missed the COSE chairs. My co-authors are also
>>>>>>>>> authors of the COSE draft, and they believe it to be stable
>>>>>>>>> enough, so does the IANA expert who has reviewed the
>>>>>>>>> registration. But of course we welcome feedback from the
>>>>>>>>> chairs.
>>>>>>>>> Thank you for keeping us updated,
>>>>>>>>> Francesca
>>>>>>>>> From: Sandy Ginoza <[e-mail]>
>>>>>>>>> Date: Thursday, 7 March 2024 at 23:37
>>>>>>>>> To: Francesca Palombini <[e-mail]>
>>>>>>>>> Cc: John Mattsson
>>>>>>>>> <john.mattsson=[e-mail]>, RFC Editor <rfc-
>>>>>>>>> [e-mail]>, Göran Selander
>>>>>>>>> <[e-mail]>, [e-mail] <lake-
>>>>>>>>> [e-mail]>, [e-mail] <[e-mail]>,
>>>>>>>>> [e-mail]<[e-mail]>,
>>>>>>>>> [e-mail] <[e-mail]>,
>>>>>>>>> [e-mail] <[e-mail]>
>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9528 <draft-ietf-lake-edhoc-23>
>>>>>>>>> for your review
>>>>>>>>> Hi Francesca, Authors,
>>>>>>>>> 
>>>>>>>>> We generally try to avoid including TBDs and IANA assignments
>>>>>>>>> for documents that have yet to be published because things may
>>>>>>>>> change before the defining document is approved for
>>>>>>>>> publication.  In this case, the state of draft-ietf-cose-cbor-
>>>>>>>>> encoded-cert appears to be I-D exists, which seems to imply
>>>>>>>>> it’s not yet stable.
>>>>>>>>> 
>>>>>>>>> Note that we just received mail from IANA asking us to
>>>>>>>>> temporarily delay updating these values because there is an
>>>>>>>>> issue they are discussing with the WG Chairs.  Note that we
>>>>>>>>> have reverted the values to TBDs per IANA’s request.
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Sandy
>>>>>>>>> 
>>>>>>>>>>> On Mar 7, 2024, at 12:16 PM, Alanna Paloma <[e-mail]>
>>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hi Francesca,
>>>>>>>>>> 
>>>>>>>>>> Thank you for the update. We have updated the files with the
>>>>>>>>>> new values.
>>>>>>>>>> 
>>>>>>>>>> The files have been posted here (please refresh):
>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>> editor.org%2Fauthors%2Frfc9528.xml&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916008891%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=aQGcqH7HmlabFMb8mzFsIGNGr184Hn9pab2DmBl8mGQ%3D&reserved=0
>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>> editor.org%2Fauthors%2Frfc9528.txt&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916013210%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=hnTO%2F%2FxCXxea6gNtzOAGG7TBjPqK%2FpBvUwd41noy75E%3D&reserved=0
>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>> editor.org%2Fauthors%2Frfc9528.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916017397%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=w1zaZ5GrzJ08%2F%2BclyF22yaoWYcmzCaYATTPRlB4UEbQ%3D&reserved=0
>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>> editor.org%2Fauthors%2Frfc9528.pdf&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916021573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=xRyM%2BxW6y1cE1OSkN%2FO252ncsccH6lsQ3Ae3w5E0waY%3D&reserved=0
>>>>>>>>>> 
>>>>>>>>>> The relevant diff files have been posted here:
>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>> editor.org%2Fauthors%2Frfc9528-
>>>>>>>>>> diff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916025743%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=mnwZ%2B9l%2BSnEf%2FKjRQj3uirSxBVxIdxcGE9VBggTGdVY%3D&reserved=0
>>>>>>>>>> (comprehensive diff)
>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>> editor.org%2Fauthors%2Frfc9528-
>>>>>>>>>> auth48diff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916029927%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=B7Y1W%2FEQtjLthNOUmhRZEc2bw5bxTZ%2FFWR6IpMn5GXk%3D&reserved=0
>>>>>>>>>> (AUTH48 changes)
>>>>>>>>>> 
>>>>>>>>>> Thank you,
>>>>>>>>>> RFC Editor/ap
>>>>>>>>>> 
>>>>>>>>>>> On Mar 7, 2024, at 11:50 AM, Francesca Palombini
>>>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hi Alanna,
>>>>>>>>>>> The values were just assigned today, thanks to Paul and IANA,
>>>>>>>>>>> so we don’t need to have TBDs anymore but we can replace them
>>>>>>>>>>> with the actual values. We can make the following change:
>>>>>>>>>>> OLD:
>>>>>>>>>>> Different header parameters to identify X.509 or C509
>>>>>>>>>>> certificates by
>>>>>>>>>>> reference are defined in [RFC9360] and
>>>>>>>>>>> [I-D.ietf-cose-cbor-encoded-cert]:
>>>>>>>>>>> *  by a hash value with the 'x5t' or 'c5t' parameters,
>>>>>>>>>>> respectively:
>>>>>>>>>>>  -  ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R,
>>>>>>>>>>>  -  ID_CRED_x = { TBD3 : COSE_CertHash }, for x = I or R;
>>>>>>>>>>> *  or by a URI with the 'x5u' or 'c5u' parameters,
>>>>>>>>>>> respectively:
>>>>>>>>>>>  -  ID_CRED_x = { 35 : uri }, for x = I or R,
>>>>>>>>>>>  -  ID_CRED_x = { TBD4 : uri }, for x = I or R.
>>>>>>>>>>> NEW:
>>>>>>>>>>> Different header parameters to identify X.509 or C509
>>>>>>>>>>> certificates by
>>>>>>>>>>> reference are defined in [RFC9360] and
>>>>>>>>>>> [I-D.ietf-cose-cbor-encoded-cert]:
>>>>>>>>>>> 
>>>>>>>>>>> *  by a hash value with the 'x5t' or 'c5t' parameters,
>>>>>>>>>>> respectively:
>>>>>>>>>>> 
>>>>>>>>>>> -  ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R,
>>>>>>>>>>> 
>>>>>>>>>>> -  ID_CRED_x = { 22 : COSE_CertHash }, for x = I or R;
>>>>>>>>>>> 
>>>>>>>>>>> *  or by a URI with the 'x5u' or 'c5u' parameters,
>>>>>>>>>>> respectively:
>>>>>>>>>>> 
>>>>>>>>>>> -  ID_CRED_x = { 35 : uri }, for x = I or R,
>>>>>>>>>>> 
>>>>>>>>>>> -  ID_CRED_x = { 23 : uri }, for x = I or R.
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Francesca
>>>>>>>>>>> From: Alanna Paloma <[e-mail]>
>>>>>>>>>>> Date: Thursday, 7 March 2024 at 20:27
>>>>>>>>>>> To: John Mattsson
>>>>>>>>>>> <john.mattsson=[e-mail]>
>>>>>>>>>>> Cc: [e-mail] <[e-mail]>,
>>>>>>>>>>> Göran Selander <[e-mail]>, Francesca
>>>>>>>>>>> Palombini <[e-mail]>, lake-
>>>>>>>>>>> [e-mail] <[e-mail]>, [e-mail] <lake-
>>>>>>>>>>> [e-mail]>, [e-mail]
>>>>>>>>>>> <[e-mail]>,
>>>>>>>>>>> [e-mail]<[e-mail]>,
>>>>>>>>>>> [e-mail] <[e-mail]>
>>>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9528 <draft-ietf-lake-edhoc-
>>>>>>>>>>> 23> for your review
>>>>>>>>>>> Hi John,
>>>>>>>>>>> 
>>>>>>>>>>> Thank you for your reply.  The files have been updated. We
>>>>>>>>>>> have one follow-up question.
>>>>>>>>>>> 
>>>>>>>>>>> RFCs are typically not published if they contain unassigned
>>>>>>>>>>> values. So, to avoid the use of unassigned values (TBD3 and
>>>>>>>>>>> TBD4), may those lines in the examples in Appendix C.3 be
>>>>>>>>>>> removed? Or, can they be replaced with different examples
>>>>>>>>>>> that use existing values?
>>>>>>>>>>> 
>>>>>>>>>>> Original:
>>>>>>>>>>> Different header parameters to identify X.509 or C509
>>>>>>>>>>> certificates by
>>>>>>>>>>> reference are defined in [RFC9360] and
>>>>>>>>>>> [I-D.ietf-cose-cbor-encoded-cert]:
>>>>>>>>>>> 
>>>>>>>>>>> *  by a hash value with the 'x5t' or 'c5t' parameters,
>>>>>>>>>>> respectively:
>>>>>>>>>>> 
>>>>>>>>>>> -  ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R,
>>>>>>>>>>> 
>>>>>>>>>>> -  ID_CRED_x = { TBD3 : COSE_CertHash }, for x = I or R;
>>>>>>>>>>> 
>>>>>>>>>>> *  or by a URI with the 'x5u' or 'c5u' parameters,
>>>>>>>>>>> respectively:
>>>>>>>>>>> 
>>>>>>>>>>> -  ID_CRED_x = { 35 : uri }, for x = I or R,
>>>>>>>>>>> 
>>>>>>>>>>> -  ID_CRED_x = { TBD4 : uri }, for x = I or R.
>>>>>>>>>>> 
>>>>>>>>>>> Perhaps:
>>>>>>>>>>> Different header parameters to identify X.509 or C509
>>>>>>>>>>> certificates by
>>>>>>>>>>> reference are defined in [RFC9360] and [C509-CERTS]:
>>>>>>>>>>> 
>>>>>>>>>>> * by a hash value with the 'x5t' or 'c5t' parameters,
>>>>>>>>>>> respectively:
>>>>>>>>>>> 
>>>>>>>>>>> - ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R,
>>>>>>>>>>> 
>>>>>>>>>>> * or by a URI with the 'x5u' or 'c5u' parameters,
>>>>>>>>>>> respectively:
>>>>>>>>>>> 
>>>>>>>>>>> - ID_CRED_x = { 35 : uri }, for x = I or R.
>>>>>>>>>>> 
>>>>>>>>>>> ...
>>>>>>>>>>> The files have been posted here (please refresh):
>>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>> editor.org%2Fauthors%2Frfc9528.xml&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916034226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=4LnLNTtpzqqFBIBpa7ZoVPRjwmVaDD4Nz2ugW0pw5Zg%3D&reserved=0
>>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>> editor.org%2Fauthors%2Frfc9528.txt&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916038447%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=S9RSVo%2FAFbFCX02eF88vPtTaYUTLSOatUdlI3xMSXvQ%3D&reserved=0
>>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>> editor.org%2Fauthors%2Frfc9528.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916042604%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=tffX3NOhyzfn7hYzdyaK%2Fy%2FJHUoeO90BUmhT5u74%2BgY%3D&reserved=0
>>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>> editor.org%2Fauthors%2Frfc9528.pdf&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916046710%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=IT3bbQ2TvedAbq7cCr%2FEO4aljEC%2FtrrwdqSecD3pxuQ%3D&reserved=0
>>>>>>>>>>> 
>>>>>>>>>>> The relevant diff files have been posted here:
>>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>> editor.org%2Fauthors%2Frfc9528-
>>>>>>>>>>> diff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916050874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=NsYJz7seopPmghmqMsdKb%2FNwQtGzs8O89xfblQJQULU%3D&reserved=0
>>>>>>>>>>> (comprehensive diff)
>>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>> editor.org%2Fauthors%2Frfc9528-
>>>>>>>>>>> auth48diff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916055002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Hs8hMRTG%2BbJNNTb%2FfdiKJ%2BJdrtn0eWkuDdv69yTx148%3D&reserved=0
>>>>>>>>>>> (AUTH48 changes)
>>>>>>>>>>> 
>>>>>>>>>>> Please review the document carefully and contact us with any
>>>>>>>>>>> further updates you may have.  Note that we do not make
>>>>>>>>>>> changes once a document is published as an RFC.
>>>>>>>>>>> 
>>>>>>>>>>> We will await approvals from each party listed on the AUTH48
>>>>>>>>>>> status page below prior to moving this document forward in
>>>>>>>>>>> the publication process.
>>>>>>>>>>> 
>>>>>>>>>>> For the AUTH48 status of this document, please see:
>>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>> editor.org%2Fauth48%2Frfc9528&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916059250%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=c%2FmEgyyBE7%2BEiHv3oF0%2B026WPUabLc57Z6SJnh4nkQc%3D&reserved=0
>>>>>>>>>>> 
>>>>>>>>>>> Thank you,
>>>>>>>>>>> RFC Editor/ap
>>>>>>>>>>> 
>>>>>>>>>>>> On Mar 5, 2024, at 5:50 AM, John Mattsson
>>>>>>>>>>>> <john.mattsson=[e-mail]> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Dear RFC Editor,
>>>>>>>>>>>> See answers to the questions inline.
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> John Preuß Mattsson
>>>>>>>>>>>> From: [e-mail] <[e-mail]>
>>>>>>>>>>>> Date: Friday, 1 March 2024 at 03:02
>>>>>>>>>>>> To: Göran Selander <[e-mail]>, John
>>>>>>>>>>>> Mattsson <[e-mail]>, Francesca Palombini
>>>>>>>>>>>> <[e-mail]>
>>>>>>>>>>>> Cc: [e-mail] <[e-mail]>,
>>>>>>>>>>>> [e-mail] <[e-mail]>, [e-mail]
>>>>>>>>>>>> <[e-mail]>,
>>>>>>>>>>>> [e-mail]<[e-mail]>,
>>>>>>>>>>>> [e-mail] <[e-mail]>,
>>>>>>>>>>>> [e-mail] <[e-mail]>
>>>>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9528 <draft-ietf-lake-edhoc-
>>>>>>>>>>>> 23> for your review
>>>>>>>>>>>> Authors,
>>>>>>>>>>>> 
>>>>>>>>>>>> While reviewing this document during AUTH48, please resolve
>>>>>>>>>>>> (as necessary) the following questions, which are also in
>>>>>>>>>>>> the XML file.
>>>>>>>>>>>> 
>>>>>>>>>>>> 1) <!-- [rfced] Please insert any keywords (beyond those
>>>>>>>>>>>> that appear in the title) for use
>>>>>>>>>>>> onhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>>> editor.org%2Fsearch&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916063470%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=zRICB9uq5TqAXxYfSVmnwwSYWdDOmZdZenm0NlupoZg%3D&reserved=0.
>>>>>>>>>>>> -->
>>>>>>>>>>>> 
>>>>>>>>>>>> AKE, LAKE, COSE, OSCORE, lightweight authenticated key
>>>>>>>>>>>> exchange, constrained node networks, IoT security
>>>>>>>>>>>> 
>>>>>>>>>>>> 2) <!--[rfced] FYI, each instance where SVG was used to
>>>>>>>>>>>> create a table,
>>>>>>>>>>>> we have changed to use the table element. For example, see
>>>>>>>>>>>> the
>>>>>>>>>>>> current Table 1, Table 2, etc. The remaining SVG is used for
>>>>>>>>>>>> diagrams,
>>>>>>>>>>>> as intended. Please review that the tables appear correctly.
>>>>>>>>>>>> -->
>>>>>>>>>>>> 
>>>>>>>>>>>> Table 2 is not correct :
>>>>>>>>>>>> OLD: | 1 | Static DH Key      | Signature Key      |
>>>>>>>>>>>> NEW: | 1 | Signature Key      | Static DH Key      |
>>>>>>>>>>>> Table 7 should have the following row to be consistant with
>>>>>>>>>>>> the other tables.
>>>>>>>>>>>> | -24 to -21 | Private Use. |
>>>>>>>>>>>> 
>>>>>>>>>>>> 3) <!--[rfced] The SVG figures in Sections 2, 3.1, and 6.3.2
>>>>>>>>>>>> and
>>>>>>>>>>>> Appendices A.2.1, A.2.2, I.1, and I.2 have width and height
>>>>>>>>>>>> specified,
>>>>>>>>>>>> which will make the artwork not scale. Please consider
>>>>>>>>>>>> whether
>>>>>>>>>>>> scaling should be enabled. Scaling will allow the figure to
>>>>>>>>>>>> be
>>>>>>>>>>>> resized when it is viewed on a mobile device; however, there
>>>>>>>>>>>> may be aesthetic trade-offs (e.g., image may appear too
>>>>>>>>>>>> large
>>>>>>>>>>>> on a desktop screen or different figures may scale
>>>>>>>>>>>> differently
>>>>>>>>>>>> based on their relative sizes). Please review the HTML and
>>>>>>>>>>>> PDF
>>>>>>>>>>>> outputs and let us know how to proceed.
>>>>>>>>>>>> 
>>>>>>>>>>>> For comparison (to see how they look without the height and
>>>>>>>>>>>> width
>>>>>>>>>>>> attributes), please see
>>>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>>> editor.org%2Fauthors%2Ftest9528.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916067659%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=d2e%2BDMZiG73rYIPX7%2Fnb%2Fmv9d9l%2FtSCM7LvGr3yHEMg%3D&reserved=0
>>>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>>> editor.org%2Fauthors%2Ftest9529.pdf&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916072011%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=4xfbPZFcWELbChAM5bYHyJQXTzqcugsUoM5FRlja9EU%3D&reserved=0
>>>>>>>>>>>> -->
>>>>>>>>>>>> 
>>>>>>>>>>>> John: OK
>>>>>>>>>>>> 
>>>>>>>>>>>> 4) <!-- [rfced] Please review whether the note below should
>>>>>>>>>>>> be in
>>>>>>>>>>>> the <aside> element. It is defined as "a container for
>>>>>>>>>>>> content
>>>>>>>>>>>> that is semantically less important or tangential to the
>>>>>>>>>>>> content
>>>>>>>>>>>> that surrounds it"
>>>>>>>>>>>> (https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthors.ietf.org%2Fen%2Frfcxml-
>>>>>>>>>>>> vocabulary%23aside&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916076312%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=5Hf4Vh8lZpBQjuhMEUa%2BCADTxMqHGhXbT1qAQhkd8i4%3D&reserved=0).
>>>>>>>>>>>> 
>>>>>>>>>>>> Original:
>>>>>>>>>>>> Implementation Note: When implementing the byte string
>>>>>>>>>>>> identifier
>>>>>>>>>>>> representation, it can in some programming languages help to
>>>>>>>>>>>> define a
>>>>>>>>>>>> new type, or other data structure, which (in its user facing
>>>>>>>>>>>> API)
>>>>>>>>>>>> behaves like a byte string, but when serializing to CBOR
>>>>>>>>>>>> produces a
>>>>>>>>>>>> CBOR byte string or a CBOR integer depending on its value.
>>>>>>>>>>>>       -->
>>>>>>>>>>>> 
>>>>>>>>>>>> John: Fine to put in <aside>
>>>>>>>>>>>> 
>>>>>>>>>>>> 5) <!--[rfced] We see the following author-inserted comment
>>>>>>>>>>>> in the XML
>>>>>>>>>>>> file for this document. We are unsure if this has been
>>>>>>>>>>>> resolved.
>>>>>>>>>>>> Please review and let us know if it can be deleted or if it
>>>>>>>>>>>> needs to
>>>>>>>>>>>> be addressed.
>>>>>>>>>>>> 
>>>>>>>>>>>> <!- A diagram of the EDHOC key schedule can be found in
>>>>>>>>>>>> Figure 2 of
>>>>>>>>>>>> {{Vucinic22}}. TBD: Rewrite the diagram ->
>>>>>>>>>>>> 
>>>>>>>>>>>> -->
>>>>>>>>>>>> 
>>>>>>>>>>>> John: Delete the comment.
>>>>>>>>>>>> 
>>>>>>>>>>>> 6) <!--[rfced] Per usage elsewhere in the document, should
>>>>>>>>>>>> "message 3" and
>>>>>>>>>>>> "message 2" be updated to "message_3" and "message_2",
>>>>>>>>>>>> respectively?
>>>>>>>>>>>> 
>>>>>>>>>>>> Original:
>>>>>>>>>>>> For example, PRK_3e2m is involved in the encryption of
>>>>>>>>>>>> message 3 and in calculating the MAC of message 2.
>>>>>>>>>>>>  -->
>>>>>>>>>>>> 
>>>>>>>>>>>> John: The Original text is correct and should not be
>>>>>>>>>>>> changed.
>>>>>>>>>>>> 
>>>>>>>>>>>> 7) <!--[rfced] We note that RFC 9053 does not contain a
>>>>>>>>>>>> Section 4.4. We
>>>>>>>>>>>> have updated this to Section 4.4 of RFC 9052 (which is
>>>>>>>>>>>> "Signing and
>>>>>>>>>>>> Verification Process"). Please review.
>>>>>>>>>>>> 
>>>>>>>>>>>> Original:
>>>>>>>>>>>>  If the
>>>>>>>>>>>>  Responder authenticates with a signature key (method
>>>>>>>>>>>> equals 0 or
>>>>>>>>>>>>  2), then Signature_or_MAC_2 is the 'signature' field of a
>>>>>>>>>>>>  COSE_Sign1 object, computed as specified in Section 4.4 of
>>>>>>>>>>>>  [RFC9053] using the signature algorithm of the selected
>>>>>>>>>>>> cipher
>>>>>>>>>>>>  suite, the private authentication key of the Responder,
>>>>>>>>>>>> and the
>>>>>>>>>>>>  following parameters as input (see Appendix C.3 for an
>>>>>>>>>>>> overview of
>>>>>>>>>>>>  COSE and Appendix C.1 for notation):
>>>>>>>>>>>>     -->
>>>>>>>>>>>> 
>>>>>>>>>>>> John: Thanks. Your change to RFC 9052 is correct.
>>>>>>>>>>>> 
>>>>>>>>>>>> 8) <!--[rfced] We are having difficulty understanding "in
>>>>>>>>>>>> this section
>>>>>>>>>>>> exemplified with CoAP" in the following sentence. May we
>>>>>>>>>>>> update the
>>>>>>>>>>>> text as suggested below?
>>>>>>>>>>>> 
>>>>>>>>>>>> Original:
>>>>>>>>>>>> EDHOC by default assumes that message duplication is handled
>>>>>>>>>>>> by the
>>>>>>>>>>>> transport, in this section exemplified with CoAP, see
>>>>>>>>>>>> Appendix A.2.
>>>>>>>>>>>> 
>>>>>>>>>>>> Perhaps:
>>>>>>>>>>>> By default, EDHOC assumes that message duplication is
>>>>>>>>>>>> handled by the
>>>>>>>>>>>> transport (which is exemplified by CoAP in this section);
>>>>>>>>>>>> see
>>>>>>>>>>>> Appendix A.2.
>>>>>>>>>>>> -->
>>>>>>>>>>>> 
>>>>>>>>>>>> John: Yes, please update the text.
>>>>>>>>>>>> 
>>>>>>>>>>>> 9) <!--[rfced] To improve clarity, may we rephrase this
>>>>>>>>>>>> sentence as follows?
>>>>>>>>>>>> 
>>>>>>>>>>>> Original:
>>>>>>>>>>>> By including the authentication credentials in the
>>>>>>>>>>>> transcript hash, EDHOC protects against Duplicate Signature
>>>>>>>>>>>> Key
>>>>>>>>>>>> Selection (DSKS)-like identity mis-binding attack that the
>>>>>>>>>>>> MAC-then-
>>>>>>>>>>>> Sign variant of SIGMA-I is otherwise vulnerable to.
>>>>>>>>>>>> 
>>>>>>>>>>>> Perhaps:
>>>>>>>>>>>> By including the authentication credentials in the
>>>>>>>>>>>> transcript hash, EDHOC protects against an identity
>>>>>>>>>>>> misbinding
>>>>>>>>>>>> attack like the Duplicate Signature Key Selection (DSKS)
>>>>>>>>>>>> that the
>>>>>>>>>>>> MAC-then-Sign variant of SIGMA-I is otherwise vulnerable to.
>>>>>>>>>>>>   -->
>>>>>>>>>>>> 
>>>>>>>>>>>> John: Yes, please rephrase the text.
>>>>>>>>>>>> 
>>>>>>>>>>>> 10) <!--[rfced] Regarding usage of "IND-CCA":
>>>>>>>>>>>> a) How should the expansion be updated? Specifically,
>>>>>>>>>>>> "indistinguishability under chosen ciphertext" or
>>>>>>>>>>>> "indistinguishability under adaptive chosen ciphertext
>>>>>>>>>>>> attack"
>>>>>>>>>>>> (as it appears in RFCs 9172 and 9180) or otherwise?
>>>>>>>>>>>> 
>>>>>>>>>>>> John: indistinguishability under adaptive chosen ciphertext
>>>>>>>>>>>> attack (IND-CCA2)
>>>>>>>>>>>> 
>>>>>>>>>>>> b) Should it be "IND-CCA2"? (We see zero instances of "IND-
>>>>>>>>>>>> CCA"
>>>>>>>>>>>> in RFCs.) Please review how it should be used in the second
>>>>>>>>>>>> sentence.
>>>>>>>>>>>> 
>>>>>>>>>>>> Original:
>>>>>>>>>>>> HKDF-Expand is not often used as a stream cipher
>>>>>>>>>>>> as it is slow on long messages, and most applications
>>>>>>>>>>>> require both
>>>>>>>>>>>> confidentiality with indistinguishability under chosen
>>>>>>>>>>>> ciphertext
>>>>>>>>>>>> (IND-CCA) as well as integrity protection.  For the
>>>>>>>>>>>> encryption of
>>>>>>>>>>>> message_2, any speed difference is negligible, IND-CCA does
>>>>>>>>>>>> not
>>>>>>>>>>>> increase security, ...
>>>>>>>>>>>> 
>>>>>>>>>>>> Perhaps (if "IND-CCA2" is accurate):
>>>>>>>>>>>> HKDF-Expand is not often used as a stream cipher
>>>>>>>>>>>> as it is slow on long messages, and most applications
>>>>>>>>>>>> require both
>>>>>>>>>>>> confidentiality with indistinguishability under adaptive
>>>>>>>>>>>> chosen
>>>>>>>>>>>> ciphertext attack (IND-CCA2) as well as integrity
>>>>>>>>>>>> protection. For the
>>>>>>>>>>>> encryption of message_2, any speed difference is negligible,
>>>>>>>>>>>> IND-CCA2
>>>>>>>>>>>> does not increase security, ...
>>>>>>>>>>>> -->    John: We are fine with changing to IND-CCA2.
>>>>>>>>>>>> 
>>>>>>>>>>>> 11) <!-- [rfced] Tables 5, 6, 7, 8, 9, and 11 do not have
>>>>>>>>>>>> titles. Please
>>>>>>>>>>>> review, and provide titles for the untitled tables if
>>>>>>>>>>>> desired. -->
>>>>>>>>>>>> 
>>>>>>>>>>>> John: Here are suggested labels:
>>>>>>>>>>>> Table 5: Registration Procedures for EDHOC Exporter Labels
>>>>>>>>>>>> Table 6: EDHOC Cipher Suites
>>>>>>>>>>>> Table 7: Registration Procedures for EDHOC Cipher Suites
>>>>>>>>>>>> Table 8: Registration Procedures for EDHOC Method Types
>>>>>>>>>>>> Table 9: Registration Procedures for EDHOC Error Codes
>>>>>>>>>>>> Table 10: EDHOC EAD Labels
>>>>>>>>>>>> Table 11: Registration procedures for EDHOC EAD Labels
>>>>>>>>>>>> 
>>>>>>>>>>>> 12) <!--[rfced] We note that draft-selander-lake-authz-03
>>>>>>>>>>>> has been replaced
>>>>>>>>>>>> by draft-ietf-lake-authz. Should this reference be updated?
>>>>>>>>>>>> 
>>>>>>>>>>>> Original:
>>>>>>>>>>>> [I-D.selander-lake-authz]
>>>>>>>>>>>>          Selander, G., Mattsson, J. P., Vučinić, M.,
>>>>>>>>>>>> Richardson,
>>>>>>>>>>>>          M., and A. Schellenbaum, "Lightweight
>>>>>>>>>>>> Authorization using
>>>>>>>>>>>>          Ephemeral Diffie-Hellman Over COSE", Work in
>>>>>>>>>>>> Progress,
>>>>>>>>>>>>          Internet-Draft, draft-selander-lake-authz-03, 7
>>>>>>>>>>>> July 2023,
>>>>>>>>>>>>          <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-
>>>>>>>>>>>> selander-
>>>>>>>>>>>> &data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916080385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=nAOfMj94UnB2ZVRA8oCDUzzZxaF%2Fta%2FCwnfKywi7HF8%3D&reserved=0
>>>>>>>>>>>>          lake-authz-03>.
>>>>>>>>>>>>           -->
>>>>>>>>>>>> 
>>>>>>>>>>>> John: Yes, please update to draft-ietf-lake-authz.
>>>>>>>>>>>> 
>>>>>>>>>>>> 13) <!--[rfced] Section 4.3 of RFC 9052 does not mention
>>>>>>>>>>>> "COSE_Sign1".
>>>>>>>>>>>> We have updated the citation as follows. Please let us know
>>>>>>>>>>>> of any
>>>>>>>>>>>> objections.
>>>>>>>>>>>> 
>>>>>>>>>>>> Original:
>>>>>>>>>>>> *  Signatures in message_2 of method 0 and 2, and in
>>>>>>>>>>>> message_3 of
>>>>>>>>>>>>  method 0 and 1, consist of a subset of the single signer
>>>>>>>>>>>> data
>>>>>>>>>>>>  object COSE_Sign1, which is described in Sections 4.2-4.4
>>>>>>>>>>>> of
>>>>>>>>>>>>  [RFC9052].
>>>>>>>>>>>> 
>>>>>>>>>>>> Current:
>>>>>>>>>>>> *  Signatures in message_2 of method 0 and 2, and in
>>>>>>>>>>>> message_3 of
>>>>>>>>>>>>  method 0 and 1, consist of a subset of the single signer
>>>>>>>>>>>> data
>>>>>>>>>>>>  object COSE_Sign1, which is described in Sections 4.2 and
>>>>>>>>>>>> 4.4 of
>>>>>>>>>>>>    [RFC9052].
>>>>>>>>>>>> -->
>>>>>>>>>>>> 
>>>>>>>>>>>> John: That is good.
>>>>>>>>>>>> 
>>>>>>>>>>>> 14) <!--[rfced] In Appendix C.3, what should replace TBD3
>>>>>>>>>>>> and TBD4?
>>>>>>>>>>>> Those placeholders were not used in the IANA Considerations.
>>>>>>>>>>>> 
>>>>>>>>>>>> Original:
>>>>>>>>>>>>  -  ID_CRED_x = { TBD3 : COSE_CertHash }, for x = I or R;
>>>>>>>>>>>> [...]
>>>>>>>>>>>>  -  ID_CRED_x = { TBD4 : uri }, for x = I or R.
>>>>>>>>>>>> -->
>>>>>>>>>>>> 
>>>>>>>>>>>> John: Hi, TBD3 and TBD4 will be registered by draft-ietf-
>>>>>>>>>>>> cose-cbor-encoded-cert in the future. We suggest the
>>>>>>>>>>>> following change. We do not want to wait until C509-CERTS is
>>>>>>>>>>>> published. This is just an example.
>>>>>>>>>>>> OLD:
>>>>>>>>>>>> When ID_CRED_x does not contain the actual credential, it
>>>>>>>>>>>> may be very short, e.g., if the endpoints have agreed to use
>>>>>>>>>>>> a key identifier parameter 'kid':
>>>>>>>>>>>> NEW:
>>>>>>>>>>>> TBD3 and TBD4 are to be assigned by [C509-CERTS].
>>>>>>>>>>>> When ID_CRED_x does not contain the actual credential, it
>>>>>>>>>>>> may be very short, e.g., if the endpoints have agreed to use
>>>>>>>>>>>> a key identifier parameter 'kid':
>>>>>>>>>>>> Otherwise the other option (we don't want) is to wait for
>>>>>>>>>>>> C509-CERTS to be done - I expect that RFC Editor will tell
>>>>>>>>>>>> us as much if we ask them how to handle.
>>>>>>>>>>>> 
>>>>>>>>>>>> 15) <!--[rfced] Figures 12 and 13 do not have titles, unlike
>>>>>>>>>>>> Figures 1-11.
>>>>>>>>>>>> Please review, and provide titles for those two figures if
>>>>>>>>>>>> desired.
>>>>>>>>>>>> -->
>>>>>>>>>>>> 
>>>>>>>>>>>> Here are suggested labels:
>>>>>>>>>>>> 
>>>>>>>>>>>> Figure 12: Initiator State Machine
>>>>>>>>>>>> Figure 13: Responder State Machine
>>>>>>>>>>>> 
>>>>>>>>>>>> 16) <!--[rfced] Acronyms
>>>>>>>>>>>> 
>>>>>>>>>>>> a) FYI - We have added expansions for the following
>>>>>>>>>>>> abbreviations
>>>>>>>>>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please
>>>>>>>>>>>> review each
>>>>>>>>>>>> expansion in the document carefully to ensure correctness.
>>>>>>>>>>>> 
>>>>>>>>>>>> IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH)
>>>>>>>>>>>> Authentication and Key Agreement (AKA)
>>>>>>>>>>>> CBC-MAC (CCM)
>>>>>>>>>>>> Extensible Authentication Protocol Tunneled Transport Layer
>>>>>>>>>>>> Security (EAP-TTLS)
>>>>>>>>>>>> Elliptic Curve Diffie-Hellman (ECDH)
>>>>>>>>>>>> Ephemeral Elliptic Curve Diffie-Hellman (ECDHE)
>>>>>>>>>>>> Elliptic Curve Digital Signature Algorithm (ECDSA)
>>>>>>>>>>>> Edwards-curve Digital Signature Algorithm (EdDSA)
>>>>>>>>>>>> Hashed Message Authentication Code (HMAC)
>>>>>>>>>>>> Internet Key Exchange Protocol Version 2 (IKEv2)
>>>>>>>>>>>> JSON Object Signing and Encryption (JOSE)
>>>>>>>>>>>> Key Derivation Function (KDF)
>>>>>>>>>>>> Lightweight Authenticated Key Exchange (LAKE)
>>>>>>>>>>>> Online Certificate Status Protocol (OSCP)
>>>>>>>>>>>> Octet Key Pair (OKP)
>>>>>>>>>>>> Pseudorandom Function (PRF)
>>>>>>>>>>>> Standards for Efficient Cryptography Group (SECG)
>>>>>>>>>>>> 
>>>>>>>>>>>> John: CCM should be “Counter with CBC-MAC (CCM)”, see RFC
>>>>>>>>>>>> 3610.
>>>>>>>>>>>> 
>>>>>>>>>>>> b) FYI, we have updated the expansion of AEAD from
>>>>>>>>>>>> "authenticated
>>>>>>>>>>>> encryption with additional data" to "Authenticated
>>>>>>>>>>>> Encryption with
>>>>>>>>>>>> Associated Data". Please let us know if this is not correct.
>>>>>>>>>>>> -->
>>>>>>>>>>>> 
>>>>>>>>>>>> John: That is fine.
>>>>>>>>>>>> 
>>>>>>>>>>>> 17) <!-- [rfced] Please review the "Inclusive Language"
>>>>>>>>>>>> portion of the online
>>>>>>>>>>>> Style Guide
>>>>>>>>>>>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>>> editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916084529%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=1RAfjYOKYHppTcYfOHhWKrQ1maEo4hr0OMh2b36%2FfTY%3D&reserved=0>
>>>>>>>>>>>> and let us know if any changes are needed.
>>>>>>>>>>>> 
>>>>>>>>>>>> For example, please consider whether "master" should be
>>>>>>>>>>>> updated.
>>>>>>>>>>>> -->
>>>>>>>>>>>> 
>>>>>>>>>>>> John: We have reviewed the “Inclusive Language” portion.
>>>>>>>>>>>> “master” cannot be updated as it is the term used in RFC
>>>>>>>>>>>> 8613.
>>>>>>>>>>>> 
>>>>>>>>>>>> Thank you.
>>>>>>>>>>>> 
>>>>>>>>>>>> RFC Editor/ap/ar
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Feb 29, 2024, [e-mail] wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> *****IMPORTANT*****
>>>>>>>>>>>> 
>>>>>>>>>>>> Updated 2024/02/29
>>>>>>>>>>>> 
>>>>>>>>>>>> RFC Author(s):
>>>>>>>>>>>> --------------
>>>>>>>>>>>> 
>>>>>>>>>>>> Instructions for Completing AUTH48
>>>>>>>>>>>> 
>>>>>>>>>>>> Your document has now entered AUTH48.  Once it has been
>>>>>>>>>>>> reviewed and
>>>>>>>>>>>>  approved by you and all coauthors, it will be published as
>>>>>>>>>>>> an RFC.
>>>>>>>>>>>> If an author is no longer available, there are several
>>>>>>>>>>>> remedies
>>>>>>>>>>>> available as listed in the FAQ
>>>>>>>>>>>> (https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>>> editor.org%2Ffaq%2F&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916089229%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ZhogC9AlzxjJu%2BDdfVDSef%2BkRt%2BVdiLf9R0ZxVC6WdQ%3D&reserved=0).
>>>>>>>>>>>> 
>>>>>>>>>>>> You and you coauthors are responsible for engaging other
>>>>>>>>>>>> parties
>>>>>>>>>>>> (e.g., Contributors or Working Group) as necessary before
>>>>>>>>>>>> providing
>>>>>>>>>>>> your approval.
>>>>>>>>>>>> 
>>>>>>>>>>>> Planning your review
>>>>>>>>>>>> ---------------------
>>>>>>>>>>>> 
>>>>>>>>>>>> Please review the following aspects of your document:
>>>>>>>>>>>> 
>>>>>>>>>>>> *  RFC Editor questions
>>>>>>>>>>>> 
>>>>>>>>>>>> Please review and resolve any questions raised by the RFC
>>>>>>>>>>>> Editor
>>>>>>>>>>>> that have been included in the XML file as comments marked
>>>>>>>>>>>> as
>>>>>>>>>>>> follows:
>>>>>>>>>>>> 
>>>>>>>>>>>> <!-- [rfced] ... -->
>>>>>>>>>>>> 
>>>>>>>>>>>> These questions will also be sent in a subsequent email.
>>>>>>>>>>>> 
>>>>>>>>>>>> *  Changes submitted by coauthors
>>>>>>>>>>>> 
>>>>>>>>>>>> Please ensure that you review any changes submitted by your
>>>>>>>>>>>> coauthors.  We assume that if you do not speak up that you
>>>>>>>>>>>> agree to changes submitted by your coauthors.
>>>>>>>>>>>> 
>>>>>>>>>>>> *  Content
>>>>>>>>>>>> 
>>>>>>>>>>>> Please review the full content of the document, as this
>>>>>>>>>>>> cannot
>>>>>>>>>>>> change once the RFC is published.  Please pay particular
>>>>>>>>>>>> attention to:
>>>>>>>>>>>> - IANA considerations updates (if applicable)
>>>>>>>>>>>> - contact information
>>>>>>>>>>>> - references
>>>>>>>>>>>> 
>>>>>>>>>>>> *  Copyright notices and legends
>>>>>>>>>>>> 
>>>>>>>>>>>> Please review the copyright notice and legends as defined in
>>>>>>>>>>>> RFC 5378 and the Trust Legal Provisions
>>>>>>>>>>>> (TLP –
>>>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustee.ietf.org%2Flicense-
>>>>>>>>>>>> info%2F&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916095475%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=78VrWIgPNwLXm6mvTMubL0rQkFyKiutRk47TL93LsoQ%3D&reserved=0).
>>>>>>>>>>>> 
>>>>>>>>>>>> *  Semantic markup
>>>>>>>>>>>> 
>>>>>>>>>>>> Please review the markup in the XML file to ensure that
>>>>>>>>>>>> elements of
>>>>>>>>>>>> content are correctly tagged.  For example, ensure that
>>>>>>>>>>>> <sourcecode>
>>>>>>>>>>>> and <artwork> are set correctly.  See details at
>>>>>>>>>>>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthors.ietf.org%2Frfcxml-
>>>>>>>>>>>> vocabulary&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916099818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=T%2FIRGzCLSoItipMEQ8rkq9DmZuNvonXtVj6YRcVE3aM%3D&reserved=0>.
>>>>>>>>>>>> 
>>>>>>>>>>>> *  Formatted output
>>>>>>>>>>>> 
>>>>>>>>>>>> Please review the PDF, HTML, and TXT files to ensure that
>>>>>>>>>>>> the
>>>>>>>>>>>> formatted output, as generated from the markup in the XML
>>>>>>>>>>>> file, is
>>>>>>>>>>>> reasonable.  Please note that the TXT will have formatting
>>>>>>>>>>>> limitations compared to the PDF and HTML.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Submitting changes
>>>>>>>>>>>> ------------------
>>>>>>>>>>>> 
>>>>>>>>>>>> To submit changes, please reply to this email using ‘REPLY
>>>>>>>>>>>> ALL’ as all
>>>>>>>>>>>> the parties CCed on this message need to see your changes.
>>>>>>>>>>>> The parties
>>>>>>>>>>>> include:
>>>>>>>>>>>> 
>>>>>>>>>>>> *  your coauthors
>>>>>>>>>>>> 
>>>>>>>>>>>> *  [e-mail] (the RPC team)
>>>>>>>>>>>> 
>>>>>>>>>>>> *  other document participants, depending on the stream
>>>>>>>>>>>> (e.g.,
>>>>>>>>>>>> IETF Stream participants are your working group chairs, the
>>>>>>>>>>>> responsible ADs, and the document shepherd).
>>>>>>>>>>>> 
>>>>>>>>>>>> *  [e-mail], which is a new archival
>>>>>>>>>>>> mailing list
>>>>>>>>>>>> to preserve AUTH48 conversations; it is not an active
>>>>>>>>>>>> discussion
>>>>>>>>>>>> list:
>>>>>>>>>>>> 
>>>>>>>>>>>> *  More info:
>>>>>>>>>>>>   https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fietf-
>>>>>>>>>>>> announce%2Fyb6lpIGh-
>>>>>>>>>>>> 4Q9l2USxIAe6P8O4Zc&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916103959%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=sX41Xd7exnQANKdi%2BG6SeKRYt72mngahplDdPteulYI%3D&reserved=0
>>>>>>>>>>>> 
>>>>>>>>>>>> *  The archive itself:
>>>>>>>>>>>>   https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916108201%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=PqGit0fo2LE7KOm8ZK9r3REK5mqAs91RqjdmH%2FnXVNM%3D&reserved=0
>>>>>>>>>>>> 
>>>>>>>>>>>> *  Note: If only absolutely necessary, you may temporarily
>>>>>>>>>>>> opt out
>>>>>>>>>>>>   of the archiving of messages (e.g., to discuss a
>>>>>>>>>>>> sensitive matter).
>>>>>>>>>>>>   If needed, please add a note at the top of the message
>>>>>>>>>>>> that you
>>>>>>>>>>>>   have dropped the address. When the discussion is
>>>>>>>>>>>> concluded,
>>>>>>>>>>>>   [e-mail] will be re-added to the CC
>>>>>>>>>>>> list and
>>>>>>>>>>>>   its addition will be noted at the top of the message.
>>>>>>>>>>>> 
>>>>>>>>>>>> You may submit your changes in one of two ways:
>>>>>>>>>>>> 
>>>>>>>>>>>> An update to the provided XML file
>>>>>>>>>>>> — OR —
>>>>>>>>>>>> An explicit list of changes in this format
>>>>>>>>>>>> 
>>>>>>>>>>>> Section # (or indicate Global)
>>>>>>>>>>>> 
>>>>>>>>>>>> OLD:
>>>>>>>>>>>> old text
>>>>>>>>>>>> 
>>>>>>>>>>>> NEW:
>>>>>>>>>>>> new text
>>>>>>>>>>>> 
>>>>>>>>>>>> You do not need to reply with both an updated XML file and
>>>>>>>>>>>> an explicit
>>>>>>>>>>>> list of changes, as either form is sufficient.
>>>>>>>>>>>> 
>>>>>>>>>>>> We will ask a stream manager to review and approve any
>>>>>>>>>>>> changes that seem
>>>>>>>>>>>> beyond editorial in nature, e.g., addition of new text,
>>>>>>>>>>>> deletion of text,
>>>>>>>>>>>> and technical changes.  Information about stream managers
>>>>>>>>>>>> can be found in
>>>>>>>>>>>> the FAQ.  Editorial changes do not require approval from a
>>>>>>>>>>>> stream manager.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Approving for publication
>>>>>>>>>>>> --------------------------
>>>>>>>>>>>> 
>>>>>>>>>>>> To approve your RFC for publication, please reply to this
>>>>>>>>>>>> email stating
>>>>>>>>>>>> that you approve this RFC for publication.  Please use
>>>>>>>>>>>> ‘REPLY ALL’,
>>>>>>>>>>>> as all the parties CCed on this message need to see your
>>>>>>>>>>>> approval.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Files
>>>>>>>>>>>> -----
>>>>>>>>>>>> 
>>>>>>>>>>>> The files are available here:
>>>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>>> editor.org%2Fauthors%2Frfc9528.xml&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916112063%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=lQq8mnS0nAab%2BpNg1sw5YzuZUK4OmzuPzKFdzH7F5oE%3D&reserved=0
>>>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>>> editor.org%2Fauthors%2Frfc9528.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916116319%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=GG%2Fe6nXKd7KuxdknHKkoecoecoPiBAYrITJgPzmdxHE%3D&reserved=0
>>>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>>> editor.org%2Fauthors%2Frfc9528.pdf&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916120511%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ibAN7KI%2BrOgpzcT2omQDiqKIXrS%2BTNz92IemDQP8Rog%3D&reserved=0
>>>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>>> editor.org%2Fauthors%2Frfc9528.txt&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916124781%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=TTMxgiB13BBzzDilfYzEX1ad6MBenQliAtLhAQ8X%2FPc%3D&reserved=0
>>>>>>>>>>>> 
>>>>>>>>>>>> Diff file of the text:
>>>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>>> editor.org%2Fauthors%2Frfc9528-
>>>>>>>>>>>> diff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916129006%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=pMMhMP7vPK8MrCl6eAK8HCyzsd0x1SNl1Ki%2BSJmma24%3D&reserved=0
>>>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>>> editor.org%2Fauthors%2Frfc9528-
>>>>>>>>>>>> rfcdiff.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916133329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=2dTFJ%2BQbWI7qzbrwq6c80jieqS9xNABIiHzNCL2LD9g%3D&reserved=0
>>>>>>>>>>>> (side by side)
>>>>>>>>>>>> 
>>>>>>>>>>>> Diff of the XML:
>>>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>>> editor.org%2Fauthors%2Frfc9528-
>>>>>>>>>>>> xmldiff1.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916137793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=AYyglRyVJ%2BUnk7rIqYnxpCnWncz8STlsIBgymZ54x00%3D&reserved=0
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Tracking progress
>>>>>>>>>>>> -----------------
>>>>>>>>>>>> 
>>>>>>>>>>>> The details of the AUTH48 status of your document are here:
>>>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>>> editor.org%2Fauth48%2Frfc9528&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cd8855bccfe03405bc4d608dc4449e8de%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638460331916142260%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=FzIFZ65CYuuwZTbiikGotR8mdAB9CxjL2GxHlk9haNI%3D&reserved=0
>>>>>>>>>>>> 
>>>>>>>>>>>> Please let us know if you have any questions.
>>>>>>>>>>>> 
>>>>>>>>>>>> Thank you for your cooperation,
>>>>>>>>>>>> 
>>>>>>>>>>>> RFC Editor
>>>>>>>>>>>> 
>>>>>>>>>>>> --------------------------------------
>>>>>>>>>>>> RFC9528 (draft-ietf-lake-edhoc-23)
>>>>>>>>>>>> 
>>>>>>>>>>>> Title            : Ephemeral Diffie-Hellman Over COSE
>>>>>>>>>>>> (EDHOC)
>>>>>>>>>>>> Author(s)        : G. Selander, J. Mattsson, F. Palombini
>>>>>>>>>>>> WG Chair(s)      : Mališa Vučinić, Stephen Farrell
>>>>>>>>>>>> Area Director(s) : Roman Danyliw, Paul Wouters
>>>>>>>>>>>> 
>>>>>>>>>>>> John: My last name is fine in the document but here it is
>>>>>>>>>>>> chopped in half. My last name is “Preuß Mattsson” including
>>>>>>>>>>>> the white space.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>> 
>>> 
>