uses peculiar names such as ES256 for ECDSA with SHA-256, A128 for AES-128, and Ed25519 for the curve edwards25519.  Algorithms need to be specified with enough parameters to make them completely <del> determined.  The MAC length MUST be at least 8 bytes.  EDHOC is currently only specified for use with key exchange algorithms of type ECDH curves, but any Key Encapsulation Method (KEM), including Post- </del>  Quantum Cryptography (PQC) KEMs, can be used in method 0, see pqc. Use of other types of key exchange algorithms to replace static DH authentication (method 1,2,3) would likely require a specification 256-bits, i.e., the hash algorithms SHA-1 and SHA-256/64 (SHA-256 truncated to 64-bits) SHALL NOT be supported for use in EDHOC except for certificate identification with x5t and c5t.  For security <del> considerations of SHA-1, see RFC6194. The EDHOC MAC length MUST be at least 8 bytes and the tag length of the EDHOC AEAD algorithm MUST be at least 64-bits.  Note that secp256k1 is only defined for use with ECDSA and not for ECDH.  Note that some COSE algorithms are marked as not recommended in the COSE IANA registry. </del>  8.4.

I added a recommendation as well. I think this can be merged.
Looks fine to me, merging
states Then has which is using -15 (SHA-256/64), not -16 (SHA-256) for the hash. How was this decision arrived at?
Thanks for the comment. The hash algorithm used in x5t is independent of the EDHOC cipher suite, that should probably be mentioned in the draft. I will make a PR with some text on this.I don't think there was any discussion on this, but SHA-256/64 feels like a natural choice. As EDHOC integrity protects the whole certificate the length of the hash does not have any security relevance, the hash is just used to find the certificate, not to prove it is the correct one. Using SHA-256 would increase overhead with 24 bytes per message without any benefits. An implementation supporting SHA-256 can easily support SHA-256/64 (as it is just a truncated SHA-256).
NAME Than I need to run an update on test vectors for p256 as I have switched to SHA256. I will make an update to use SHA256/64 and pull request
Yes, please do. Using SHA-256 in x5t is just a waste of 24 bytes in message2 and message3. We should maybe give some recommendations in the draft regarding this, but I think it is hard to give normative requirements as x5t is just one example and future COSE header parameters and EAD might use cryptographic algorithms. The algortithms in X.509 in another example on algorithms not controlled by the cipher suite, Somebody might use a cert with a P-521 authentication key where the CA used RSA-PSS to sign the certificate together with cipher suite 2/3. Maybe the draft should recommend the use of algorithms from the ciphersuite also in cose headers, EAD, X.509, CWT, etc. In the case of x5t the recommendation could be to use the same hash function but with as much truncation as possible.
Can we close this now?
Works for me - thanks.

uses peculiar names such as ES256 for ECDSA with SHA-256, A128 for AES-128, and Ed25519 for the curve edwards25519.  Algorithms need to be specified with enough parameters to make them completely  <ins> determined.  The MAC length MUST be at least 8 bytes.  Any cryptographic algorithm used in the COSE header parameters in ID_CRED is selected independently of the cipher suite.  EDHOC is currently only specified for use with key exchange algorithms of type ECDH curves, but any Key Encapsulation Method (KEM), including Post- </ins> Quantum Cryptography (PQC) KEMs, can be used in method 0, see pqc. Use of other types of key exchange algorithms to replace static DH authentication (method 1,2,3) would likely require a specification 256-bits, i.e., the hash algorithms SHA-1 and SHA-256/64 (SHA-256 truncated to 64-bits) SHALL NOT be supported for use in EDHOC except for certificate identification with x5t and c5t.  For security  <ins> considerations of SHA-1, see RFC6194.  As EDHOC integrity protects the whole authentication credential, the choice of hash algorithm in x5t and c5t does not affect security and it is RECOMMENDED to use the same hash algorithm as in the cipher suite but with as much truncation as possible, i.e, when the EDHOC hash algorithm is SHA-256 it is RECOMMENDED to use SHA-256/64 in x5t and c5t.  The EDHOC MAC length MUST be at least 8 bytes and the tag length of the EDHOC AEAD algorithm MUST be at least 64-bits.  Note that secp256k1 is only defined for use with ECDSA and not for ECDH.  Note that some COSE algorithms are marked as not recommended in the COSE IANA registry. </ins> 8.4.


7. <del> An implementation may support only Initiator or only Responder. </del>  <del> An implementation may support only a single method.  None of the </del>  methods are mandatory-to-implement. Implementations MUST support 'kid' parameters of type int.  None of the other COSE header parameters are mandatory-to-implement. <del> An implementation may support only a single credential type (CCS, </del>  CWT, X.509, C509).  None of the credential types are mandatory-to- implement. messages.  Implementations MUST support padding of plaintext when receiving messages, i.e. MUST be able to parse padded messages. <del> For many constrained IoT devices it is problematic to support several crypto primitives.  Existing devices can be expected to support either ECDSA or EdDSA.  Cipher suites 0 (AES-CCM-16-64-128, SHA-256, 8, X25519, EdDSA, AES-CCM-16-64-128, SHA-256) and 1 (AES-CCM- 16-128-128, SHA-256, 16, X25519, EdDSA, AES-CCM-16-64-128, SHA-256) only differ in size of the MAC length, so supporting one or both of these is no essential difference.  Similarly for cipher suites 2 </del>  (AES-CCM-16-64-128, SHA-256, 8, P-256, ES256, AES-CCM-16-64-128, SHA- 256) and 3 (AES-CCM-16-128-128, SHA-256, 16, P-256, ES256, AES-CCM- <del> 16-64-128, SHA-256).  To enable as much interoperability as possible, less constrained devices SHOULD implement all four cipher suites 0-3. Constrained endpoints SHOULD implement cipher suites 0 and 1, or cipher suites 2 and 3.  Implementations only need to implement the algorithms needed for their supported methods. </del>  8.

When does the Compliance requirements apply
The first term was "applicability statement" but since we did not intend the meaning of RFC 2026 was changed to "applicability template" which seems to be confusing because implies something needs to be filled in. New proposal: "application profile".
I like it. That also aligns with the wording in TLS 1.3.
Compliance requirements has some positive effects but also many negative. Constrained devices might be required to support things (takes up storage) they never use. Weaknesses might be found in cryptographic algorithms. Implementation then have to chose between being compliant or insecure. TLS 1.3 has softened the compliance requirements compared to TLS 1.2 (COSE does not have any at all). TLS 1.3 (RFC8446) use the following sentence " In the absence of an application profile standard specifying otherwise: " This might (likely?) be a good sentence for EDHOC as well.
Other comments, in addition to the proposal in PR (see above): TLS text for convenience: Corresponding EDHOC may be: "In the absence of an applicability template specifying otherwise:" With an initial sentence as in 2. or PR 239, the current text on cipher suites may be considerably simplified (since it is anyway up to the application), for example: OLD For many constrained IoT devices it is problematic to support several crypto primitives. Existing devices can be expected to support either ECDSA or EdDSA. Cipher suites 0 (AES-CCM-16-64-128, SHA-256, 8, X25519, EdDSA, AES-CCM-16-64-128, SHA-256) and 1 (AES-CCM-16-128-128, SHA-256, 16, X25519, EdDSA, AES-CCM-16-64-128, SHA-256) only differ in size of the MAC length, so supporting one or both of these is no essential difference. Similarly for cipher suites 2 (AES-CCM-16-64-128, SHA-256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-256) and 3 (AES-CCM-16-128-128, SHA-256, 16, P-256, ES256, AES-CCM-16-64-128, SHA-256). To enable as much interoperability as possible, less constrained devices SHOULD implement all four cipher suites 0-3. Constrained endpoints SHOULD implement cipher suites 0 and 1, or cipher suites 2 and 3. Implementations only need to implement the algorithms needed for their supported methods. NEW Cipher suites 2 (AES-CCM-16-64-128, SHA-256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-256) and 3 (AES-CCM-16-128-128, SHA-256, 16, P-256, ES256, AES-CCM-16-64-128, SHA-256) only differ in size of the MAC length, so supporting one or both of these is no essential difference. An EDHOC-compliant implementation MUST implement cipher suite 2 and 3. Implementations only need to implement the algorithms needed for their supported methods.

7.  <ins> In the absence of an application profile specifying otherwise: </ins>  <ins> An implementation MAY support only Initiator or only Responder. An implementation MAY support only a single method.  None of the </ins> methods are mandatory-to-implement. Implementations MUST support 'kid' parameters of type int.  None of the other COSE header parameters are mandatory-to-implement.  <ins> An implementation MAY support only a single credential type (CCS, </ins> CWT, X.509, C509).  None of the credential types are mandatory-to- implement. messages.  Implementations MUST support padding of plaintext when receiving messages, i.e. MUST be able to parse padded messages.  <ins> Implementations MUST support cipher suite 2 and 3.  Cipher suites 2 </ins> (AES-CCM-16-64-128, SHA-256, 8, P-256, ES256, AES-CCM-16-64-128, SHA- 256) and 3 (AES-CCM-16-128-128, SHA-256, 16, P-256, ES256, AES-CCM-  <ins> 16-64-128, SHA-256) only differ in size of the MAC length, so supporting one or both of these is no essential difference. Implementations only need to implement the algorithms needed for their supported methods. </ins> 8.


As described in SIGMA, different levels of identity protection are provided to the Initiator and the Responder.  EDHOC protects the credential identifier of the Initiator against active attacks and the <del> credential identifier of the Responder against passive attacks.  The roles should be assigned to protect the most sensitive identity/ identifier, typically that which is not possible to infer from routing information in the lower layers. </del>  Compared to SIGMA, EDHOC adds an explicit method type and expands the message authentication coverage to additional elements such as

Good to describe that the known attack on Sigma is that the attacker create a new message_1, no attack is known where an active attacker modifies the ongoing connection (even if the lack of such attacks is likely not proven).
This seems ready to merge
Current draft says: "EDHOC protects the credential identifier of the Initiator against active attacks and the credential identifier of the Responder against passive attacks." Should probably point out that active attack would be a new message1 to the lower layer address as the other message1.

