Ephemeral Diffie-Hellman Over COSE (EDHOC)
draft-ietf-lake-edhoc-23

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-lake-edhoc and RFC 9528, changed IESG state to RFC Published)

[Ballot comment]
# GEN AD review of draft-ietf-lake-edhoc-20

CC @larseggert

Thanks to Christer Holmberg for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/tvJRHUSdUtXJpishMcOd0KwR4O0).

## Comments

### Section 3.4, paragraph 5
```
    *  flow control,
```
But not congestion control?

### Section 10.2, paragraph 17
```
    | -20 to 23      | Standards Action with Expert Review |
```
Why still Expert Review if this already requires a Standards Action?
(Same comment for other registry ranges with this policy.)

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `master`; alternatives might be `active`, `central`, `initiator`,
  `leader`, `main`, `orchestrator`, `parent`, `primary`, `server`
* Term `man`; alternatives might be `individual`, `people`, `person`
* Term `dummy`; alternatives might be `placeholder`, `sample`, `stand-in`,
  `substitute`
* Term `native`; alternatives might be `built-in`, `fundamental`, `ingrained`,
  `intrinsic`, `original`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Document references `draft-selander-lake-authz-02`, but `-03` is the latest
available revision.

Document references `draft-ietf-core-oscore-key-update-04`, but `-05` is the
latest available revision.

Document references `draft-ietf-teep-architecture`, but that has been published
as `RFC9397`.

Document references `draft-ietf-cose-cbor-encoded-cert-05`, but `-06` is the
latest available revision.

Document references `draft-ietf-core-oscore-edhoc-07`, but `-08` is the latest
available revision.

### URLs

These URLs in the document did not return content:

* https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa-suite.cfm
* https://webee.technion.ac.il/~hugo/sigma-pdf.pdf

These URLs in the document can probably be converted to HTTPS:

* http://cbor.me/

### Grammar/style

#### Section 3.5.1, paragraph 2
```
n used by Initiator or Responder. Similarly for CRED_I, see Section 5.4.2. Th
                                  ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Similarly".

#### Section 4.1.1.3, paragraph 5
```
used for two different purposes. However an application can re-derive the s
                                  ^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "However".

#### Section 4.1.2, paragraph 1
```
al times as long as it is done in a secure way. For example, in most encrypt
                              ^^^^^^^^^^^^^^^
```
Consider replacing this phrase with the adverb "securely" to avoid wordiness.

#### Section 5.3.2, paragraph 17
```
s is similar to waiting for an acknowledgement (ACK) in a transport protocol.
                              ^^^^^^^^^^^^^^^
```
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

#### Section 6, paragraph 11
```
s 8 and 9, and prefers suite 8, so therefore selects suite 8 in the second m
                                ^^^^^^^^^^^^
```
Consider using "so" or "therefore".

#### Section 6.3.1, paragraph 3
```
multiple times due to missing acknowledgement on the CoAP messaging layer.
                              ^^^^^^^^^^^^^^^
```
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

#### Section 9.1, paragraph 6
```
e use of authenticated encryption. Hence the message authenticating function
                                  ^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Hence".

#### Section 9.5, paragraph 1
```
rves such as Ed25519 and Ed448 can mapped to and from short-Weierstrass form
                                  ^^^^^^
```
The modal verb "can" requires the verb's base form.

#### Section 9.8, paragraph 1
```
H_3, TH_4) does not make use of a so called running hash. This is a design c
                                  ^^^^^^^^^
```
The expression "so-called" is usually spelled with a hyphen.

#### Section 11.2, paragraph 11
```
sage flow" (see Appendix A.2.2). By default we assume the forward message flo
                                ^^^^^^^^^^
```
Did you mean: "By default,"?

#### "A.1.", paragraph 4
```
t representation trivially avoids so called "benign malleability" attacks whe
                                  ^^^^^^^^^
```
The expression "so-called" is usually spelled with a hyphen.

#### "A.1.", paragraph 6
```
yte 0x02 (i.e., M = 0x02 || X). * If a uncompressed y-coordinate is required,
                                    ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### "A.2.", paragraph 2
```
he major type. CBOR supports several different types of data items, in addit
                            ^^^^^^^^^^^^^^^^^
```
Consider using "several".

#### "A.2.", paragraph 7
```
CDDL C.2. CDDL Definitions This sections compiles the CDDL definitions for e
                                ^^^^^^^^
```
Consider using the singular form after the singular determiner "This".

