Ephemeral Diffie-Hellman Over COSE (EDHOC)
draft-ietf-lake-edhoc-23
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-03-20
|
(System) | 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 … 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) |
|
2024-03-15
|
23 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2024-03-13
|
23 | Mališa Vučinić | Changed document external resources from: None to: github_repo https://github.com/lake-wg/edhoc |
2024-03-01
|
23 | (System) | RFC Editor state changed to AUTH48 |
2024-01-29
|
23 | (System) | RFC Editor state changed to RFC-EDITOR from IESG |
2024-01-26
|
23 | Gunter Van de Velde | Request closed, assignment withdrawn: Shwetha Bhandari Last Call OPSDIR review |
2024-01-26
|
23 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue |
2024-01-22
|
23 | Göran Selander | New version available: draft-ietf-lake-edhoc-23.txt |
2024-01-22
|
23 | Göran Selander | New version accepted (logged-in submitter: Göran Selander) |
2024-01-22
|
23 | Göran Selander | Uploaded new revision |
2024-01-10
|
22 | (System) | RFC Editor state changed to IESG from RFC-EDITOR |
2023-12-12
|
22 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2023-11-20
|
22 | (System) | RFC Editor state changed to EDIT from IESG |
2023-10-27
|
22 | (System) | RFC Editor state changed to IESG from EDIT |
2023-10-25
|
22 | Mališa Vučinić | Added to session: IETF-118: lake Mon-1630 |
2023-09-05
|
22 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2023-09-05
|
22 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2023-09-04
|
22 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2023-08-29
|
22 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2023-08-28
|
22 | (System) | RFC Editor state changed to EDIT |
2023-08-28
|
22 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2023-08-28
|
22 | (System) | Announcement was received by RFC Editor |
2023-08-28
|
22 | (System) | IANA Action state changed to In Progress |
2023-08-28
|
22 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2023-08-28
|
22 | Cindy Morgan | IESG has approved the document |
2023-08-28
|
22 | Cindy Morgan | Closed "Approve" ballot |
2023-08-28
|
22 | Cindy Morgan | Ballot approval text was generated |
2023-08-28
|
22 | (System) | Removed all action holders (IESG state changed) |
2023-08-28
|
22 | Paul Wouters | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2023-08-25
|
22 | Göran Selander | New version available: draft-ietf-lake-edhoc-22.txt |
2023-08-25
|
22 | (System) | New version approved |
2023-08-25
|
22 | (System) | Request for posting confirmation emailed to previous authors: Francesca Palombini , Goeran Selander , John Mattsson |
2023-08-25
|
22 | Göran Selander | Uploaded new revision |
2023-08-25
|
21 | Lars Eggert | [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). … [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 |
2023-08-25
|
21 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss |
2023-08-24
|
21 | Roman Danyliw | [Ballot comment] Thank you to Radia Perlman for the SECDIR review. Thank you for addressing my DISCUSS and COMMENT feedback. |
2023-08-24
|
21 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2023-08-24
|
21 | (System) | Changed action holders to Paul Wouters (IESG state changed) |
2023-08-24
|
21 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2023-08-24
|
21 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2023-08-24
|
21 | Göran Selander | New version available: draft-ietf-lake-edhoc-21.txt |
2023-08-24
|
21 | (System) | New version approved |
2023-08-24
|
21 | (System) | Request for posting confirmation emailed to previous authors: Francesca Palombini , Goeran Selander , John Mattsson |
2023-08-24
|
21 | Göran Selander | Uploaded new revision |
2023-08-24
|
20 | (System) | Changed action holders to Paul Wouters, Göran Selander, John Preuß Mattsson, Francesca Palombini (IESG state changed) |
2023-08-24
|
20 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2023-08-24
|
20 | Andrew Alston | [Ballot Position Update] New position, No Objection, has been recorded for Andrew Alston |
2023-08-23
|
20 | Jim Guichard | [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard |
2023-08-23
|
20 | Lars Eggert | [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). … [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. |
2023-08-23
|
20 | Lars Eggert | Ballot discuss text updated for Lars Eggert |
2023-08-23
|
20 | Éric Vyncke | [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 … [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 |
2023-08-23
|
20 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2023-08-22
|
20 | Roman Danyliw | [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 … [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? |
2023-08-22
|
20 | Roman Danyliw | [Ballot comment] Thank you to Radia Perlman for the SECDIR review. ** Section 3.4. EDHOC is not bound to a particular transport layer and … [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? |
2023-08-22
|
20 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2023-08-22
|
20 | David Dong | IANA Experts State changed to Expert Reviews OK from Issues identified |
2023-08-22
|
20 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2023-08-22
|
20 | Warren Kumari | [Ballot comment] Other than supporting other ADs positions, I have nothing to add (it is far outside my areas of expertise). |
2023-08-22
|
20 | Warren Kumari | Ballot comment text updated for Warren Kumari |
2023-08-22
|
20 | Warren Kumari | [Ballot comment] Other than supporting other ADs positions, I have nothing to add. |
2023-08-22
|
20 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2023-08-22
|
20 | John Scudder | [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 … [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. |
2023-08-22
|
20 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2023-08-22
|
20 | David Dong | IANA Experts State changed to Issues identified from Reviews assigned |
2023-08-22
|
20 | David Dong | 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 … 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 |
2023-08-22
|
20 | Zaheduzzaman Sarker | [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 … [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. |
2023-08-22
|
20 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2023-08-22
|
20 | Lars Eggert | [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). … [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. |
2023-08-22
|
20 | Lars Eggert | [Ballot comment] ## Comments ### Section 3.4, paragraph 5 ``` * flow control, ``` But not congestion control? ### Section 10.2, paragraph 17 … [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 |
2023-08-22
|
20 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded for Lars Eggert |
2023-08-22
|
20 | Erik Kline | [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 … [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). |
2023-08-22
|
20 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2023-08-21
|
20 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2023-08-16
|
20 | Martin Duke | [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 … [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). |
2023-08-16
|
20 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2023-08-15
|
20 | David Dong | 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 … 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 |
2023-08-15
|
20 | David Dong | 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 … 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" |
2023-08-08
|
20 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Radia Perlman. Submission of review completed at an earlier date. |
2023-08-04
|
20 | David Dong | Expert has approved the Well-Known URIs registration. |
2023-08-04
|
20 | Cindy Morgan | Placed on agenda for telechat - 2023-08-24 |
2023-08-04
|
20 | Paul Wouters | Ballot has been issued |
2023-08-04
|
20 | Paul Wouters | [Ballot Position Update] New position, Yes, has been recorded for Paul Wouters |
2023-08-04
|
20 | Paul Wouters | Created "Approve" ballot |
2023-08-04
|
20 | Paul Wouters | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2023-08-04
|
20 | Paul Wouters | Ballot writeup was changed |
2023-08-04
|
20 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Radia Perlman. |
2023-08-04
|
20 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2023-08-03
|
20 | David Dong | IANA Experts State changed to Reviews assigned |
2023-08-03
|
20 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2023-08-03
|
20 | David Dong | (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 … (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 |
2023-07-18
|
20 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Shwetha Bhandari |
2023-07-13
|
20 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Radia Perlman |
2023-07-07
|
20 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2023-07-07
|
20 | Cindy Morgan | 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 … 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)) |
2023-07-07
|
20 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2023-07-07
|
20 | Cindy Morgan | Last call announcement was changed |
2023-07-07
|
20 | Paul Wouters | Last call was requested |
2023-07-07
|
20 | Paul Wouters | Ballot approval text was generated |
2023-07-07
|
20 | Paul Wouters | Ballot writeup was generated |
2023-07-07
|
20 | (System) | Changed action holders to Paul Wouters (IESG state changed) |
2023-07-07
|
20 | Paul Wouters | IESG state changed to Last Call Requested from Publication Requested::AD Followup |
2023-07-07
|
20 | Paul Wouters | Last call announcement was generated |
2023-07-07
|
20 | (System) | Removed all action holders (IESG state changed) |
2023-07-07
|
20 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2023-07-07
|
20 | Göran Selander | New version available: draft-ietf-lake-edhoc-20.txt |
2023-07-07
|
20 | (System) | New version approved |
2023-07-07
|
20 | (System) | Request for posting confirmation emailed to previous authors: Francesca Palombini , Goeran Selander , John Mattsson |
2023-07-07
|
20 | Göran Selander | Uploaded new revision |
2023-06-19
|
19 | Paul Wouters | Some changes are queued up in github, and pending if there will be changes on the C_Y encrypted or not consensus call. |
2023-06-19
|
19 | (System) | Changed action holders to Göran Selander, John Preuß Mattsson, Francesca Palombini (IESG state changed) |
2023-06-19
|
19 | Paul Wouters | IESG state changed to Publication Requested::Revised I-D Needed from Publication Requested |
2023-03-15
|
19 | Mališa Vučinić | Added to session: IETF-116: lake Thu-0030 |
2023-02-03
|
19 | Göran Selander | New version available: draft-ietf-lake-edhoc-19.txt |
2023-02-03
|
19 | (System) | New version approved |
2023-02-03
|
19 | (System) | Request for posting confirmation emailed to previous authors: Francesca Palombini , Goeran Selander , John Mattsson |
2023-02-03
|
19 | Göran Selander | Uploaded new revision |
2023-01-26
|
18 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Radia Perlman. Submission of review completed at an earlier date. |
2023-01-24
|
18 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Radia Perlman. |
2023-01-01
|
18 | Donald Eastlake | Request for Last Call review by INTDIR Completed: Ready with Issues. Reviewer: Donald Eastlake. |
2022-12-23
|
18 | Michael Scharf | Request for Last Call review by TSVART Completed: Ready with Nits. Reviewer: Michael Scharf. Sent review to list. |
2022-12-20
|
18 | Christer Holmberg | Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Christer Holmberg. Sent review to list. |
2022-12-19
|
18 | Magnus Westerlund | Assignment of request for Last Call review by TSVART to Bernard Aboba was marked no-response |
2022-12-19
|
18 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Michael Scharf |
2022-12-19
|
18 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Michael Scharf |
2022-12-11
|
18 | Carlos Jesús Bernardos | Request for Last Call review by INTDIR is assigned to Donald Eastlake |
2022-12-11
|
18 | Carlos Jesús Bernardos | Request for Last Call review by INTDIR is assigned to Donald Eastlake |
2022-12-10
|
18 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Radia Perlman |
2022-12-10
|
18 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Radia Perlman |
2022-12-08
|
18 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2022-12-08
|
18 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2022-12-08
|
18 | Mališa Vučinić | # 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 … # 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. |
2022-12-05
|
18 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Bernard Aboba |
2022-12-05
|
18 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Bernard Aboba |
2022-12-05
|
18 | Stephen Farrell | Requested Last Call review by TSVART |
2022-12-05
|
18 | Stephen Farrell | Requested Last Call review by IOTDIR |
2022-12-05
|
18 | Stephen Farrell | Requested Last Call review by INTDIR |
2022-12-05
|
18 | Stephen Farrell | Requested Last Call review by GENART |
2022-12-05
|
18 | Stephen Farrell | Requested Last Call review by SECDIR |
2022-12-05
|
18 | Stephen Farrell | Responsible AD changed to Paul Wouters |
2022-12-05
|
18 | Stephen Farrell | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2022-12-05
|
18 | Stephen Farrell | IESG state changed to Publication Requested from I-D Exists |
2022-12-05
|
18 | Stephen Farrell | Document is now in IESG state Publication Requested |
2022-12-05
|
18 | Stephen Farrell | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2022-12-05
|
18 | Stephen Farrell | Notification list changed to malisa.vucinic@inria.fr because the document shepherd was set |
2022-12-05
|
18 | Stephen Farrell | Document shepherd changed to Mališa Vučinić |
2022-12-05
|
18 | Stephen Farrell | Changed consensus to Yes from Unknown |
2022-12-05
|
18 | Stephen Farrell | Intended Status changed to Proposed Standard from None |
2022-11-28
|
18 | Göran Selander | New version available: draft-ietf-lake-edhoc-18.txt |
2022-11-28
|
18 | (System) | New version approved |
2022-11-28
|
18 | (System) | Request for posting confirmation emailed to previous authors: Francesca Palombini , Goeran Selander , John Mattsson |
2022-11-28
|
18 | Göran Selander | Uploaded new revision |
2022-10-26
|
17 | Mališa Vučinić | Added to session: IETF-115: lake Tue-1630 |
2022-10-14
|
17 | Mališa Vučinić | IETF WG state changed to In WG Last Call from WG Document |
2022-10-12
|
17 | Göran Selander | New version available: draft-ietf-lake-edhoc-17.txt |
2022-10-12
|
17 | Göran Selander | New version accepted (logged-in submitter: Göran Selander) |
2022-10-12
|
17 | Göran Selander | Uploaded new revision |
2022-09-30
|
16 | Göran Selander | New version available: draft-ietf-lake-edhoc-16.txt |
2022-09-30
|
16 | Göran Selander | New version accepted (logged-in submitter: Göran Selander) |
2022-09-30
|
16 | Göran Selander | Uploaded new revision |
2022-09-29
|
15 | Mališa Vučinić | Added to session: interim-2022-lake-02 |
2022-07-11
|
15 | Mališa Vučinić | Added to session: IETF-114: lake Wed-1330 |
2022-07-10
|
15 | Göran Selander | New version available: draft-ietf-lake-edhoc-15.txt |
2022-07-10
|
15 | (System) | New version approved |
2022-07-10
|
15 | (System) | Request for posting confirmation emailed to previous authors: Francesca Palombini , Goeran Selander , John Mattsson |
2022-07-10
|
15 | Göran Selander | Uploaded new revision |
2022-05-18
|
14 | Göran Selander | New version available: draft-ietf-lake-edhoc-14.txt |
2022-05-18
|
14 | (System) | New version approved |
2022-05-18
|
14 | (System) | Request for posting confirmation emailed to previous authors: Francesca Palombini , Goeran Selander , John Mattsson |
2022-05-18
|
14 | Göran Selander | Uploaded new revision |
2022-04-18
|
13 | Göran Selander | New version available: draft-ietf-lake-edhoc-13.txt |
2022-04-18
|
13 | (System) | New version approved |
2022-04-18
|
13 | (System) | Request for posting confirmation emailed to previous authors: Francesca Palombini , Goeran Selander , John Mattsson |
2022-04-18
|
13 | Göran Selander | Uploaded new revision |
2022-03-17
|
12 | Mališa Vučinić | Added to session: IETF-113: lake Mon-1430 |
2022-01-21
|
12 | Mališa Vučinić | Added to session: interim-2022-lake-01 |
2021-12-13
|
12 | Mališa Vučinić | Added to session: interim-2021-lake-05 |
2021-11-04
|
12 | Mališa Vučinić | Added to session: IETF-112: lake Fri-1430 |
2021-10-20
|
12 | Göran Selander | New version available: draft-ietf-lake-edhoc-12.txt |
2021-10-20
|
12 | (System) | New version approved |
2021-10-20
|
12 | (System) | Request for posting confirmation emailed to previous authors: Francesca Palombini , Goeran Selander , John Mattsson |
2021-10-20
|
12 | Göran Selander | Uploaded new revision |
2021-10-05
|
11 | Stephen Farrell | Added to session: interim-2021-lake-04 |
2021-09-24
|
11 | Göran Selander | New version available: draft-ietf-lake-edhoc-11.txt |
2021-09-24
|
11 | (System) | New version approved |
2021-09-24
|
11 | (System) | Request for posting confirmation emailed to previous authors: Francesca Palombini , Goeran Selander , John Mattsson |
2021-09-24
|
11 | Göran Selander | Uploaded new revision |
2021-09-04
|
10 | John Preuß Mattsson | New version available: draft-ietf-lake-edhoc-10.txt |
2021-09-04
|
10 | (System) | New version accepted (logged-in submitter: John Preuß Mattsson) |
2021-09-04
|
10 | John Preuß Mattsson | Uploaded new revision |
2021-08-23
|
09 | Göran Selander | New version available: draft-ietf-lake-edhoc-09.txt |
2021-08-23
|
09 | (System) | New version approved |
2021-08-23
|
09 | (System) | Request for posting confirmation emailed to previous authors: Francesca Palombini , Goeran Selander , John Mattsson |
2021-08-23
|
09 | Göran Selander | Uploaded new revision |
2021-07-24
|
08 | Mališa Vučinić | Added to session: IETF-111: lake Thu-1200 |
2021-07-12
|
08 | Göran Selander | New version available: draft-ietf-lake-edhoc-08.txt |
2021-07-12
|
08 | (System) | New version approved |
2021-07-12
|
08 | (System) | Request for posting confirmation emailed to previous authors: Francesca Palombini , Goeran Selander , John Mattsson |
2021-07-12
|
08 | Göran Selander | Uploaded new revision |
2021-05-24
|
07 | Göran Selander | New version available: draft-ietf-lake-edhoc-07.txt |
2021-05-24
|
07 | (System) | New version accepted (logged-in submitter: Göran Selander) |
2021-05-24
|
07 | Göran Selander | Uploaded new revision |
2021-04-21
|
06 | Göran Selander | New version available: draft-ietf-lake-edhoc-06.txt |
2021-04-21
|
06 | (System) | New version approved |
2021-04-21
|
06 | (System) | Request for posting confirmation emailed to previous authors: Francesca Palombini , Goeran Selander , John Mattsson |
2021-04-21
|
06 | Göran Selander | Uploaded new revision |
2021-04-15
|
05 | Mališa Vučinić | Added to session: interim-2021-lake-02 |
2021-03-05
|
05 | Mališa Vučinić | Added to session: IETF-110: lake Tue-1300 |
2021-02-22
|
05 | Göran Selander | New version available: draft-ietf-lake-edhoc-05.txt |
2021-02-22
|
05 | (System) | New version approved |
2021-02-22
|
05 | (System) | Request for posting confirmation emailed to previous authors: Francesca Palombini , Goeran Selander , John Mattsson |
2021-02-22
|
05 | Göran Selander | Uploaded new revision |
2021-01-27
|
04 | Göran Selander | New version available: draft-ietf-lake-edhoc-04.txt |
2021-01-27
|
04 | (System) | New version approved |
2021-01-27
|
04 | (System) | Request for posting confirmation emailed to previous authors: Francesca Palombini , Goeran Selander , John Mattsson |
2021-01-27
|
04 | Göran Selander | Uploaded new revision |
2021-01-25
|
03 | Mališa Vučinić | Added to session: interim-2021-lake-01 |
2020-12-18
|
03 | Göran Selander | New version available: draft-ietf-lake-edhoc-03.txt |
2020-12-18
|
03 | (System) | New version approved |
2020-12-18
|
03 | (System) | Request for posting confirmation emailed to previous authors: Francesca Palombini , Goeran Selander , John Mattsson |
2020-12-18
|
03 | Göran Selander | Uploaded new revision |
2020-12-15
|
02 | Mališa Vučinić | Added to session: interim-2020-lake-04 |
2020-11-10
|
02 | Mališa Vučinić | Added to session: IETF-109: lake Mon-1200 |
2020-11-02
|
02 | John Preuß Mattsson | New version available: draft-ietf-lake-edhoc-02.txt |
2020-11-02
|
02 | (System) | New version approved |
2020-11-02
|
02 | (System) | Request for posting confirmation emailed to previous authors: John Mattsson , Goeran Selander , Francesca Palombini |
2020-11-02
|
02 | John Preuß Mattsson | Uploaded new revision |
2020-08-02
|
01 | Göran Selander | New version available: draft-ietf-lake-edhoc-01.txt |
2020-08-02
|
01 | (System) | New version approved |
2020-08-02
|
01 | (System) | Request for posting confirmation emailed to previous authors: Francesca Palombini , John Mattsson , Goeran Selander |
2020-08-02
|
01 | Göran Selander | Uploaded new revision |
2020-07-17
|
00 | Mališa Vučinić | Added to session: IETF-108: lake Fri-1100 |
2020-07-08
|
00 | Mališa Vučinić | This document now replaces draft-selander-lake-edhoc instead of None |
2020-07-06
|
00 | Göran Selander | New version available: draft-ietf-lake-edhoc-00.txt |
2020-07-06
|
00 | (System) | WG -00 approved |
2020-07-06
|
00 | Göran Selander | Set submitter to "=?utf-8?q?G=C3=B6ran_Selander?= ", replaces to (none) and sent approval email to group chairs: lake-chairs@ietf.org |
2020-07-06
|
00 | Göran Selander | Uploaded new revision |