As described in SIGMA, different levels of identity protection are provided to the Initiator and the Responder.  EDHOC protects the credential identifier of the Initiator against active attacks and the  <ins> credential identifier of the Responder against passive attacks.  An active attacker can get the credential identifier of the Responder by eavesdropping on the destination address used for transporting message_1 and send its own message_1 to the same address.  The roles should be assigned to protect the most sensitive identity/identifier, typically that which is not possible to infer from routing information in the lower layers. </ins> Compared to SIGMA, EDHOC adds an explicit method type and expands the message authentication coverage to additional elements such as


Decode message_1 (see CBOR). <del> Verify that G_X is not equal to G_X in a simultanous EDHOC message exchange initiated by the Responder. </del> Verify that the selected cipher suite is supported and that no prior cipher suite in SUITES_I is supported. of SP-800-56A.  For secp256r1, secp384r1, and secp521r1, at least partial public-key validation MUST be done.  8.3. When using private cipher suite or registering new cipher suites, the If two nodes unintentionally initiate two simultaneous EDHOC message exchanges with each other even if they only want to complete a single EDHOC message exchange, they MAY terminate the exchange with the <del> lexicographically smallest G_X.  If the two G_X values are equal, the received message_1 MUST be discarded to mitigate reflection attacks. Reflection attacks are not possible when the other endpoint's identity is verified, but could be a problem with trust on first use (TOFU) and future EHDOC methods using e.g., pre-shared keys.  Note that in cases where several EDHOC exchanges with different parameter sets (method, COSE headers, etc.) are used, an attacker can affect which of the parameter sets that will be used by blocking some of the parameter sets. </del>  If supported by the device, it is RECOMMENDED that at least the long- term private keys are stored in a Trusted Execution Environment (TEE)

Removed the G_X checking that is heavy for implementations. That was a left over from the PSK mehtod.
Based on Marco's comment. Maybe we should not have details.... Remoded details on ID_CRED Reforormulated in split into tofu and non tofu Renamed to selfie attack. (reflection attack was used earlier for the same thing but can also be other types of attacks) So-called selfie attacks are mitigated as long as the Initiator does not have its own identity in the set of Responder identities it is allowed to communicate with. In trust on first use (TOFU) use cases the Initiator should verify that the the Responder's identity is not equal to its own. Any future EHDOC methods using e.g., pre-shared keys might need to mitigate this in other ways.
In the Editor's copy, the second bullet point at [1] says: Could you clarify the exact meaning of "simultaneous EDHOC message exchange" and which of the existing EDHOC sessions should be checked? In particular, is this limited to checking the sessions that the Responder has started but are still not completed, while simply skipping all the other ones? If so, can a session be considered completed when TH_4 has been computed and stored, or even earlier than that? [1] https://lake-URL
Yes, let's clarify that.
It would also help narrowing that statement to where it is actually relevant. Reading over "all the state" in a system can be costly, and becomes less and less well-defined the more a system becomes distributed. Reading (for example, if that is the case) over "all the state of exchanges that use a particular PSK" would be more doable.
I certainly agree.
I agree. The GX is a leftover from the time when we had a PSK mode, It was left as it theoretically is a nice way to stop selfie-attacks for future methods. Given the practical problems and that this is not needed for any of the current methods with mutual authentication I think it should be removed from processing and moved back to security considerations. For method 0-3 with mutual authentication, selfie-attacks are not a problem, I will authenticate R. For method 0-3 with TOFU, selfie-attacks are a problem, but can then be solved by the looking at CREDR and making sure CREDR was not previously sent by I. This is easier to do then checking active GX. For a hypothetical future EDHOC PSK mode, selfie-attack can be mitigated by doing the G_X check, assign strict roles (I or R) to each PSK, or adding some identifier string to e.g. EAD ("42-50-31-FF-EF-37-32-39").
I made a PR which should address all the aspects of this issue. Deleted all GX checking text Separated reflection attack checking from simultanous sessions. Added the following text To mititgate reflection attacks, the Initiator MUST verify that the the Responder's identity is not equal to Initiator's, e.g., by checking that IDCREDR was not previosly created by the Intiator. Any future EHDOC methods using e.g., pre-shared keys might need to mitigate this in other ways. Should it be mentioned in message2 processing? Should it be MUST? Should it take specifically about TOFU?
Addresses Marcos comments. Seems to be agreement on new text. Merging and closing

Decode message_1 (see CBOR).  Verify that the selected cipher suite is supported and that no prior cipher suite in SUITES_I is supported. of SP-800-56A.  For secp256r1, secp384r1, and secp521r1, at least partial public-key validation MUST be done. <ins> So-called selfie attacks are mitigated as long as the Initiator does not have its own identity in the set of Responder identities it is allowed to communicate with.  In trust on first use (TOFU) use cases the Initiator should verify that the the Responder's identity is not equal to its own.  Any future EHDOC methods using e.g., pre-shared keys might need to mitigate this in other ways. </ins> 8.3. When using private cipher suite or registering new cipher suites, the If two nodes unintentionally initiate two simultaneous EDHOC message exchanges with each other even if they only want to complete a single EDHOC message exchange, they MAY terminate the exchange with the  <ins> lexicographically smallest G_X.  Note that in cases where several EDHOC exchanges with different parameter sets (method, COSE headers, etc.) are used, an attacker can affect which of the parameter sets that will be used by blocking some of the parameter sets. </ins> If supported by the device, it is RECOMMENDED that at least the long- term private keys are stored in a Trusted Execution Environment (TEE)


IANA has created a new registry titled "EDHOC Exporter Label" under the new group name "Ephemeral Diffie-Hellman Over COSE (EDHOC)".  The registration procedure is "Expert Review".  The columns of the <del> registry are Label, and Description.  Label is a uint.  Description is a text string.  The initial contents of the registry are: </del>  9.2. IANA has created a new registry titled "EDHOC Cipher Suites" under the new group name "Ephemeral Diffie-Hellman Over COSE (EDHOC)".  The registration procedure is "Expert Review".  The columns of the <del> registry are Value, Array, Description, and Reference, where Value is an integer and the other columns are text strings.  The initial contents of the registry are: </del>  9.3. IANA has created a new registry entitled "EDHOC Method Type" under the new group name "Ephemeral Diffie-Hellman Over COSE (EDHOC)".  The <del> registration procedure is "Expert Review".  The columns of the registry are Value, Description, and Reference, where Value is an integer and the other columns are text strings.  The initial contents of the registry are shown in fig-method-types. </del>  9.4.

I am against adding a stupid reference column.
NAME Noted. Is the rest OK?
Currently a mixture of: The registration procedure is "Expert Review". The registration procedure is "Specification Required".
I changed EDHOC Error Code Registry to "Expert Review" to align with the others. It makes no sense that the Error registry has harder requirements than the methods or cipher suite registry, We should maybe discuss Registration procedures for the new EDHOC registries at IETF 112. Right now they are all expert review without any differentiation between small and big numbers. We should discuss what is the right approach.
The registries was aligned in -12 and the topic was discussed at the Oct 5 interim without any suggestions for change. The expert instructions seem to cover all the aspects discussed during the interim
Reopen based on the comment by Kathleen. At least new EDHOC method types would typically require specification.
Makes sense to me
Was is the status of this? This should be quick and easy to fix and close.
The plan is to update Section 9.4 and replace "Expert Review" with "Specification Required". I noted now that in that section the columns of the registry are: but the table with the referred initial contents (Figure 4) has columns:
It should be 9.4 I think "Value, Description, and Reference" is correct, but just referencing Figure 4 does not work.
We may need two tables. Figure 4 doesn't need to have a Reference column. We can make another table in 9.4 with "Value, Description, and Reference", where Description is "Initiator and Responder uses signature key for authentication" etc.
A reference column is never needed. I would suggest to remove it from all the Tables in Section 9. That column is needed on the IANA homepage but does not help anybody in the EDHOC specification. IANA is smart enough to use the correct reference without us giving them a column.
Maybe Description should be separated into Initiator Authentication Key, Responder Authentication Key,
The comments above about section 9.4 refers to 9.3 [EDHOC Method Type Registry] in the current master branch.
An attempt to address all comments in PR . I kept the column for References for the registries where a specification is required, method (9.3) and EAD (9.5).
References column removed also in cases where spec. is required in , which is now merged.

IANA has created a new registry titled "EDHOC Exporter Label" under the new group name "Ephemeral Diffie-Hellman Over COSE (EDHOC)".  The registration procedure is "Expert Review".  The columns of the  <ins> registry are Label and Description.  Label is a uint.  Description is a text string.  The initial contents of the registry are: </ins> 9.2. IANA has created a new registry titled "EDHOC Cipher Suites" under the new group name "Ephemeral Diffie-Hellman Over COSE (EDHOC)".  The registration procedure is "Expert Review".  The columns of the  <ins> registry are Value, Array and Description, where Value is an integer and the other columns are text strings.  The initial contents of the registry are: </ins> 9.3. IANA has created a new registry entitled "EDHOC Method Type" under the new group name "Ephemeral Diffie-Hellman Over COSE (EDHOC)".  The  <ins> registration procedure is "Specification Required".  The columns of the registry are Value, Initiator Authentication Key, and Responder Authentication Key, where Value is an integer and the other columns are text strings describing the authentication keys.  The initial contents of the registry are shown in fig-method-types. </ins> 9.4.


Choose a connection identifier C_R and store it for the length of the protocol. <del> Compute the transcript hash TH_2 = H( H(message_1), G_Y, C_R ) </del>  where H() is the EDHOC hash algorithm of the selected cipher suite.  The transcript hash TH_2 is a CBOR encoded bstr and the input to the hash function is a CBOR Sequence.  Note that