#### "A.2.1.", paragraph 8
```
ing. What verifications are needed depend on the deployment, in particular th
                                  ^^^^^^
```
Did you mean "to depend"?

#### "D.3.", paragraph 1
```
cation message is successful, then the the Initiator transitions from COMPLET
                                  ^^^^^^^
```
Possible typo: you repeated a word.

#### "Appendix E.", paragraph 7
```
with example state machine o Acknowledgements o Language improvements by na
                              ^^^^^^^^^^^^^^^^
```
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot discuss]
# GEN AD review of draft-ietf-lake-edhoc-20

CC @larseggert

Thanks to Christer Holmberg for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/tvJRHUSdUtXJpishMcOd0KwR4O0).

## Discuss

### Section 3.4, paragraph 6
```
    *  denial-of-service protection,
```
No IETF transport protocol provides DDoS protection. If this is an
actual requirement, how will it be provided?

### Section 8, paragraph 3
```
    An implementation MAY support only a single method.  None of the
    methods are mandatory-to-implement.
```
How is interoperability guaranteed without at least a single
mandatory-to-implement method?

### Section 9.7, paragraph 1
```
    state, perform cryptographic operations, and amplify messages.  To
    mitigate such attacks, an implementation SHOULD rely on lower layer
    mechanisms.  For instance, when EDHOC is transferred as an exchange
    of CoAP messages, the CoAP server can use the Echo option defined in
    [RFC9175] which forces the CoAP client to demonstrate reachability at
    its apparent network address.  To avoid an additional roundtrip the
    Initiator can reduce the amplification factor by padding message_1,
    i.e., using EAD_1, see Section 3.8.1.
```
While the Echo option prevents some resource exhaustion aspects of
spoofing, it does not prevent DDoS by actual CoAP clients. Likewise,
while limiting amplification reduces the impact of a DDoS attack by
actual clients, it does not prevent it. It is hence incorrect to say
that these attacks are mitigated by COAP. (They also wouldn't be
mitigated by any other IETF transport protocol.)

### "A.2.", paragraph 1
```
    duplication.  CoAP can also perform fragmentation and protect against
    denial-of-service attacks.  The underlying CoAP transport should be
```
Per above, COAP does not protect against DDoS.

### "A.2.", paragraph 6
```
    To protect against denial-of-service attacks, the CoAP server MAY
    respond to the first POST request with a 4.01 (Unauthorized)
    containing an Echo option [RFC9175].  This forces the Initiator to
```
Per above, this mitigates some aspects of spoofing, but does not
protect against DDoS.

[Ballot comment]
Thank you for the work put into this document as it is outside of my technical expertise, I am trusting the SEC ADs for their reviews, I have detected nothing related to INT area while browsing the I-D.

Special thanks to Mališa Vučinić for the shepherd's detailed write-up including the WG consensus and some justification of the intended status.

Thanks also to Donald Eastlake for his last call int-dir review, I have seen that the authors had engaged with the reviewer.

Regards,

-éric

[Ballot discuss]
** Section 3.5.2
When the identified credential is a
  chain or a bag, the authentication credential CRED_x is just the end
  entity X.509 or C509 certificate / CWT.

Per Section 2 of RFC9360, the x5bag claim is:

"This header parameter contains a bag of X.509 certificates. The set of certificates in this header parameter is unordered and may contain self-signed certificates. Note that there could be duplicating certificates. The certificate bag can contain certificates which are completely extraneous to the message."

How does one pick-out the “end entity” if the list contains self-signed or extraneous certificates?

[Ballot comment]
Thank you to Radia Perlman for the SECDIR review.

** Section 3.4.
  EDHOC is not bound to a particular transport layer and can
  even be used in environments without IP.

Is there a minimum transport PDU for EDHOC? That is, if too small, EDHOC would fragment and eliminate all of the design benefits of limited round trips?

** Section 3.5.2
  It is RECOMMENDED that the COSE 'kid' parameter, when used to
  identify the authentication credential, refers to a specific
  encoding.

In what way does the “kid” claim convey a “specific encoding”?

** Section 7.  This section seems to be discussing how EDHOC implementations handle message duplication.  However, Section 3.4 says that “… the transport is responsible … to handle … message duplication”.  Is it a transport requirement or not to handle duplication?

** Section 9.4
  Symmetric algorithms used in EDHOC such as SHA-256 and AES-CCM-
  16-64-128 are practically secure against even large quantum
  computers.

Could “AES-CCM-16-16-128” being “practically secure” be better explained or cited.

