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

[John Mattsson <[e-mail]>]

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://eprint.iacr.org/2023/913
[2] https://eprint.iacr.org/2024/220

-----------

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.
>
>