This allows to future proof the protocol against a weak hash with chose-prefix collisions. It corresponds to , and is also mentioned in .
There has been a lot of suggestions and discussion regarding the key derivation latelely. Below is an attempt to summarize all the current suggstions that currently seems relatively likely to be done. This is not an issue in itself but I think it is good to have somewhere to discucess the complete changes to the key derivation. Suggested to permute the order of element in the TH2 sequence to be more resistant to any future collision attacks in hash functions. Exact order unclear but suggested to put the random and unpredictable GY first. Suggested to use PLAINTEXT instead of CIPHERTEXT in transcript hashes to simplify formal verification. Endpoints agree on that they received the same plaintext rather then the same cipertext.Suggested to use a salt derived from PRK in Extract to avoid usign the PRK keys directly in both Extract and ExpandSuggested to use unsigned integer instead of text string for label to save memory.Suggestion to add a final key derivation PRKout and use that in the exporter. Note that the exporter would also have uint labelsSuggestion to base Key-Update on Expand instead of extract. The label would need IANA registration. hashlength is a new variable that the implementation needs to keep track of. Should considered whether using Exporter for KeyUpdate has any disadvantages. Suggested that more info on how an application protocol is supposed to use KeyUpdate and Exporter together is needed.The EDHOC internal key derivations (i.e., not using the Exporter) would then be something like below. The exact labels should be discussed. Note that that only some of the derivations actually need a label to avoid collisionIncluding KeyUpdate, the IANA registered exporter labels could be:
Looks good. I had different naming in mind of the salts: PRK3e2m = Extract( SALT3e2m, GRX ) PRK3m = Extract( SALT3m, GIY ) where SALT3e2m = EDHOC-KDF( PRK2e, TH2, 0, h'', hashlength ) SALT3m = EDHOC-KDF( PRK3e2m, TH3, 0, h'', hashlength ) With this the salts are named by its use rather than from what key they are derived.
The labels was just to illustrate the fact that they don't need to be separate. I think it is still better to just use 0-7. That makes it very easy for the reader to see that there are no collisions.
NAME Was this a comment on my proposed names of salts, or a separate comment? (I agree labels 0-7 is good.)
It was a separate comments. Your suggestion for salt naming is fine with me. Some other non-technical naming things that a hidden in my summary above I think keylength should use different terms in the derivation of K4 and OSCORE Master Secret. The current naming gives the idea that they are the same. I think the contexts in the MAC2 and MAC3 derivations should be given names. Should consider collection all the EDHOC-KDF derivations in a single place.
Might want to derive: K4 = EDHOC-KDF( PRK3m, TH4, 0, h'', keylength ) IV4 = EDHOC-KDF( PRK3m, TH4, 0, h'', ivlength ) to avoid that the applicaiton gets K4 and IV4. Another alternative is to use K4 = EDHOC-Exporter( 7, h'', keylength ) IV4 = EDHOC-Exporter( 8, h'', ivlength ) and forbid the application to use the labels for K4 and IV4
Editorial; should be: K4 = EDHOC-KDF( PRK3m, TH4, 1, h'', keylength ) IV4 = EDHOC-KDF( PRK3m, TH4, 2, h'', ivlength ) or, if we want all KDF labels distinct: K4 = EDHOC-KDF( PRK3m, TH4, 8, h'', keylength ) IV4 = EDHOC-KDF( PRK3m, TH4, 9, h'', ivlength ) Alternatively, application access to Exporter only allows uint with: K4 = EDHOC-Exporter( -1, h'', keylength ) IV4 = EDHOC-Exporter( -2, h'', ivlength )
Trying to compile the suggestions. These have a PR: Suggested to permute the order of element in the TH2 sequence … Suggested to use PLAINTEXT instead of CIPHERTEXT in transcript hashes … Suggestion to add a final key derivation PRKout and use that in the exporter The following needs to be addressed: Suggested to use a salt derived from PRK in Extract define salt derive salt Suggested to use unsigned integer instead of text string for label to save memory suggestion to base Key-Update on Expand consider whether using Exporter for KeyUpdate has any disadvantages. more info on how an application protocol is supposed to use KeyUpdate and Exporter together distinguish keylength in K3/K_4 and OSCORE Master Secret define contexts explicitly table of KDF derivations
Trying to put things together. Let's call this variant A, part 1. where and (edit: depending on method) New salts to avoid double use of PRK, named by its use. Same construction for K4/IV4 as K3/IV3, motivating the renaming of 3m in as 4e3m. The label in the KDF, third argument, is an uint, all distinct for simplicity.
Variant A, part 2: Distinct "transcript hash" in KeyUpdate and Exporter. Exporter does not give access to EDHOC internal keys. OSCORE key length separate from key_length. Edit: Not clear that 'context' is needed in the EDHOC-Exporter. Also, to be strict in labelling we could continue enumeration. Here is variant B, part 2 (B.1 = A.1):
Variant C.2 (C.1 = A.1): (edited:) Same as B.2 but with different labels. With variant C we have essentially: the internal KDF labels with current list: 0, ..., 9; and the IANA EDHOC Exporter Registry with current list: 0, 1.
NAME NAME NAME and all: Any implementation considerations or other comments on variant C above? We'll start with the PR(s) soon.
The last posts here are confusing.... I don't agree. These are separate. We should definitly not try to keep them separate. I.e. it should be Master Secret = EDHOC-Exporter( 0, h'', oscorekeylength ) Master Salt = EDHOC-Exporter( 1, h'', oscoresaltlength )
The above looks good to me with the following not so interesting options. order of the 0-9 labels use 10 or 0 label for Key-Update order of the h'00' and h'01' "transcripts"
I think we should maybe merge the "context" and "transcript hash" inputs. This simplifies things and avoids using h'00' and h''01' as "transcript hashes.
Alternatively
The latest version of the summary URL looks good.
Overview of main changes needed: Merge Rename PRK3m as PRK4e3m Section 4.1 update PRK definitions move section PRKout to 4.2 Section 4.2 Update EDHOC-KDF and info definition Update derivations Include derivations of salts and K4 / IV4 List EDHOC-KDF derivations with labels 0-9 Section 4.3 Update EDHOC-Exporter (use label 10 instead of 11) Remove derivation of K4 / IV4 Section 4.4 Update EDHOC-KeyUpdate (use label 11 instead of 10) Section 5.3.2 Define context2 Section 5.4.2 Define context3 Section 9.1 Update EDHOC Exporter labels Appendix A.1 Update Master Secret/Salt derivation
Additional updates: As noted in previous comment, a proposal to interchange labels 10 and 11 to enumerate labels in the order they appear in the specification. (Other proposal for assignment of integer labels is welcome.) Should we align / adapt definition of contextx and externalaad? Currently (for message2 and similar for message3): externalaad = > context2 = > Edit: Seems to be favourable to at least align this blobs, so changed context2 to > and similar for context_3, in 5464707a
PRKexporter is a key which we only introduce for simple distinction between different KDF applications. Perhaps an overkill? May open up for unnecessary discussion about properties of that key. Here is another variant: Edit: As commented before, Marco thinks a separate PRKExporter is preferred; less error prone etc.
Most old comments are now addressed, and there are quite a few changes, so it is a good time to merge PR . Remaining points: derivation of K4/ IV4 and text about key confirmation. Not clear if there is any difference in practice between K4 /IV4 being derived from PRK4e3m or PRKout, but the current text about explicit key confirmation is not valid in the former case. May alternatively tune down the key confirmation terminology. Suggested to make clearer distinction between key derivation for EDHOC processing, resulting in PRKout, and key derivation for application, i.e. making use of PRKout in EDHOC-Exporter and EDHOC-KeyUpdate. More guidance on the latter is also proposed.
Tried to address the remaining points in the previous comment with the latest two commits: 5d675ac and 95e35bb. More guidance on KeyUpdate may still be needed. Other points?
NAME What more guidance is needed on KeyUpdate?
Was a request from someone. Might be hard to understand how to use it. E.g. that you should alternate key update and exporter Exporter Key Update Exporter Key Update Exporter ...
Another guidance needed is how to manage overwrite of PRKout pending confirmation of the derived key from the other endpoint. When the Initiator is updating PRKout it needs both old and new derived keys to be able to communicate securely in lock-step the change to the new key.
Perhaps good to remark that the entire application contexts (including e.g. sequence numbers) need to be maintained before a transition is made.
see instead. The current discussion has very little to do with
Looks good. I think should do this change.

Choose a connection identifier C_R and store it for the length of the protocol.  <ins> Compute the transcript hash TH_2 = H( G_Y, C_R, H(message_1) ) </ins> where H() is the EDHOC hash algorithm of the selected cipher suite.  The transcript hash TH_2 is a CBOR encoded bstr and the input to the hash function is a CBOR Sequence.  Note that


The EDHOC protocol consists of three mandatory messages (message_1, message_2, message_3) between Initiator and Responder, an optional fourth message (message_4), and an error message.  All EDHOC messages <del> are CBOR Sequences RFC8742. fig-flow illustrates an EDHOC message flow with the optional fourth message as well as the content of each message.  The protocol elements in the figure are introduced in overview and asym.  Message formatting and processing are specified in asym and error. </del>  Application data may be protected using the agreed application algorithms (AEAD, hash) in the selected cipher suite (see cs) and the make use of a so called running hash, this is a design choice as running hashes are often not supported on constrained platforms.  9. 9.1.

It is stated that EDHOC uses deterministic CBOC, but EDHOC could still be non-deterministic if is allows a choice between e.g., bstr and int. Add that the encodig in EDHOC is deterministic. Add some considerations regarding decoding. In any cryptographic protocols the optimal for security is that the decoder raises a fatal error if the something in the encoding is enexpected. E.g. wrong order in map or two byte encoding of the integer 7. This is however not supported by CBOR implementations so it cannot be mandated. The security issues with a allowing decoder is that is gives options to an attacker. If the hash function has some weakness, An attacker can e.g. try all n! permutations of a map with n elements until they find a collision. This is not critical but it might be guidance that a decoder that only tolerated deterministic CBOR might have security benefits.
That would be interesting, notably as it was mentioned as an attack surface previously (). Bellow is an additional example of the kind of weird things that can go on when everything is not nice and deterministic. Consider an attacker that can only modify messages going from Rresponder R to Initiator I, but not send its own messages to R. Then, the identity of R should intuitively be anonymous. This could be the case of an attacker only sitting next to the device I, and who wants to know from whom I is receiving messages. The attacker wants to tests if some I is communicating with some fixed identity . This attacker may intercept the message2 encrypted part: . Now assume that there exists a second distinct encoding of , that we call . The attacker can then compute . Now, two options, either , in which case the message received by I is , which will successfully proceed. If , the processing of the message will fail. And thus, the attacker can learn if I is talking to or not. Remark that in both cases, the key exchange will fail at the next step as parties will disagree on .
Decoding considerations should consider deterministic CBOR, CDDL, and anything outside CBOR and CDDL.
The text about decoding should recommend to abort if encoding not deterministic.
"All EDHOC messages are deterministically encoded CBOR Sequences {{RFC8742}}." Do we need to clarify the meaning of "deterministically encoded CBOR Sequences"? Readers may be lead to believe it is defined in RFC8742.