** Section 9.6.
  Implementations and users SHOULD consider
  these threat models.

What does a normative “SHOULD” to “consider” a threat model mean?

** Section 9.7
EDHOC itself does not provide countermeasures against Denial-of-
  Service attacks. 
...
To
  mitigate such attacks, an implementation SHOULD rely on lower layer
  mechanisms.

What is the intent of this normative guidance?  If EDHOC doesn’t have DoS protection, what is the alternative relying on a lower level (stated as a SHOULD here)?  Is it an application mechanism?

** Section 9.8
  NIST
  generally forbids deriving secret and non-secret randomness from the
  same KDF instance,

Can the basis of this prohibition be cited?

** Section 9.8. 

  Implementations might consider deriving secret and non-secret
  randomness from different PRNG/PRF/KDF instances to limit the damage
  if the PRNG/PRF/KDF turns out to be fundamentally broken.
  ...

I’m confused on the position this entire paragraph is taking.  It’s framed as “might consider.” It then describes that there is conflicting advice from NIST and [HKDFpaper].  Either removing this text or state an explicit position.

** Section 9.8
  Verification of validity may require the use of a Real-Time Clock
  (RTC).  The private authentication keys MUST be kept secret, only the
  Responder SHALL have access to the Responder's private authentication
  key and only the Initiator SHALL have access to the Initiator's
  private authentication key.

Can the link between the two sentences in this paragraph be clarified?  How is the need for a clock connected to keeping the authentication keys secret?

[Ballot comment]
thank you to Mališa Vučinić for the illuminating and helpful shepherd writeup, and to the authors for the well-written document.

One nit (and it is the smallest of nits) is that the backslash ("\") character that occurs in Figure 17 seemed odd.

I had a short interaction with the authors, clarifying one thing I didn’t understand.

Fundamentally, the two registration requests in Section 10.6 are appropriate, each with an integer label to be assigned out of the Standards Action space (e.g., 13 and 14).

I have asked for a slight update of the registration request based on the following observations:

* The Value Type for the kccs parameter is listed as `map/#6(map)`. This appears to be an incomplete specification, waiting for a tag to be assigned for a CCS in draft-ietf-rats-uccs. Since EDHOC seems to be completing faster than that draft, and the alternative that includes the tag for CCS also is not strongly required, I propose to change the Value Type to just `map`.

* The supplementary information about both kccs and kcwt in the paragraph preceding the registry template is unlikely to be picked up by people consulting just the registry. I have requested making the “description” column more complete, in particular also pointing to RFC 8392 as the source of the “CWT” and “CCS” definitions.

* As an editorial observation, the description "A CBOR Web Token (CWT)/... containing a COSE_Key in a 'cnf’ claim” could be read as saying that only that one claim is to be contained in the token. Section 3.5.3.1 clarifies this by also saying "There may be any number of additional claims present in the CWT/CCS.”. Adding an “and possibly others” or similar to the description column might make this information more accessible to readers coming from the registry.

I have discussed the first two items with the authors, who agree with the suggestions, and expect them to be open to the third one as well.

Grüße, Carsten

[Ballot comment]
Thanks for working on this specification. Thanks to Michael Scharf his valuable TSVART review and nice to those addressed.

I would like to have responses on the following points as I believe clarity would help this specification -

  - It appeared to me that reliable transport is preferred while EDHOC messages are transmitted, however, this is not clearly mentioned. I think if this is the case then it should be clear in this specification. 

  - I also like section 3.4, however, it is not clear to me if the list provided, is a "must to meet" criteria for any transport or fulfilling any subset of features is good enough. If the later then this specification should describe how the missing criteria should be fulfilled or ignore or describe the impact.

For the similar reason, I am also supporting Lars's discuss on clarification required for DoS protection by the transport.

[Ballot discuss]
# GEN AD review of draft-ietf-lake-edhoc-20

CC @larseggert

Thanks to Christer Holmberg for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/tvJRHUSdUtXJpishMcOd0KwR4O0).

## Discuss

### Section 3.4, paragraph 6
```
    *  denial-of-service protection,
```
No IETF transport protocol provides DDoS protection. If this is an
actual requirement, how will it be provided?

### Section 8, paragraph 3
```
    An implementation MAY support only a single method.  None of the
    methods are mandatory-to-implement.
```
How is interoperability guaranteed without at least a single
mandatory-to-implement method?

