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

[Göran Selander <[e-mail]>]

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]>, [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 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://datatracker.ietf.org/doc/minutes-interim-2024-lake-01-202402131400/

“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 <[e-mail]>, [e-mail] <[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
>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] <[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://www.iana.org/assignments/edhoc/edhoc.xhtml#edhoc-error-codes) 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://www.iana.org/assignments/edhoc/edhoc.xhtml#edhoc-exporter-labels)
> 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://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-dc22bfcd594b44db&q=1&e=df791691-0ab0-48aa-9818-b117e83cee3f&u=https%3A%2F%2Feprint.iacr.org%2F2023%2F913
>> [2] https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-238b27209f91355d&q=1&e=df791691-0ab0-48aa-9818-b117e83cee3f&u=https%3A%2F%2Feprint.iacr.org%2F2024%2F220
>
> ) 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://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-dc22bfcd594b44db&q=1&e=df791691-0ab0-48aa-9818-b117e83cee3f&u=https%3A%2F%2Feprint.iacr.org%2F2023%2F913>.
>
> [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://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-238b27209f91355d&q=1&e=df791691-0ab0-48aa-9818-b117e83cee3f&u=https%3A%2F%2Feprint.iacr.org%2F2024%2F220>.
> ...
> 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)
>
> For the AUTH48 status of this document, please see:
>  https://www.rfc-editor.org/auth48/rfc9528
>
> 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://doi.org/10.6028/NIST.SP.800-108r1>.
>> 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://doi.org/10.6028/NIST.SP.800-108r1-upd1>.
>> (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://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-dc22bfcd594b44db&q=1&e=df791691-0ab0-48aa-9818-b117e83cee3f&u=https%3A%2F%2Feprint.iacr.org%2F2023%2F913
>> [2] https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-238b27209f91355d&q=1&e=df791691-0ab0-48aa-9818-b117e83cee3f&u=https%3A%2F%2Feprint.iacr.org%2F2024%2F220
>> -----------
>> 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] <[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 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 <[e-mail]>, Göran Selander <[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
>> 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://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)
>>>
>>> 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]>, [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
>>>> 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://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)
>>>>
>>>> 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://www.rfc-editor.org/auth48/rfc9528
>>>>
>>>> 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://www.rfc-editor.org/search. -->
>>>>>
>>>>> 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://www.rfc-editor.org/authors/test9528.html
>>>>> https://www.rfc-editor.org/authors/test9529.pdf
>>>>> -->
>>>>>
>>>>> 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://authors.ietf.org/en/rfcxml-vocabulary#aside).
>>>>>
>>>>> 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://datatracker.ietf.org/doc/html/draft-selander-
>>>>>             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://www.rfc-editor.org/styleguide/part2/#inclusive_language>
>>>>> 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://www.rfc-editor.org/faq/).
>>>>>
>>>>> 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://trustee.ietf.org/license-info/).
>>>>>
>>>>> *  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://authors.ietf.org/rfcxml-vocabulary>.
>>>>>
>>>>> *  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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>>>>>
>>>>>   *  The archive itself:
>>>>>      https://mailarchive.ietf.org/arch/browse/auth48archive/
>>>>>
>>>>>   *  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://www.rfc-editor.org/authors/rfc9528.xml
>>>>> https://www.rfc-editor.org/authors/rfc9528.html
>>>>> https://www.rfc-editor.org/authors/rfc9528.pdf
>>>>> https://www.rfc-editor.org/authors/rfc9528.txt
>>>>>
>>>>> Diff file of the text:
>>>>> https://www.rfc-editor.org/authors/rfc9528-diff.html
>>>>> https://www.rfc-editor.org/authors/rfc9528-rfcdiff.html (side by side)
>>>>>
>>>>> Diff of the XML:
>>>>> https://www.rfc-editor.org/authors/rfc9528-xmldiff1.html
>>>>>
>>>>>
>>>>> Tracking progress
>>>>> -----------------
>>>>>
>>>>> The details of the AUTH48 status of your document are here:
>>>>> https://www.rfc-editor.org/auth48/rfc9528
>>>>>
>>>>> 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.
>>>
>>>
>