The EDHOC protocol consists of three mandatory messages (message_1, message_2, message_3) between Initiator and Responder, an optional fourth message (message_4), and an error message.  All EDHOC messages  <ins> are CBOR Sequences RFC8742, and are deterministically encoded. fig- flow illustrates an EDHOC message flow with the optional fourth message as well as the content of each message.  The protocol elements in the figure are introduced in overview and asym.  Message formatting and processing are specified in asym and error. </ins> Application data may be protected using the agreed application algorithms (AEAD, hash) in the selected cipher suite (see cs) and the make use of a so called running hash, this is a design choice as running hashes are often not supported on constrained platforms. <ins> When parsing a received EDHOC message, implementations MUST terminate the protocol if the message does not comply with the CDDL for that message.  It is RECOMMENDED to terminate the protocol if the received EDHOC message is not deterministic CBOR. </ins> 9. 9.1.


identifiers from EDHOC SHOULD provide mechanisms to update the connection identifier and MAY provide mechanisms to issue several simultaneously active connection identifiers.  See RFC9000 for a non- <del> constrained example of such mechanisms. </del>  8.6.

Some additional text on connection id privacy New connections identifiers needs to be unpredictable to provide improved privacy QUIC requirement to not use the same identifier in a connection seems like nonsense that lowers privacy compared to random selection and increases implementation complexity. Christian Amsuss pointed out in a discussion in CORE that connection id privacy often does not make sense in many deployments as there are fixed identifier in lower layers
LGTM
If connection identifiers are predictable (e.g., a sequence) they might be used by an attacker to determine that the two EDHOC sessions came from the same device. We should add a sentence on this. In practice it does not matter unless IP address, MAC address, etc are randomized as well.
Isn´t it covered by sec 8.5?: Essentially, any of the additional data (EADs and CI/CR) can be used to attack privacy, whether anonymity or unlinkability. A side remark is that even with padding, if any of the EADs is a counter, the length of messagex can allow to distinguish high intensity traffic vs low intensity traffic.
Yes, it does. The text is more general then I thought. Should probablt have some guidance on non-predictable connection identifiers. If a device is using a sequence like 0x3489f2, 0x3489f3, 0x3489f4, 0x3489f5 updating the connection identifier is quite useless.

identifiers from EDHOC SHOULD provide mechanisms to update the connection identifier and MAY provide mechanisms to issue several simultaneously active connection identifiers.  See RFC9000 for a non-  <ins> constrained example of such mechanisms.  Connection identifiers SHOULD be unpredictable.  Using the same identifier several times is not a problem as long as it is chosen randomly.  Connection identity privacy mechanisms are only useful when there are not fixed identifiers such as IP address or MAC address in the lower layers. </ins> 8.6.


CIPHERTEXT_2 is calculated by using the Expand function as a binary additive stream cipher over the following plaintext: <del> PLAINTEXT_2 = ( ? PAD, ID_CRED_R / bstr / -24..23, </del>  Signature_or_MAC_2, ? EAD_2 ) If ID_CRED_R contains a single 'kid' parameter, i.e., is conveyed in the plaintext, represented as described in bstr-repr. <del> PAD = 1* "true" (see CBOR) is padding that may be used to </del>  hide the length of the unpadded plaintext Compute KEYSTREAM_2 as in expand, where plaintext_length is the prepended C_I, see coap). Decrypt CIPHERTEXT_2, see asym-msg2-proc, and, if present, discard <del> padding. </del>  Make ID_CRED_R and (if present) EAD_2 available to the application for authentication- and EAD processing. K_3 and IV_3 are defined in <del> PLAINTEXT_3 = ( ? PAD, ID_CRED_I / bstr / -24..23, </del>  Signature_or_MAC_3, ? EAD_3 ) If ID_CRED_I contains a single 'kid' parameter, i.e., is conveyed in the plaintext, represented as described in bstr-repr. <del> PAD = 1* "true" (see CBOR) is padding that may be used to </del>  hide the length of the unpadded plaintext CIPHERTEXT_3 is the 'ciphertext' of COSE_Encrypt0. Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of I-D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in the selected cipher suite, and the parameters defined <del> in asym-msg3-proc.  Discard padding, if present. </del>  Make ID_CRED_I and (if present) EAD_3 available to the application for authentication- and EAD processing. K_4 and IV_4 are defined in <del> PLAINTEXT_4 = ( ? PAD, ? EAD_4 ) </del>  <del> PAD = 1* "true" (see CBOR) is padding that may be used to </del>  hide the length of the unpadded plaintext. EAD_4 - external authorization data, see AD. Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of I-D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in the selected cipher suite, and the parameters defined <del> in asym-msg4-proc.  Discard padding, if present. </del>  Make (if present) EAD_4 available to the application for EAD processing.

This is an editorial change.
If there is a risk someone thinks that padding in the messages must be the same we could use PAD2, PAD3, PAD_4.
If I understand correctly, the PAD is to hide the length of the messages. If the three messages share the same PAD length, it is enough for one of the message to have a length known by the attacker, e.g. if EAD_4 is of constant length across all sessions, to leak the length of the PAD, and thus the length of the other messages contents. As such, 3 distinct padding lengths would be strictly better. Otherwise, as the encryptions are distinct (different key streams), I on my side don't see any weird cryptographic interactions that would be possible. (a side question is does the padding in message 2 leads to potential for padding oracles attacks, where the attacker could try to flip a few bytes of the cyphertext and learn some information based on which step of the processing fail. However, that is covered by I guess)
This is an editorial change. I merged the PR and will close this issue. No and yes. SIGMA and EDHOC and TLS 1.3 does not provide confidentiality of the second flight to active attackers (except maybe the signature). In SIGMA and EDHOC and attacker can modify the second flight and gain information. But this attack seems very uninteresting compared to attacks where the attacker modifies message_1.

CIPHERTEXT_2 is calculated by using the Expand function as a binary additive stream cipher over the following plaintext:  <ins> PLAINTEXT_2 = ( ? PAD_2, ID_CRED_R / bstr / -24..23, </ins> Signature_or_MAC_2, ? EAD_2 ) If ID_CRED_R contains a single 'kid' parameter, i.e., is conveyed in the plaintext, represented as described in bstr-repr.  <ins> PAD_2 = 1* "true" (see CBOR) is padding that may be used to </ins> hide the length of the unpadded plaintext Compute KEYSTREAM_2 as in expand, where plaintext_length is the prepended C_I, see coap). Decrypt CIPHERTEXT_2, see asym-msg2-proc, and, if present, discard  <ins> the padding PAD_2. </ins> Make ID_CRED_R and (if present) EAD_2 available to the application for authentication- and EAD processing. K_3 and IV_3 are defined in  <ins> PLAINTEXT_3 = ( ? PAD_3, ID_CRED_I / bstr / -24..23, </ins> Signature_or_MAC_3, ? EAD_3 ) If ID_CRED_I contains a single 'kid' parameter, i.e., is conveyed in the plaintext, represented as described in bstr-repr.  <ins> PAD_3 = 1* "true" (see CBOR) is padding that may be used to </ins> hide the length of the unpadded plaintext CIPHERTEXT_3 is the 'ciphertext' of COSE_Encrypt0. Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of I-D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in the selected cipher suite, and the parameters defined  <ins> in asym-msg3-proc.  Discard the padding PAD_3, if present. </ins> Make ID_CRED_I and (if present) EAD_3 available to the application for authentication- and EAD processing. K_4 and IV_4 are defined in  <ins> PLAINTEXT_4 = ( ? PAD_4, ? EAD_4 ) </ins>  <ins> PAD_4 = 1* "true" (see CBOR) is padding that may be used to </ins> hide the length of the unpadded plaintext. EAD_4 - external authorization data, see AD. Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of I-D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in the selected cipher suite, and the parameters defined  <ins> in asym-msg4-proc.  Discard the padding PAD_4, if present. </ins> Make (if present) EAD_4 available to the application for EAD processing.


where <del> label is a uint </del>  context is a bstr where <del> label is a registered uint from the EDHOC Exporter Label registry (exporter-label) </del>  context is a bstr defined by the application algorithm of the selected cipher suite.  Note that PRK_exporter changes every time EDHOC-KeyUpdate is used, see keyupdate. <del> The (label, context) pair used in EDHOC-Exporter must be unique, i.e., a (label, context) MUST NOT be used for two different purposes. However an application can re-derive the same key several times as long as it is done in a secure way.  For example, in most encryption algorithms the same key can be reused with different nonces.  The context can for example be the empty CBOR byte string. </del>  Examples of use of the EDHOC-Exporter are given in transfer.

In the latest commit there are new names to distinguish infolabel and exporterlabel, the former is extended to be int. I also noted an error in the CDDL reference section C.2.
The current design of encryption of message2 in EDHOC limits the size of the message to 8160 bytes when SHA-256 is used. Is that a problem? message2 consists of the fields GY IDCREDR SignatureorMAC2 CR and optional fields: ? PAD2 ? EAD2 While these message fields could be very small, depending on use case, some may be arbitrarily large. The field IDCREDR would typically be a reference to an authentication credential, but may contain the credential itself, for example a certificate chain. EAD2 is defined by the application so may a priori be large. One example is revocation information. John: SHA-384 has the limit 12240 bytes and SHA-512 has the limit 16320 bytes. SHAKE128 and SHAKE256 have much much larger limits (2^2040 − 1 bits)
Some of the alternatives: Do nothing / this is not a problem Replace HKDF with HKDF', which allows larger length of output Use HKDF for message2 size < 8160, HKDF' for larger message2 Replace message_2 encryption with AES-CTR / ChaCha20 Use KMAC instead of HKDF Edit: Multiple applications of HKDF, to produce sufficiently long keystream John: HKDF' here refer only to HKDF-Expand. HKDF-Extract would stay the same. John: HKDF' would still be HKDF but not HKDF as specified in RFC 5869. The original HKDF paper just states that the counter is fixed length. RFC 5869 unfortunately chose 1 byte. URL
It seems that this is a concern if/when GY or SignatureorMAC2 becomes one of the monstrous Post-Quantum algorithms, or a HSS. I think that we should rule that out of scope, say that when it happens that we'll do EDHOC2 based upon new constraints at the time. I think that 8K is probably enough for the certificate chain. That's a lot (100) of 802.15.4 fragments. So unless switching to HKDF' is really cheap, don't bother.
Thanks Michael. Yes, the assumption so far has been "this is not a problem". NAME It would be good to understand the impact on implementation if we would come to a different conclusion. Please comment, on the examples below. Replace HKDF with HKDF', which allows larger length of output HKDF is constructed from HMAC using a counter which is 8 bits long. By defining HKDF' with 16 / 32 bits counter would make the output 2 MB / 137 GB (if I did the maths right) before the counter wraps. How is HKDF implemented today? Is it feasible to define your own variant, say with 32 bits counter? Use HKDF for message2 size >
PR is included in -16