### Section 9.7, paragraph 1
```
    state, perform cryptographic operations, and amplify messages.  To
    mitigate such attacks, an implementation SHOULD rely on lower layer
    mechanisms.  For instance, when EDHOC is transferred as an exchange
    of CoAP messages, the CoAP server can use the Echo option defined in
    [RFC9175] which forces the CoAP client to demonstrate reachability at
    its apparent network address.  To avoid an additional roundtrip the
    Initiator can reduce the amplification factor by padding message_1,
    i.e., using EAD_1, see Section 3.8.1.
```
While the Echo option prevents some resource exhaustion aspects of
spoofing, it does not prevent DDoS by actual CoAP clients. Likewise,
while limiting amplification reduces the impact of a DDoS attack by
actual clients, it does not prevent it. It is hence incorrect to say
that these attacks are mitigated by COAP. (They also wouldn't be
mitigated by any other IETF transport protocol.)

### "A.2.", paragraph 1
```
    duplication.  CoAP can also perform fragmentation and protect against
    denial-of-service attacks.  The underlying CoAP transport should be
```
Per above, COAP does not protect against DDoS.

### "A.2.", paragraph 6
```
    To protect against denial-of-service attacks, the CoAP server MAY
    respond to the first POST request with a 4.01 (Unauthorized)
    containing an Echo option [RFC9175].  This forces the Initiator to
```
Per above, this mitigates some aspects of spoofing, but does not
protect against DDoS.

### IANA

This document seems to have unresolved IANA issues. Holding a DISCUSS for IANA,
so we can determine next steps during the telechat.

[Ballot comment]

## Comments

### Section 3.4, paragraph 5
```
    *  flow control,
```
But not congestion control?

### Section 10.2, paragraph 17
```
    | -20 to 23      | Standards Action with Expert Review |
```
Why still Expert Review if this already requires a Standards Action?
(Same comment for other registry ranges with this policy.)

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `master`; alternatives might be `active`, `central`, `initiator`,
  `leader`, `main`, `orchestrator`, `parent`, `primary`, `server`
* Term `man`; alternatives might be `individual`, `people`, `person`
* Term `dummy`; alternatives might be `placeholder`, `sample`, `stand-in`,
  `substitute`
* Term `native`; alternatives might be `built-in`, `fundamental`, `ingrained`,
  `intrinsic`, `original`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Document references `draft-selander-lake-authz-02`, but `-03` is the latest
available revision.

Document references `draft-ietf-core-oscore-key-update-04`, but `-05` is the
latest available revision.

Document references `draft-ietf-teep-architecture`, but that has been published
as `RFC9397`.

Document references `draft-ietf-cose-cbor-encoded-cert-05`, but `-06` is the
latest available revision.

Document references `draft-ietf-core-oscore-edhoc-07`, but `-08` is the latest
available revision.

### URLs

These URLs in the document did not return content:

* https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa-suite.cfm
* https://webee.technion.ac.il/~hugo/sigma-pdf.pdf

These URLs in the document can probably be converted to HTTPS:

* http://cbor.me/

### Grammar/style

#### Section 3.5.1, paragraph 2
```
n used by Initiator or Responder. Similarly for CRED_I, see Section 5.4.2. Th
                                  ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Similarly".

#### Section 4.1.1.3, paragraph 5
```
used for two different purposes. However an application can re-derive the s
                                  ^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "However".

#### Section 4.1.2, paragraph 1
```
al times as long as it is done in a secure way. For example, in most encrypt
                              ^^^^^^^^^^^^^^^
```
Consider replacing this phrase with the adverb "securely" to avoid wordiness.

#### Section 5.3.2, paragraph 17
```
s is similar to waiting for an acknowledgement (ACK) in a transport protocol.
                              ^^^^^^^^^^^^^^^
```
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

#### Section 6, paragraph 11
```
s 8 and 9, and prefers suite 8, so therefore selects suite 8 in the second m
                                ^^^^^^^^^^^^
```
Consider using "so" or "therefore".

#### Section 6.3.1, paragraph 3
```
multiple times due to missing acknowledgement on the CoAP messaging layer.
                              ^^^^^^^^^^^^^^^
```
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

#### Section 9.1, paragraph 6
```
e use of authenticated encryption. Hence the message authenticating function
                                  ^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Hence".

#### Section 9.5, paragraph 1
```
rves such as Ed25519 and Ed448 can mapped to and from short-Weierstrass form
                                  ^^^^^^
```
The modal verb "can" requires the verb's base form.

#### Section 9.8, paragraph 1
```
H_3, TH_4) does not make use of a so called running hash. This is a design c
                                  ^^^^^^^^^
```
The expression "so-called" is usually spelled with a hyphen.

#### Section 11.2, paragraph 11
```
sage flow" (see Appendix A.2.2). By default we assume the forward message flo
                                ^^^^^^^^^^
```
Did you mean: "By default,"?

#### "A.1.", paragraph 4
```
t representation trivially avoids so called "benign malleability" attacks whe
                                  ^^^^^^^^^
```
The expression "so-called" is usually spelled with a hyphen.

#### "A.1.", paragraph 6
```
yte 0x02 (i.e., M = 0x02 || X). * If a uncompressed y-coordinate is required,
                                    ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### "A.2.", paragraph 2
```
he major type. CBOR supports several different types of data items, in addit
                            ^^^^^^^^^^^^^^^^^
```
Consider using "several".

#### "A.2.", paragraph 7
```
CDDL C.2. CDDL Definitions This sections compiles the CDDL definitions for e
                                ^^^^^^^^
```
Consider using the singular form after the singular determiner "This".

#### "A.2.1.", paragraph 8
```
ing. What verifications are needed depend on the deployment, in particular th
                                  ^^^^^^
```
Did you mean "to depend"?

#### "D.3.", paragraph 1
```
cation message is successful, then the the Initiator transitions from COMPLET
                                  ^^^^^^^
```
Possible typo: you repeated a word.

#### "Appendix E.", paragraph 7
```
with example state machine o Acknowledgements o Language improvements by na
                              ^^^^^^^^^^^^^^^^
```
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
# Internet AD comments for draft-ietf-lake-edhoc-20
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S6.2

* I'm not sure about "MUST be ... written in English".  Does it not suffice
  to say "MUST be a human-readable string" and "SHOULD be English", since the
  exact written language is not protocol-critical?

### Appendix B

* Do any of the Certicom patents as notified to SECG:

      https://www.secg.org/certicom_patent_letter_SECG.pdf

  apply the text in this section?  If so, has the working group been made
  aware and collectively agreed to proceed?

  I just found this linked off the https://www.secg.org/ site and it seemed
  to mention "point compression", but I'm not really qualified to make any
  reasonable assessment about whether readers of this I-D should be made
  aware of this stuff or not.

## Nits

### S3.3.2

* Figure 5 could make it more clear that the CBOR encoding values are
  in hex (right?)

### S3.9

* "because of wrong credential"

  Either "because of wrong credentials" or maybe "because of a wrong
  credential" might read better.

### S5.2.2, S5.3.2, S5.4.2, S5.5.2

* I found the use of "Processing" in the section heading to somewhat
  misleading.  I don't think of the sender as "processing" a message that
  it's going to send.  Perhaps, "Preparation" or "Composition" might be more
  natural?

### Appendix D.5

* You might be asked by the Editor about alternative language for
  "man-in-the-middle" (e.g., "on-path attacker" or something).

[Ballot comment]
Thanks to Michael Scharf for the TSVART review.

I appreciate the clear statement of transport requirements in S3.4.

You state that deduplication is a requirement of the transport, but then in S7 you state that some transports don't actually meet the requirement, and what to do in that case. So it really isn't a requirement, is it? Just a nice to have! It would be good to state that in 3.4.