where  <ins> info_label is an int </ins> context is a bstr where  <ins> exporter_label is a registered uint from the EDHOC Exporter Label registry (exporter-label) </ins> context is a bstr defined by the application algorithm of the selected cipher suite.  Note that PRK_exporter changes every time EDHOC-KeyUpdate is used, see keyupdate.  <ins> The (exporter_label, context) pair used in EDHOC-Exporter must be unique, i.e., an (exporter_label, context) MUST NOT be used for two different purposes.  However an application can re-derive the same key several times as long as it is done in a secure way.  For example, in most encryption algorithms the same key can be reused with different nonces.  The context can for example be the empty CBOR byte string. </ins> Examples of use of the EDHOC-Exporter are given in transfer.


Verification of the selected cipher suite. <del> Method types and error handling. </del>  Selection of connection identifiers C_I and C_R which may be used in EDHOC to identify protocol state. Application data may be protected using the agreed application algorithms (AEAD, hash) in the selected cipher suite (see cs) and the application can make use of the established connection identifiers <del> C_I and C_R (see ci).  EDHOC may be used with the media type application/edhoc+cbor-seq defined in media-type. </del>  The Initiator can derive symmetric application keys after creating EDHOC message_3, see exporter.  Protected application data can

There are now two different media types defined. Padding was missing from the list that EDHOC adds.

Verification of the selected cipher suite.  <ins> Method types, error handling, and padding. </ins> Selection of connection identifiers C_I and C_R which may be used in EDHOC to identify protocol state. Application data may be protected using the agreed application algorithms (AEAD, hash) in the selected cipher suite (see cs) and the application can make use of the established connection identifiers  <ins> C_I and C_R (see ci).  Media types that may be used for EDHOC are defined in media-type. </ins> The Initiator can derive symmetric application keys after creating EDHOC message_3, see exporter.  Protected application data can


sufficient to fit the analysis of secure shared signature and ECDH key usage in Degabriele11 and Thormarker21. <del> So-called selfie attacks are mitigated as long as the Initiator does not have its own identity in the set of Responder identities it is </del>  allowed to communicate with.  In Trust on first use (TOFU) use cases, see tofu, the Initiator should verify that the Responder's identity is not equal to its own.  Any future EHDOC methods using e.g., pre- <del> shared keys might need to mitigate this in other ways. </del>  8.3.

PR to Largely based on the text suggested by NAME but will some changes.
The selfie attack mitigation implies that an initiator is stopping the exchange if it receives its own identity. An active attacker can then use this behavior to test if an initiator identity is the same one as a responder identity. In turn, it implies that the initiator anonymity does not hold against an active attacker when this mitigation is enabled. To judge if this is an issue in practice, the following question should be answered: Are there scenarios where an identity is shared between an initiator and a receiver, but the initiator identity should still be protected? One could maybe think about the case where multiple initiators and receivers are on the same server, sometimes sharing public keys and using distinct ports, but it is expected that the initiators identities are still protected. Possible actions: mention privacy loss due to the selfie attack mitigation. update the selfie attack mitigation, by mentioning that initiators should conclude the exchange as usual, but can check at the end whether they are talking to themselves or not. remove the selfie attack mitigation. Classical selfie attacks are when there is a pre-shared key between an initiator and a receiver, and the initiator will be talking to itself while it believes to be talking to the receiver. When there are only public keys, as in EDHOC, it is unclear to me if what is currently called in the draft is indeed a selfie attack. An initiator talking to itself knows it and does not believe to be talking to some other identity. As such this is why it could be possible to either remove the mention of selfie attacks in the draft, or update it.
I and R are expected to stop the exchange it they receive any identity they do not want to talk to. This likely includes their own identity. Good point that this leaks information. I think that should be added, but I don't see that the own identity is special. >Classical selfie attacks are when there is a pre-shared key between an initiator and a receiver, >and the initiator will be talking to itself while it believes to be talking to the receiver. >When there are only public keys, as in EDHOC, it is unclear to me if what is currently >called in the draft is indeed a selfie attack. The selfie attack mitigation is intended for Trust On First Use (TOFU) use cases, where there is no authentication in the initial setup. I don't think an initiator talking to itself in a TOFU use case would not know it except if they checked R's public key. Do you some better suggestion than "Selfie attack". I agree that it is not perfect. "Selfie attacks" has in older papers been called reflection attacks, but the term reflection attacks has also been used for very different attacks. One option is to not give the attack any name and instead just describe the attack.
I think I like to not give any name, as it does not perfectly match the classical definition. Here, the property which is violated is "If an EDHOC exchange is completed, two distinct identities/computers/agents were active". Which is different to violating the authentication of the protocol as is the case in classical selfie attacks. Good point. So what we are talking about in this issue is a slightly different privacy leak, which happens when the set of parties you are willing to talk to is equal to all responders minus yourself. To be more concrete, let me try to put it in a kind of drafty formal description that could replace the existing formulation. First the existing formulation: Now a possible replacement:
Thanks for the input! This issue is related to the TOFU use case which is still to be detailed (Appendix D.5). We probably should wait with the update until we have progressed that.
Relates to
I made PR for this issue. This is also related to PR and PR . The suggested text in is largely based on the suggested text above but I made some changes. I did not think this fitted well with the rest of the draft. The sentence was also not really needed. This is only true in the case where the set of identifiers is a small finite set. In the general case the set of identifiers the Initiator is not willing to communicate with is infinite. I suggest to add the following recommendation for TOFU To not leak any long-term identifiers, it is recommended to use a freshly generated authentication key as identity in each initial TOFU exchange.
I merged the PR to master. Keeping the issue open for a while.

sufficient to fit the analysis of secure shared signature and ECDH key usage in Degabriele11 and Thormarker21.  <ins> The property that a completed EDHOC exchange implies that another identity has been active is upheld as long as the Initiator does not have its own identity in the set of Responder identities it is </ins> allowed to communicate with.  In Trust on first use (TOFU) use cases, see tofu, the Initiator should verify that the Responder's identity is not equal to its own.  Any future EHDOC methods using e.g., pre-  <ins> shared keys might need to mitigate this in other ways.  However, an active attacker can gain information about the set of identities an Initiator is willing to communicate with.  If the Initiator is willing to communicate with all identities except its own an attacker can determine that a guessed Initiator identity is correct.  To not leak any long-term identifiers, it is recommended to use a freshly generated authentication key as identity in each initial TOFU exchange. </ins> 8.3.


The Initiator SHALL compose message_3 as follows: <del> Compute the transcript hash TH_3 = H(TH_2, PLAINTEXT_2) where H() is the EDHOC hash algorithm of the selected cipher suite.  The transcript hash TH_3 is a CBOR encoded bstr and the input to the hash function is a CBOR Sequence.  Note that H(TH_2, PLAINTEXT_2) can be computed and cached already in the processing of message_2. </del>  Compute MAC_3 as in expand, with context_3 = << ID_CRED_I, TH_3, CRED_I, ? EAD_3 >> CIPHERTEXT_3 is the 'ciphertext' of COSE_Encrypt0. <del> Compute the transcript hash TH_4 = H(TH_3, PLAINTEXT_3) where H() is the EDHOC hash algorithm of the selected cipher suite.  The transcript hash TH_4 is a CBOR encoded bstr and the input to the hash function is a CBOR Sequence. </del>  Calculate PRK_out as defined in fig-edhoc-kdf.  The Initiator can now derive application keys using the EDHOC-Exporter interface, protocol SIGMA.  Using the terminology from SIGMA, EDHOC provides forward secrecy, mutual authentication with aliveness, consistency, and peer awareness.  As described in SIGMA, peer awareness is <del> provided to the Responder, but not to the Initiator. </del>  As described in SIGMA, different levels of identity protection are provided to the Initiator and the Responder.  EDHOC provides identity

Change implementing the change to TH3 and TH4 suggested by Marc and Felix in
Following our last email and in preparation for the IETF 114, we would like to offer a suggestion from our computational analysis of EDHOC. I will first state the suggestion and then give some motivation and justification. Suggestion: Include the authentication credentials in the transcript hash computation. Namely, we suggest modifying the transcript hashes TH3 and TH4 to include the credential of the peer that authenticate themselves. More precisely, we propose that protocol participants compute: Similarly, we propose that the computation of TH4 becomes The philosophy behind this proposal is to make explicit the identity of the peer that authenticated themselves, even if those identities are not sent. (One can think of this as expanding TH to include the actual identity credentials, which the sent IDCRED values hint to but do not uniquely determine). This is to simplify arguing agreement on the communication peer. Motivation and justification: We analysed EDHOC in the Multi-Stage Key exchange model, following the work [Dow21] of Dowling et al. We suggest the change above as an improvement towards ensuring explicit authentication, which we observed when analysing the following excerpt from the draft (draft-14, section 3.5.3): "As stated in Section 3.1 of [I-D.ietf-cose-rfc8152bis-struct], applications MUST NOT assume that 'kid' values are unique, and several keys associated with a 'kid' may need to be checked before the correct one is found. Applications might use additional information such as 'kid context' or lower layers to determine which key to try first. Applications should strive to make IDCREDx as unique as possible, since the recipient may otherwise have to try several keys." We modelled the above statement conservatively and considered that any IDCRED might reference multiple identities and associated credentials. A potential consequence of this modelling is that there may be ambiguity about the identity of the peer who authenticated themselves, which needs careful consideration. For instance, if IDCREDR refers to both CREDR and CREDR', the initiator that tries multiple public keys could conclude that it is talking to R'. If this occurs, the protocol would still come to completion since the transcript hash won't change. The standard unforgeability notion of signature schemes would not necessarily prevent such a scenario [1], and our analysis relies on strictly stronger notions. Concretely we require that signature schemes in EDHOC provide explicit ownership. In our model and proof, we had to rely on the relatively strong notion of "Malicious Universal Exclusive Ownership" to capture explicit authentication for EDHOC as currently specified. To the best of our knowledge, M-S-UEO was only studied and proven for Ed25519 as implemented in Libsodium[Bre20]. Therefore, relying on a weaker notion, "Universal Exclusive Ownership", is desirable. Adding the credentials in the transcript hash would prevent identity mis-binding attacks since divergence in the identity of the authenticated host would lead to diverging transcript hashes and, therefore, different derived keys. Furthermore, we can rely on weaker notions of explicit ownership from a proof standpoint. Fortunately, Ed25519 provides explicit ownership [Bre20], and [Po05] already showed that the inclusion of the credentials along with the message in the signing process, as is done already in EDHOC, provides explicit ownership and prevents ambiguity. For ECDSA, care must be taken in the implementation so that this construction guarantees exclusive ownership. Overall, we assume that CBOR encoding is unambiguous. We would very much appreciate your feedback and thoughts on the discussion above, and we are happy to answer any questions you might have. Kind regards, Marc Ilunga (and Felix Günther) [1] The need for a notion strictly stronger than standard EUF-CMA security for signature schemes also arises in the basic SIGMA protocol with the MAC under the signature. One needs that signature scheme is not only unforgeable for a random key but for all keys. Otherwise, an attacker may carry an identity mis-binding attack. [Dow21] Dowling et al. "A Cryptographic Analysis of the TLS 1.3 Handshake Protocol", URL [Po05] Pornin and Stern, "Digital Signatures Do Not Guarantee Exclusive Ownership", URL [Bre20] Brendel et al. "The Provable Security of Ed25519: Theory and Practice", URL URL
Hi! When reading: I understood that a kid would map to multiple keys, but all of those keys would be owned by the same party. From what I understand, the attack described here only occurs when one kid maps to keys owned by distinct parties. Which is the correct interpretation? And should the second case actually be allowed? (I think the update proposed is no matter what a good idea though, it strictly improves things)
My interpretation of COSE is that one kid might map to keys owned by distinct parties. Seems hard to guarantee anything about kids unless there is a single authority that controls all the kids. as soon as there are several authorities there might be collisions. That all the keys with a certain kid belongs to a single party would require that a single authority determines all the kids or that some additional header parameter like kidcontext is used. I think the whole reason that kidcontext was introduced was to separate between different authorities determining kids. Maybe it would be good to clarify things in I-D.ietf-cose-rfc8152bis-struct
Thanks for this quick feedback!
I sent a mail to COSE suggesting that this should maybe be clarified URL
I am trying to precisely detail step by step the missbinding attack to understand how to improve our symbolic models and capture it, and I am not precisely able to. My first idea would require to be able to alter the signature under the xor, is this indeed the needed capability? Marc, could you give the details on how it would be carried out?
Below is my mail to LAKE on the topic
I am trying to precisely detail step by step the missbinding attack to understand how to improve our symbolic models and capture it, and I am not precisely able to. Seems hard to do something in practice as any change to CREDR changes the 32 byte pseudorandom value MAC2.
The MAC-then-Sign version of SIGMA-I is proven to be secure. If the above attack is possible in EDHOC it seems interesting to make a comparision between EDHOC SIG-SIG and SIGMA-I: Is there any protocol differences beween EDHOC SIG-SIG and SIGMA? Is there different assumptions on the cryptographic functions or in the definition of "secure"? Is the SIGMA-I proof wrong?
Hi all, Thanks for the feedback so far! I will try and answer the question raised above. First of all, I realised we wrote several things in the email but let me reiterate the main points: The identity mis-binding attack that we presented (and that I will flesh out below) only applies the basic MAC-Then-SIGn version of SIGMA as described in URL It served as a starting point to reason about the precise guarantees we need from the signature scheme. Fortunately: the actual instantiation in EHDOC seems to prevent the attack (thanks to including the credentials under the signature and not just the MAC. However, from a proof perspective, we are unable to properly show a reduction unless we assume even more about the signature schemes. The suggestion allows us to easily reduce the security to a weaker security notion that is likely provided by concrete use of the signatures in EDHOC. Indeed MAC-then-Sign is proven secure, but the attack concerns the particularity of having the MAC under the signature, which is not completely considered in the previous analysis. Quoting the above paper (URL): can compute even after seeing . However, in the context of an identity mis-binding attack, we are concerned about the possibility of computing . Where is adversarially chosen, which hints at Duplicate Signature Key Selection (DSKS)-like attacks. See: URL Based on the existing SIGMA analysis, the requirement for the signature scheme is unforgeability. Namely, the signature is unforgeable "on the average," i.e. for a random key. However, this does not exclude the possibility of "weak" keys, which are, for instance, a key pair such that verifies any message and signature pair, i.e. . This notion of a "weak" key is not really necessary since the signature is still unforgeable. If SIGMA is instantiated with such a pathological signature scheme, which is still unforgeable, then the attacker can carry an identity mis-binding that proceeds as follows: Alice -> Bob : Bob -> Eve(interception) : Eve : creates a special E -> A : A -> B : In the end, Alice thinks she talks to Eve, and Bob thinks he talks to Alice. Why doesn't this attack work on the "normal" SIGMA? With the MAC under the signature, peers do not have a notion of verifying a MAC and do so only implicitly via a successful signature verification. In the "normal" SIGMA, the MAC is explicitly verified; hence the attack above doesn't work even with a pathological signature scheme. Obviously, EDHOC doesn't quite use such a pathological scheme; however, this shows that this case has to be carefully analysed, hence the suggestion for the transcript hashes.
So does this identity misbinding attack mean that IKEv1 and IKEv2 does not provide authentication, aliveness, peer awareness, etc?
Hi NAME apologies for the delayed response, as I am coming towards the end of my thesis project I need to finalize my writing… Anyhow, regarding IKE protocols, this is a good question… Ultimately, this would depend on the concrete instantiation of the signature scheme. My fairly limited understanding of IKE is that the type of attack we describe above also apply. However, the adversary is likely to need to modify the communication transcript when injecting their certificate. This is where my limited knowledge of IKE limits what I can say about the actual impact. Perhaps, an attacker may abuse bit string representations to forge a certificate that seemingly does not modify the traffic on the wire? From a theoretical perspective, at least, it appears that we require some notion of exclusive ownership to prove security of the MAc-then-SIGn, this also depends on how it is instantiated. The EDHOC instantiation seems to do the right thing.
NAME Also apologies for providing the requested details, late. I wondered whether you had the chance to analyze this issue and what results you get from your formal modeling.
Our model did in fact already cover such weak keys for signatures, and in the case of EDHOC such attack is impossible, from what I understand mostly because the attacker cannot perform a MiTM as it cannot compute the encryption keys of the multiple messages. Only in message 2, which is not integrity protected, could the attacker hope to change the signature such that if it was able to go by xoring from the IDCREDR to an ID pointing to some weak key, the signature check would go through for some other identity. But then the hash transcript would change and the key exchange would never go further, as the initiator would then produce a message encrypted with a key that neither the attacker nor the reponder can compute.
Dear NAME , thanks for the feedback and the insights on how your formal model captured weak keys. I believe, however, that we are describing slightly different attacks. At a high level, the type of attack we consider does not really involve a PITM attack. In particular, the attack doesn't modify the transcript; hence nor do the transcript hash changes, or the key derived thereafter; at least as they are currently specified in draft 14. More precisely, from the assumption that IDCRED may hint at multiple credentials and associated public keys. The verification process would look something like the following pseudo-code(here for the initiator) If the adversary would register a specially weak key such that credentials[IDCREDR] and assuming that somehow gets precedence on the real this attack would work if the signature scheme would be vulnerable. Though we describe attacks on plaintext communication; this is cheating just shows that the attacker knows IDCREDR. I hope this clarifies things a bit. Marc
I did understand your attack, and I was trying to essentially lift the attack you are describing to one that does not require the multiple CREDR for one IDCREDR assumption. I was trying to do that, because under the multiple IDCRED assumption, the authentication property becomes weird. If we ask for authentication over the IDCRED and the attacker can register its own pk for an honnest IDCRED, this already breaks authentication. If we ask for authentication over the pks, then in your attack, the initiator is simply using an attacker key, for which we have no guarantees, and it is thus not breaking the authentication property.
Apologies, I misunderstood the previous message. But we had a similar observation if using unique ID_CRED. These attacks don't really work. In the end, we could rely on strong universal exclusive ownership of the signature to show explicit authentication. Although we also had to tweak the explicit authentication guarantees slightly, the reduction would need something stronger than S-UEO. To the best of our knowledge, it is not provided by the signature. Maybe except Ed25519 if it is implemented according to the way Libsodium does it. But adding the credentials to the transcript hashes strengthen the guarantees.
No worries, I was unclear. We seem to agree overall!
No disagreement and the PR is included in edhoc-16 Dear Mališa, dear all, Following our last email and in preparation for the IETF 114, we would like to offer a suggestion from our computational analysis of EDHOC. I will first state the suggestion and then give some motivation and justification. Suggestion: Include the authentication credentials in the transcript hash computation. Namely, we suggest modifying the transcript hashes TH3 and TH4 to include the credential of the peer that authenticate themselves. More precisely, we propose that protocol participants compute: Similarly, we propose that the computation of TH4 becomes The philosophy behind this proposal is to make explicit the identity of the peer that authenticated themselves, even if those identities are not sent. (One can think of this as expanding TH to include the actual identity credentials, which the sent IDCRED values hint to but do not uniquely determine). This is to simplify arguing agreement on the communication peer. Motivation and justification: We analysed EDHOC in the Multi-Stage Key exchange model, following the work [Dow21] of Dowling et al. We suggest the change above as an improvement towards ensuring explicit authentication, which we observed when analysing the following excerpt from the draft (draft-14, section 3.5.3): "As stated in Section 3.1 of [I-D.ietf-cose-rfc8152bis-struct], applications MUST NOT assume that 'kid' values are unique, and several keys associated with a 'kid' may need to be checked before the correct one is found. Applications might use additional information such as 'kid context' or lower layers to determine which key to try first. Applications should strive to make IDCREDx as unique as possible, since the recipient may otherwise have to try several keys." We modelled the above statement conservatively and considered that any IDCRED might reference multiple identities and associated credentials. A potential consequence of this modelling is that there may be ambiguity about the identity of the peer who authenticated themselves, which needs careful consideration. For instance, if IDCREDR refers to both CREDR and CREDR', the initiator that tries multiple public keys could conclude that it is talking to R'. If this occurs, the protocol would still come to completion since the transcript hash won't change. The standard unforgeability notion of signature schemes would not necessarily prevent such a scenario [1], and our analysis relies on strictly stronger notions. Concretely we require that signature schemes in EDHOC provide explicit ownership. In our model and proof, we had to rely on the relatively strong notion of "Malicious Universal Exclusive Ownership" to capture explicit authentication for EDHOC as currently specified. To the best of our knowledge, M-S-UEO was only studied and proven for Ed25519 as implemented in Libsodium[Bre20]. Therefore, relying on a weaker notion, "Universal Exclusive Ownership", is desirable. Adding the credentials in the transcript hash would prevent identity mis-binding attacks since divergence in the identity of the authenticated host would lead to diverging transcript hashes and, therefore, different derived keys. Furthermore, we can rely on weaker notions of explicit ownership from a proof standpoint. Fortunately, Ed25519 provides explicit ownership [Bre20], and [Po05] already showed that the inclusion of the credentials along with the message in the signing process, as is done already in EDHOC, provides explicit ownership and prevents ambiguity. For ECDSA, care must be taken in the implementation so that this construction guarantees exclusive ownership. Overall, we assume that CBOR encoding is unambiguous. We would very much appreciate your feedback and thoughts on the discussion above, and we are happy to answer any questions you might have. Kind regards, Marc Ilunga (and Felix Günther) [1] The need for a notion strictly stronger than standard EUF-CMA security for signature schemes also arises in the basic SIGMA protocol with the MAC under the signature. One needs that signature scheme is not only unforgeable for a random key but for all keys. Otherwise, an attacker may carry an identity mis-binding attack. [Dow21] Dowling et al. "A Cryptographic Analysis of the TLS 1.3 Handshake Protocol", URL [Po05] Pornin and Stern, "Digital Signatures Do Not Guarantee Exclusive Ownership", URL [Bre20] Brendel et al. "The Provable Security of Ed25519: Theory and Practice", URL
Changing the format has the advantage of allowing the one-pass signature verification and parsing, which reduces the compute (pasing) and memory usage. But it breaks already deployed certificates. With the current format we have the opposite pro and con. I personally prefer to add new types for the new format, to keep the old certificates still valid. BR/Lijun On Fri, Feb 2, 2024 at 2:51 PM Derek Atkins wrote: Lijun Liao

The Initiator SHALL compose message_3 as follows:  <ins> Compute the transcript hash TH_3 = H(TH_2, PLAINTEXT_2, CRED_R) where H() is the EDHOC hash algorithm of the selected cipher suite.  The transcript hash TH_3 is a CBOR encoded bstr and the input to the hash function is a CBOR Sequence.  Note that H(TH_2, PLAINTEXT_2) can be computed and cached already in the processing of message_2. </ins> Compute MAC_3 as in expand, with context_3 = << ID_CRED_I, TH_3, CRED_I, ? EAD_3 >> CIPHERTEXT_3 is the 'ciphertext' of COSE_Encrypt0.  <ins> Compute the transcript hash TH_4 = H(TH_3, PLAINTEXT_3, CRED_I) where H() is the EDHOC hash algorithm of the selected cipher suite.  The transcript hash TH_4 is a CBOR encoded bstr and the input to the hash function is a CBOR Sequence. </ins> Calculate PRK_out as defined in fig-edhoc-kdf.  The Initiator can now derive application keys using the EDHOC-Exporter interface, protocol SIGMA.  Using the terminology from SIGMA, EDHOC provides forward secrecy, mutual authentication with aliveness, consistency, and peer awareness.  As described in SIGMA, peer awareness is  <ins> provided to the Responder, but not to the Initiator.  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. </ins> As described in SIGMA, different levels of identity protection are provided to the Initiator and the Responder.  EDHOC provides identity


The pseudorandom key PRK_2e is derived with the following input: <del> The salt SHALL be a zero-length byte string.  Note that RFC5869 specifies that if the salt is not provided, it is set to a string of zeros (see Section 2.2 of RFC5869).  For implementation purposes, not providing the salt is the same as setting the salt to the zero-length byte string (0x). </del>  The IKM SHALL be the ephemeral-ephemeral ECDH shared secret G_XY (calculated from G_X and Y or G_Y and X) as defined in Example: Assuming the use of SHA-256 the extract phase of HKDF produces PRK_2e as follows: <del> where salt = 0x (zero-length byte string). </del> 4.1.1.2. The pseudorandom key PRK_3e2m is derived as follows:

Not sure this change is practically needed, but it is a simple change does not hurt. Actually simplifies the specification as the discussion on HKDF and empty string can be deleted.
No disagreement recorded - merging now.
The nonce used for the computation of PRK2e in the key schedule is set to be an empty. By replacing this empty string by the sid of the session, this makes the key PRK2e linked to the session connection identifiers and divides the chances for an attacker to correctly compute the key PRK_2e by the number of running sessions. More precisely, considering running sessions, computing Extract("",Z) with a random Z, the attacker may have a match with any of the sessions. While considering using a sid, computing Extract(sid, Z), the attacker may have a match only with the session using this sid.
This would increase the reduction bounds for PRK2e, but would it make a change if we consider the actual keystream? (and latter keys) As the transcript is included inside the derivation, the keystream2 does depend on all the information exchanged that could be used to build an sid. At a high level, the question is kind of the following I guess: is it better to do vs ? (I have no clue about the answer, but I would guess that if we rely on the PRF assumption, it is mostly the same?)
Making the following change would be relatively easy: But as charlie-j points out, TH2 is already included in all the Expand() derivations, so I am not sure that adding TH2 improves the practical security. For the inclusion of SID to make this "attack" harder the size of the curve would have to be smaller than the size of the hash function output. For the X25519-SHA-256 combination that is true but the size of X25519 is still 2^252. Brute forcing that would be much harder than brute forcing the typically 128 bit OSCORE key or breaking X25519 with Pollard's rho.
For comparison, below is how the TLS 1.3 key schedule looks like without PSK
This is not really true for the current: But would be true for
If we interpret in this quote as covering the PRKs, it is not true for any of them apart from PRKout, as similarly TH3 and TH4 are included only in K3 and K_4.
Good point. Let's see if we should reformulate "and all symmetric keys are derived using as much previous information as possible" is some way
The keys (and actually random material) that do follow this specification are the one form the key derivation figure: So an option would be to simply point at the figure?
Making a PR for this I noticed that this change has the benefit of allowing the text talking about HKDF and using the empty string as salt. Irrespectively of if the extra security factor is needed or not I therefore think this change should be done. There does not seem to be any negative affects of the change (except that it affects the test vectors).
PR is included in -16

The pseudorandom key PRK_2e is derived with the following input:  <ins> The salt SHALL be TH_2. </ins> The IKM SHALL be the ephemeral-ephemeral ECDH shared secret G_XY (calculated from G_X and Y or G_Y and X) as defined in Example: Assuming the use of SHA-256 the extract phase of HKDF produces PRK_2e as follows:  4.1.1.2. The pseudorandom key PRK_3e2m is derived as follows:


applies for encrypted data sent to an unauthenticated party.  In particular, it applies to EAD_1, ID_CRED_R, EAD_2, and error messages.  Using the same EAD_1 in several EDHOC sessions allows <del> passive eavesdroppers to correlate the different sessions.  Another consideration is that the list of supported cipher suites may potentially be used to identify the application.  The Initiator and the Responder must also make sure that unauthenticated data does not trigger any harmful actions.  In particular, this applies to EAD_1 and error messages. </del>  An attacker observing network traffic may use connection identifiers sent in clear in EDHOC or the subsequent application protocol to

The current text just says that: "The Initiator and the Responder must make sure that unprotected data and metadata do not reveal any sensitive information. This also applies for encrypted data sent to an unauthenticated party. In particular, it applies to EAD1, IDCREDR, EAD2, and error messages. " The eadvalue is expected to sometimes/often be encrypted outside of EDHOC. The text should be augmented with text that eadlabel leaks information even if ead_value is encrypted outside of EDHOC.

applies for encrypted data sent to an unauthenticated party.  In particular, it applies to EAD_1, ID_CRED_R, EAD_2, and error messages.  Using the same EAD_1 in several EDHOC sessions allows  <ins> passive eavesdroppers to correlate the different sessions.  Note that even if ead_value is encrypted outside of EDHOC, the ead_label in EAD_1 is revealed to passive attackers and the ead_label in EAD_2 is revealed to active attackers.  Another consideration is that the list of supported cipher suites may potentially be used to identify the application.  The Initiator and the Responder must also make sure that unauthenticated data does not trigger any harmful actions.  In particular, this applies to EAD_1 and error messages. </ins> An attacker observing network traffic may use connection identifiers sent in clear in EDHOC or the subsequent application protocol to


Transport of external authorization data. EDHOC is designed to encrypt and integrity protect as much <del> information as possible, and all symmetric keys are derived using as much previous information as possible.  EDHOC is furthermore designed to be as compact and lightweight as possible, in terms of message sizes, processing, and the ability to reuse already existing CBOR, COSE, and CoAP libraries.  Like (D)TLS, authentication is the responsibility of the application, EDHOC identifies (and optionally transports) authentication credentials, and provides proof-of- possession of the private authentication key. </del>  To simplify for implementors, the use of CBOR and COSE in EDHOC is summarized in CBORandCOSE.  Test vectors including CBOR diagnostic

Based on side comment in about "all symmetric keys are derived using as much previous information as possible"

Transport of external authorization data. EDHOC is designed to encrypt and integrity protect as much  <ins> information as possible.  Symmetric keys and random material derived using EDHOC-KDF are derived with as much previous information as possible, see fig-edhoc-kdf.  EDHOC is furthermore designed to be as compact and lightweight as possible, in terms of message sizes, processing, and the ability to reuse already existing CBOR, COSE, and CoAP libraries.  Like (D)TLS, authentication is the responsibility of the application, EDHOC identifies (and optionally transports) authentication credentials, and provides proof-of-possession of the private authentication key. </ins> To simplify for implementors, the use of CBOR and COSE in EDHOC is summarized in CBORandCOSE.  Test vectors including CBOR diagnostic


..., 23 is just copied directly into the message, a byte string which doesn't is encoded as a CBOR bstr during transport.  3.3.3. For OSCORE, the choice of connection identifier results in the

. First text based on initial draft by Christian.
On request. Some people have already implemented this and may want to comment on the Implementation Note in PR .
Merged

..., 23 is just copied directly into the message, a byte string which doesn't is encoded as a CBOR bstr during transport. <ins> 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 byte string or an integer depending on its value. </ins> 3.3.3. For OSCORE, the choice of connection identifier results in the


The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf is the output of a successful EDHOC exchange.  Keys for applications are <del> derived from PRK_out, see exporter.  An application using EDHOC- KeyUpdate needs to store PRK_out.  If EDHOC-KeyUpdate is not used, an application only needs to store PRK_out or PRK_exporter as long as EDHOC-Exporter is used.  (Note that the word "store" used here does not imply that the application has access to the plaintext PRK_out since that may be reserved for code within a TEE, see impl-cons). </del>  4.2. <del> This section defines EDHOC-Exporter and EDHOC-KeyUpdate in terms of EDHOC-KDF and PRK_out. </del>  4.2.1. PRK_exporter is derived from PRK_out: where hash_length denotes the output size in bytes of the EDHOC hash <del> algorithm of the selected cipher suite.  Note that PRK_exporter changes every time EDHOC-KeyUpdate is used, see keyupdate. </del>  The (exporter_label, context) pair used in EDHOC-Exporter must be unique, i.e., an (exporter_label, context) MUST NOT be used for two Examples of use of the EDHOC-Exporter are given in transfer. <del> 4.2.2. To provide forward secrecy in an even more efficient way than re- running EDHOC, EDHOC provides the optional function EDHOC-KeyUpdate. When EDHOC-KeyUpdate is called, a new PRK_out is calculated as a "hash" of the old PRK_out using the Expand function as illustrated by the following pseudocode.  The change of PRK_out causes a change to PRK_exporter and derived keys using EDHOC-Exporter. where hash_length denotes the output size in bytes of the EDHOC hash algorithm of the selected cipher suite. The EDHOC-KeyUpdate takes a context as input to enable binding of the updated PRK_out to some event that triggered the keyUpdate.  The Initiator and the Responder need to agree on the context, which can, e.g., be a counter or a pseudorandom number such as a hash.  To provide forward secrecy the old PRK_out and derived 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. I-D.ietf-core-oscore-key-update describes key update for OSCORE using EDHOC-KeyUpdate. While this key update method provides forward secrecy it does not give as strong security properties as re-running EDHOC, see security. </del> 5. This section specifies formatting of the messages and processing CWT, X.509, C509).  None of the credential types are mandatory-to- implement. <del> Implementations MUST support the EDHOC-Exporter.  Implementations SHOULD support EDHOC-KeyUpdate. </del>  Implementations MAY support message_4.  Error codes (ERR_CODE) 1 and 2 MUST be supported. As required by RFC7258, IETF protocols need to mitigate pervasive monitoring when possible.  EDHOC therefore only supports methods with <del> ephemeral Diffie-Hellman and provides a KeyUpdate function for lightweight application protocol rekeying with forward secrecy, in the sense that compromise of the private authentication keys does not </del>  compromise past session keys, and compromise of a session key does <del> not compromise past session keys. While the KeyUpdate method can be used to meet cryptographic limits and provide partial protection against key leakage, it provides significantly weaker security properties than re-running EDHOC with ephemeral Diffie-Hellman.  Even with frequent use of KeyUpdate, compromise of one session key compromises all future session keys, and an attacker therefore only needs to perform static key exfiltration RFC7624.  Frequently re-running EDHOC with ephemeral Diffie-Hellman forces attackers to perform dynamic key exfiltration instead of static key exfiltration RFC7624.  In the dynamic case, the attacker must have continuous interactions with the collaborator, which is more complicated and has a higher risk profile than the static case. </del>  To limit the effect of breaches, it is important to limit the use of symmetrical group keys for bootstrapping.  EDHOC therefore strives to shared secret) leads to compromise of all session keys derived from that compromised shared secret.  Compromise of one session key does not compromise other session keys.  Compromise of PRK_out leads to <del> compromise of all keying material derived with the EDHOC-Exporter since the last invocation (if any) of the EDHOC-KeyUpdate function. </del>  Based on the cryptographic algorithms requirements sec_algs, EDHOC provides a minimum of 64-bit security against online brute force