Is it really necessary for the transport to handle reordering? IIUC this protocol consists of up to 4 atomic messages that fit in a datagram, and each one is input to the next. How could there be reordered messages in this context? (Similarly, I fail to see how a transport could support ordering but not deduplication -- perhaps I'm not imaginative enough).

Expert has approved the Well-Known URIs registration. Comments from the expert regarding the CoAP Content-Formats registration: Ok, that seems fine. I propose to allocate two neighbouring numbers in the range 64-95. (e.g. 64 and 65). Some feedback to the authors: Appendix A does not require the Content-Format option to be used in requests or responses, they are only mentioned in “examples” in the figures. Also RFC 7252 does not require the Content-Format Option for a POST request or response with payload. Therefore, some implementers may opt to leave out the Content-Format option from the message to save space.  If the other implementation is not prepared for this,  and e.g. sends back a CoAP error, then interoperability is not achieved. So this is something to keep in mind when testing.  Or it could be clarified in the draft what to require/allow the implementations to do here if you want it to be more strict. (E.g. tighten the RFC 7252 requirements in order to reduce test cases when interop testing.) Esko

Expert has approved the Well-Known URIs registration. Comments from the expert regarding the CoAP Content-Formats registration: "The proposed registration looks good. From Appendix A and figure 18 and 19 I infer that the Content-Format will be used in CoAP message exchanges, for establishing or renewing a security context. If that happens not frequently then IDs from the range 256-9999 seems fine. If the authors think size is of utmost importance for particular reasons, or if this exchange is expected to happen frequently, then we can allocate from the range 0-255. In the latter case the authors could comment on this email thread maybe? Thanks Esko"

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-lake-edhoc-20. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about the tenth action requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are eleven actions which we must complete.

First, a new registry group titled Ephemeral Diffie-Hellman Over COSE (EDHOC) is to be created at:

https://www.iana.org/protocols

Second, a new registry is to be created called the EDHOC Exporter Label registry. The registry is to be located in the Ephemeral Diffie-Hellman Over COSE (EDHOC) registry group created above. The reference for the new registry is [ RFC-to-be ]. The values in the new registry range from 0 to 32767.

The registration procedures (RFC 8126) for the new registry are:

Range Registration Procedures
------------+-----------------
0 to 23 Standards Action
24 to 32767 Expert Review

There are initial registrations in the new registry as follows:

Label Description Reference
-----------+--------------------------------+--------------
0 Derived OSCORE Master Secret [ RFC-to-be ]
1 Derived OSCORE Master Salt [ RFC-to-be ]
2-22 Unassigned
23 Reserved [ RFC-to-be ]
24-32767 Unassigned
32768-65535 Private Use

Third, a new registry is to be created called the EDHOC Cipher Suites registry. The registry is to be located in the Ephemeral Diffie-Hellman Over COSE (EDHOC) registry group created above. The reference for the new registry is [ RFC-to-be ]. The columns of the registry are Value, Array and Description, where Value is an integer and the other columns are text strings.

The registration procedures (RFC 8126) for the new registry are:

Range Registration Procedures
-----------------+-----------------------------------
-65536 to -25 Specification Required
-20 to 23 Standards Action with Expert Review
24 to 65535 Specification Required

There are initial registrations in the new registry as follows:

Value: -24
Array: N/A
Description: Private Use
Reference: [ RFC-to-be ]

Value: -23
Array: N/A
Description: Private Use
Reference: [ RFC-to-be ]

Value: -22
Array: N/A
Description: Private Use
Reference: [ RFC-to-be ]

Value: -21
Array: N/A
Description: Private Use
Reference: [ RFC-to-be ]

Value: 0
Array: 10, -16, 8, 4, -8, 10, -16
Description: AES-CCM-16-64-128, SHA-256, 8, X25519, EdDSA, AES-CCM-16-64-128, SHA-256
Reference: [ RFC-to-be ]

Value: 1
Array: 30, -16, 16, 4, -8, 10, -16
Description: AES-CCM-16-128-128, SHA-256, 16, X25519, EdDSA, AES-CCM-16-64-128, SHA-256
Reference: [ RFC-to-be ]

Value: 2
Array: 10, -16, 8, 1, -7, 10, -16
Description: AES-CCM-16-64-128, SHA-256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-256
Reference: [ RFC-to-be ]

Value: 3
Array: 30, -16, 16, 1, -7, 10, -16
Description: AES-CCM-16-128-128, SHA-256, 16, P-256, ES256, AES-CCM-16-64-128, SHA-256
Reference: [ RFC-to-be ]

Value: 4
Array: 24, -16, 16, 4, -8, 24, -16
Description: ChaCha20/Poly1305, SHA-256, 16, X25519, EdDSA, ChaCha20/Poly1305, SHA-256
Reference: [ RFC-to-be ]

Value: 5
Array: 24, -16, 16, 1, -7, 24, -16
Description: ChaCha20/Poly1305, SHA-256, 16, P-256, ES256, ChaCha20/Poly1305, SHA-256
Reference: [ RFC-to-be ]

Value: 6
Array: 1, -16, 16, 4, -7, 1, -16
Description: A128GCM, SHA-256, 16, X25519, ES256, A128GCM, SHA-256
Reference: [ RFC-to-be ]

Value: 23
Reserved
Reference: [ RFC-to-be ]

Value: 24
Array: 3, -43, 16, 2, -35, 3, -43
Description: A256GCM, SHA-384, 16, P-384, ES384, A256GCM, SHA-384
Reference: [ RFC-to-be ]

Value: 25
Array: 24, -45, 16, 5, -8, 24, -45
Description: ChaCha20/Poly1305, SHAKE256, 16, X448, EdDSA, ChaCha20/Poly1305, SHAKE256
Reference: [ RFC-to-be ]

Fourth, a new registry is to be created called the EDHOC Method Type registry. The registry is to be located in the Ephemeral Diffie-Hellman Over COSE (EDHOC) registry group created above. The reference for the new registry is [ RFC-to-be ]. The columns of the registry are Value, Initiator Authentication Key, and Responder Authentication Key, and Reference, where Value is an integer and the key columns are text strings describing the authentication keys.

The registration procedures (RFC 8126) for the new registry are:

Range Registration Procedures
-----------------+-----------------------------------
-65536 to -25 Specification Required
-24 to 23 Standards Action with Expert Review
24 to 65535 Specification Required

There are initial registrations in the new registry as follows:

Method Type Initiator Responder
Value Authentication Key Authentication Key Reference
------------+-----------------------+--------------------------+-------------
0 Signature Key Signature Key [ RFC-to-be ]
1 Signature Key Static DH Key [ RFC-to-be ]
2 Static DH Key Signature Key [ RFC-to-be ]
3 Static DH Key Static DH Key [ RFC-to-be ]
23 Reserved [ RFC-to-be ]

Fifth, a new registry is to be created called the EDHOC Error Codes registry. The registry is to be located in the Ephemeral Diffie-Hellman Over COSE (EDHOC) registry group created above. The reference for the new registry is [ RFC-to-be ]. The columns of the registry are ERR_CODE, ERR_INFO Type, Description, and Reference, where ERR_CODE is an integer, ERR_INFO is a CDDL defined type, and Description is a text string.

The registration procedures (RFC 8126) for the new registry are:

Range Registration Procedures
-----------------+-----------------------------------
-65536 to -25 Specification Required
-24 to 23 Standards Action with Expert Review
24 to 65535 Specification Required

There are initial registrations in the new registry as follows:

ERR_CODE ERR_INFO Type Description Reference
--------+-------------+-----------------------------+-------------
0 Reserved [ RFC-to-be ]
1 tstr Unspecified error [ RFC-to-be ]
2 suites Wrong selected cipher suite [ RFC-to-be ]
3 true Unknown credential referenced [ RFC-to-be ]
23 Reserved [ RFC-to-be ]

Sixth, a new registry is to be created called the EDHOC External Authorization Data registry. The registry is to be located in the Ephemeral Diffie-Hellman Over COSE (EDHOC) registry group created above. The reference for the new registry is [ RFC-to-be ]. The columns of the registry are Name, Label, Description, and Reference, where Label is a non-negative integer and the other columns are text strings.

The registration procedures (RFC 8126) for the new registry are:

Range Registration Procedures
------------+-----------------
0 to 23 Standards Action with Expert Review
24 to 65535 Specification Required

There are two initial registrations in the new registry as follows:

Name: Padding
Label: 0
Description: Randomly generated CBOR byte string
Reference: [ RFC-to-be; Section 3.8.1 ]

Name:
Label: 23
Description: Reserved
Reference: [ RFC-to-be; Section 10.5 ]

Seventh, in the COSE Header Parameters registry on the CBOR Object Signing and Encryption (COSE) registry group located at:

https://www.iana.org/assignments/cose/

two new registrations are to be made as follows:

Name: kcwt
Label: [ TBD-at-Registration ]
Value Type: COSE_Messages
Value Registry:
Description: A CBOR Web Token (CWT) containing a COSE_Key in a 'cnf' claim
Reference: [ RFC-to-be ]

Name: kccs
Label: [ TBD-at-Registration ]
Value Type: map / #6(map)
Value Registry:
Description: A CWT claims Set (CCS) containing a COSE_Key in a 'cnf' claim
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Eighth, in the Well-Known URIs registry located at:

https://www.iana.org/assignments/well-known-uris/

a single new URI is to be registered as follows:

URI Suffix: edhoc
Change Controller: IETF
Reference: [ RFC-to-be ]
Status: permanent
Related Information:
Date Registered: [ TBD-at-Registration ]
Date Modified:

As this also requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Ninth, in the application namespace of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

two new registrations are to be made as follows:

Name: edhoc+cbor-seq
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Name: cid-edhoc+cbor-seq
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Tenth, in the CoAP Content-Formats registry in the Constrained RESTful Environments (CoRE) Parameters registry group located at:

https://www.iana.org/assignments/core-parameters/

two new registrations are to be made as follows:

Content Type: application/edhoc+cbor-seq
Content Coding:
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Content Type: application/cid-edhoc+cbor-seq
Content Coding:
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]