Replacing a session key with its hash for forward secrecy as specified with EDHOC-KeyUpdate, can alternatively be defined by the application as is done in KUDOS (draft-core-oscore-key-update). For this reason there is no need to recommend EDHOC-KeyUpdate as is done in Section 7. "Implementations SHOULD support EDHOC-KeyUpdate." EDHOC-KeyUpdate can useful in other applications but the description should be moved out of the body in the interest of focusing on the core functionality of EDHOC.
Discussed in the interim and PR merged.

The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf is the output of a successful EDHOC exchange.  Keys for applications are  <ins> derived from PRK_out, see exporter.  For the purpose of using EDHOC- Exporter, an application only needs to store PRK_out or PRK_exporter. (Note that the word "store" used here does not imply that the application has access to the plaintext PRK_out since that may be reserved for code within a TEE, see impl-cons). </ins> 4.2.  <ins> This section defines EDHOC-Exporter in terms of EDHOC-KDF and PRK_out. </ins> 4.2.1. PRK_exporter is derived from PRK_out: where hash_length denotes the output size in bytes of the EDHOC hash  <ins> algorithm of the selected cipher suite. </ins> The (exporter_label, context) pair used in EDHOC-Exporter must be unique, i.e., an (exporter_label, context) MUST NOT be used for two Examples of use of the EDHOC-Exporter are given in transfer.  5. This section specifies formatting of the messages and processing CWT, X.509, C509).  None of the credential types are mandatory-to- implement.  <ins> Implementations MUST support the EDHOC-Exporter. </ins> Implementations MAY support message_4.  Error codes (ERR_CODE) 1 and 2 MUST be supported. As required by RFC7258, IETF protocols need to mitigate pervasive monitoring when possible.  EDHOC therefore only supports methods with  <ins> ephemeral Diffie-Hellman.  This provides forward secrecy, in the sense that compromise of the private authentication keys does not </ins> compromise past session keys, and compromise of a session key does  <ins> not compromise past session keys.  Frequently re-running EDHOC forces attackers to perform dynamic key exfiltration where the attacker must have continuous interactions with the collaborator, which is a significant complication. </ins> To limit the effect of breaches, it is important to limit the use of symmetrical group keys for bootstrapping.  EDHOC therefore strives to shared secret) leads to compromise of all session keys derived from that compromised shared secret.  Compromise of one session key does not compromise other session keys.  Compromise of PRK_out leads to  <ins> compromise of all keying material derived with the EDHOC-Exporter. </ins> Based on the cryptographic algorithms requirements sec_algs, EDHOC provides a minimum of 64-bit security against online brute force


RFC8613) typically only breaks the security of the data in the forged packet.  After sending message_3, the Initiator is assured that no other party than the Responder can compute the key PRK_out.  While the Initiator can securely send protected application data, the Initiator SHOULD

NAME Do you or David have any comment on the formulation?
NAME We needed to merge this PR to prepare for -17, but we are of course still interested in your comments :-)
No comment to do ;). It's good.
This is the outcome of the work by Baptiste Cottier and David Pointcheval related to The conclusions form Baptiste and David is that after receiving message4 the Initiator has authenticated the Responder with a strength of the combined MACs in message2 and message4. I.e. if both MACs are 64 bits, they work together as a 128 bit MAC. The same thing apply to application messages such as OSCORE used as message 4,5,6,..... but this comes with the additional requirement that the security association has to be terminated and EDHOC redone in the case that verification of the OSCORE MAC fails. The same apply to the draft-ietf-core-oscore-edhoc where 2 MACs are sent in flight 3 URL The same priciple should apply to modes with signatures where a signature in message2 combined with a MAC in message_4 gives the strenght of the signature and the MAC combined. Baptiste and David have not investigated this formally.
Good. Terminology comment: You use first "authenticated with 128-bit security" and then "128-bit mutual authentication". I assume that means the same in security terms (although one is unilateral and the other mutual). No mentioning of online attacks here. Is it clear how that relates to "64-bit security against online brute force attacks" which is stated in another security consideration? "can be achieved after verification of the first OSCORE Response". This is correct in its brevity, but the use of "verification" gives the impression that it is the verification of OSCORE Response is what makes this achieved, rather than it is the completion of the processing of the OSCORE request and OSCORE response that are the moments in time when, with the appropriate measures, security can be achieved. Perhaps replace "verification" with "completion".

RFC8613) typically only breaks the security of the data in the forged packet. <ins> As the EDHOC protocol is terminated when verification fails, the security against online attacks is given by the sum of the strength of the verified signatures, MACs (including MAC in AEAD).  As an example, if EDHOC is used with method 3, cipher suite 2, and message_4, the Responder is authenticated with 128-bit security against online attacks (the sum of the 64-bit MACs in message_2 and message_4).  The same principle applies for MACs in an application protocol keyed by EDHOC as long as EDHOC is rerun when verification of the first MACs in the application protocol fail.  As an example, if EDHOC with method 3 and cipher suite 2 is used as in Figure 2 of I-D.ietf-core-oscore-edhoc, 128-bit mutual authentication against online attacks can be achieved after completion of the first OSCORE request and response. </ins> After sending message_3, the Initiator is assured that no other party than the Responder can compute the key PRK_out.  While the Initiator can securely send protected application data, the Initiator SHOULD