IANA QUESTION --> What range in the CoAP Content-Formats registry should these two registrations use?


Eleventh, in the Resource Type (rt=) Link Target Attribute Values registry also in the Constrained RESTful Environments (CoRE) Parameters registry group located at:

https://www.iana.org/assignments/core-parameters/

a single new registration will be made as follows:

Value: core.edhoc
Description: EDHOC resource
Reference: [[this document]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2023-08-04):

From: The IESG
To: IETF-Announce
CC: draft-ietf-lake-edhoc@ietf.org, lake-chairs@ietf.org, lake@ietf.org, malisa.vucinic@inria.fr, paul.wouters@aiven.io
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Ephemeral Diffie-Hellman Over COSE (EDHOC)) to Proposed Standard


The IESG has received a request from the Lightweight Authenticated Key
Exchange WG (lake) to consider the following document: - 'Ephemeral
Diffie-Hellman Over COSE (EDHOC)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-08-04. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a
  very compact and lightweight authenticated Diffie-Hellman key
  exchange with ephemeral keys.  EDHOC provides mutual authentication,
  forward secrecy, and identity protection.  EDHOC is intended for
  usage in constrained scenarios and a main use case is to establish an
  OSCORE security context.  By reusing COSE for cryptography, CBOR for
  encoding, and CoAP for transport, the additional code size can be
  kept very low.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc9053: CBOR Object Signing and Encryption (COSE): Initial Algorithms (Informational - Internet Engineering Task Force (IETF))

# Document Shepherd Write-Up for draft-ietf-lake-edhoc

Template version: 4 July 2022

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

There is a strong consensus in the working group on publishing this document.
During the WGLC, there were 7 reviews received, both from the formal analysis
academic community and the implementers. After resolving these comments, there
were no objections on pushing the document forward to the IESG.

2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

One point that received particular attention was the decision on the mandatory-
to-implement cipher suite. Section 7 details the consensus text.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as RFC 7942 recommends) or elsewhere
(where)?

To this date, there are at least 7 independent implementations of the protocol
at its different versions. These were tested during 6 interoperability testing
events organized either online or in collocation with the IETF Hackathon. The
page gathering relevant information around the protocol is available at:
lakewg.org

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

EDHOC is a key exchange protocol over COSE. Participants of the COSE working
group were involved in the standardization of this document. Further, during
the working group stage of the document, it was decided to invite the academic
community using formal methods to study the contents of the specification. From
November 2021 to May 2022, the working group 'froze' the document to give enough
time to the academic teams to review. Overall, four independent teams have
studied the protocol's security properties and the work on a formally verified
implementation is ongoing. No major security vulnerabilities were discovered and
the process has resulted in improvements to the protocol.

6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not applicable.

7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?

Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

CDDL in the previous version of the document has been manually reviewed by
Carsten Bormann, a co-author of RFC 8610 (CDDL). The shepherd has asked a
re-review on the latest version.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

The document has undergone a thorough review by the academic community working
on formal methods.

11. What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

The draft should be published as "Proposed Standard". The draft is a major
dependency for many documents in other IoT-related working groups, such as ACE
and CoRE. The Datatracker intended RFC status is set to "Proposed Standard".


12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

Yes, the authors have confirmed publicly that they are not aware of any IPR
that relates to this draft.

13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes, each author has confirmed their willingness to be listed as author.

14. Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

I-D nits check generated warnings for lines that appear to be too long, but
this was caused by non-ascii characters. Lines with non-ascii characters also
generated a warning. There is also an outdated reference to
draft-ietf-rats-eat-17, which generated a warning.


15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

There was a discussion in the group whether I-D.ietf-cose-cbor-encoded-cert
should be included as a normative reference.

16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

There are no such normative references.

17. Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.

RFC 7624, RFC 8376, RFC 9053 are not listed in the DOWNREF registry.

RFC 7624 and RFC 8376 can be informative and following shepherd's review an
issue was raised to update the document changing these references to informative.
RFC 9053, which defines a set of algorithms, should likely be included in the
DOWNREF registry.

18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

The only normative reference which has the I-D status (draft-ietf-cose-x509) is
submitted to IESG for publication. All other normative references have been
published as RFCs.

19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

No.


20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).

Following shepherd's review of the IANA considerations section, the description
of one registry has been updated. I confirm all aspects mentioned above.

21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

EDHOC Exporter Label Registry
EDHOC Cipher Suites Registry
EDHOC Error Codes Registry

Yes, there is a dedicated section (Section 9.11) with clear instructions to the
Designated Expert.