Markdown Version | Session Recording

Session Date/Time: 01 Mar 2023 15:00

CORE

Summary

The CORE Working Group meeting discussed the status and next steps for several key documents: draft-ietf-core-coset (COSE-T), draft-ietf-core-comi (CoMI), draft-ietf-core-target-attributes (CoRE Target Attribute), and draft-ietf-core-profiling-edhoc-oscore (Profiling EDHOC for CoAP and OSCORE). Significant progress was reported on all, with core-target-attributes moving towards submission to the IESG, and profiling-edhoc-oscore addressing a comprehensive set of Working Group Last Call comments. Key discussions focused on payload formats, error handling, web linking attributes, application profiles, and credential type registries, leading to several decisions and actions.

Key Discussion Points

COSE Configuration Documents (carconf)

draft-ietf-core-coset (COSE-T)

• Status: draft-ietf-core-yang-cbor (RFC 9254) has been published. draft-ietf-core-cose-c is in IESG review. draft-ietf-core-yang-library has passed Working Group Last Call (WGLC) but may need revisiting due to its broad ecosystem implications.
• Rob Wilton's DISCUSS: An outstanding DISCUSS comment from Rob Wilton has led to many discussions and edits. Authors submitted draft-ietf-core-coset-20 which is believed to address these concerns, but Rob's feedback is still awaited.
• Main Changes in -20:
  • Introduction of a per-SID fire status (unpublished/published).
  • Introduction of a per-item sid-item status (unstable/stable/obsolete, where obsolete is a deprecation mark).
  • Transitioned from Yang data to a structured Yang future, which currently lacks tool support for validation.
  • Fixed an incorrect Yang JSON representation for unsigned 64-bit integers.
• Discussion on Next Steps: The co-chair Marco suggested initiating a third WGLC for core-coset soon, in parallel with seeking Rob Wilton's feedback. This would ensure sufficient time for review ahead of the next IETF meeting.
• Validation Tooling (Amusement): Carson mentioned writing a sid.cdl tool and defining a CSV version of a SID file for easier validation, as existing tools for structured Yang future are lacking.

draft-ietf-core-comi (CoMI)

• Status: The working group will proceed assuming core-coset issues are under control.
• Implementation Experience: Simplifications based on implementation experience gained at a hackathon will be incorporated into the document.
• Shepherd/Author List: The current editor (Carson) will finish the document. This requires a new shepherd and modifications to the author list to comply with the five-person limit.

draft-ietf-core-target-attributes (CoRE Target Attribute)

• Status: Working Group Last Call (WGLC) has passed. draft-ietf-core-target-attributes-02 was submitted, addressing all WGLC comments.
• Changes in -02:
  • Added an Acknowledgments paragraph.
  • Referenced the core-parameters mailing list for discussions between registrants, the designated expert, and the wider community regarding the registry.
  • Removed Internet Draft-based registrations.
• Further Comments: Christian provided additional feedback, for which a pull request has been made.
• Discussion on Attribute Flags: Christian raised a point about attributes used in specific contexts (e.g., resource directory, where base, etd, ep are used). It was clarified that if an 'a' flag (indicating a specific property) were to be added to an existing attribute, it would be treated as a new registration requiring expert review. Conflicts with existing widely-used non-'a' flagged versions of the attribute would prevent the 'a' flag addition. Christian explained how conflicts are managed in the Resource Directory context.

draft-ietf-core-profiling-edhoc-oscore (Profiling EDHOC for CoAP and OSCORE)

• Status: Working Group Last Call comments from Christian and Jon Madison are being addressed. Editorial comments have been integrated into the editor's copy.
• Christian's Comment 1: Payload Format for EDHOC OSCORE Request
  • Current: CIBOR sequence of two CIBOR byte strings (EDHOC Message 3 and OSCORE ciphertext).
  • Proposed: EDHOC Message 3 as a CIBOR byte string, followed by the OSCORE ciphertext as raw bytes (not CIBOR-wrapped). This saves 2-3 bytes and has precedent (e.g., RFC 9277's "CIBOR header" concept).
  • Discussion: A sense of those present indicated support for the proposal.
• Christian's Comment 2: Server-side Error Handling
  • Current: Responds with an error if a decrypted OSCORE request includes the edhoc-oscore option without the edhoc-oscore option also being present.
  • Proposed: The language should be more future-proof, avoiding strict normative statements about what cannot happen. An alternative text suggests that if the edhoc-oscore option is present in a decrypted request, it must be regarded as an unprocessed critical option unless processed by a "further mechanism" (e.g., nested OSCORE).
• Christian's Comment 3: Web Linking - Missing Target Attributes
  • Current: Defines target attributes for EDHOC methods, cipher suites, etc.
  • Issue: Lacks attributes to indicate support for forward/reverse EDHOC message flows and initiator/responder roles.
  • Proposal: Define four new non-repeatable target attributes, without values (presence indicates support), for forward flow, reverse flow, initiator, and responder support.
  • Discussion: Christian questioned if the flow direction attributes (flow-forward, flow-reverse) imply the role attributes (initiator, responder), potentially making some redundant from a server's perspective. Carson suggested using flag bits for groups of related attributes to avoid an excessive number of individual attributes. Authors agreed to internally discuss redundancy and alternative representations.
• Christian's Comment 4: Application Profile Target Attribute
  • Idea: Introduce a target attribute to indicate support for a specific EDHOC application profile (e.g., my-edhoc-P1), assuming the EDHOC draft defines such profiles.
  • Discussion: Carson expressed strong reservations based on past IETF experience (e.g., HTTP, HTML profiles) where profiles often failed to gain traction because implementations couldn't guarantee knowledge of all possible profile values, necessitating fallback to more explicit signaling. While it could be an optimization to save a round trip, functionality should not hinge on profile understanding. The introduction of such an attribute is contingent on the EDHOC draft defining an application profile registry.
• Christian's Comment 5: Web Linking Example - /.well-known/edhoc
  • Current: Example uses custom EDHOC resources like /edhoc/sa and /edhoc/rs.
  • Proposed: Revert to using /.well-known/edhoc in examples. The original shift away was based on the idea that /.well-known/edhoc implies client knowledge, but this does not extend to knowledge of specific application profiles. Using /.well-known/edhoc provides a cleaner, well-defined path.
  • Discussion: A sense of those present supported reverting to /.well-known/edhoc.
• Christian's Comment 6: Well-known EDHOC Application Profile
  • Idea: Should a /.well-known/edhoc application profile be defined? Should it be a default profile?
  • Authors' View: Defining a specific /.well-known/edhoc application profile (in the EDHOC draft) and registering it could be beneficial, providing a known baseline. However, it should not be a default profile for /.well-known/edhoc as this could inadvertently create mandatory implementation requirements beyond the EDHOC specification itself.
  • Discussion: Christian suggested a default profile could state "obvious things" implied by CoAP use rather than imposing new mandatory features. Authors will discuss if a very minimal profile would provide sufficient guidance without being overly prescriptive, and whether such a profile would be defined in the EDHOC document.
• Jon Madison's Comment 1: Document Title
  • Current: "Profiling EDHOC for CoAP and OSCORE".
  • Proposed: "EDHOC with CoAP and OSCORE". The term "profiling" might be misleading as the document does not technically profile EDHOC.
  • Discussion: A sense of those present indicated support for the proposed title change.
• Jon Madison's Comment 2: Server-side Error Handling (OSCORE Protection)
  • Question: Can EDHOC error messages be protected with OSCORE?
  • Authors' Proposal: EDHOC error messages are always sent unprotected. The server must not establish a new OSCORE security context for sending such an error.
  • Discussion: Carson raised concerns about potential disclosure of sensitive information in unprotected error messages and suggested making them "frugal." Malisa suggested clarifying that unprotected errors should not give sensitive details. Christian raised a critical issue regarding ambiguity if error messages were protected: a client receiving a protected response would have difficulty distinguishing an EDHOC error message from a valid resource representation (e.g., in pub/sub where arbitrary content formats are allowed), leading to potential misinterpretation. The working group agreed that making error messages consistently unprotected simplifies error handling and avoids this ambiguity.
• Jon Madison's Comment 3: Retransmission of EDHOC+OSCORE Request
  • Question: What happens if an EDHOC+OSCORE request is retransmitted?
  • Authors' View: This document inherits from the EDHOC specification, which states that different instances of the same message must not be processed in one session. Relying on EDHOC's error handling (sections 5.3 and 6.2 of the EDHOC draft) should be sufficient.
  • Discussion: A sense of those present indicated agreement with relying on the EDHOC specification.
• Jon Madison's Comment 4: EAD Target Attributes
  • Issue: Clarification is needed that EDHOC External Authorization Data (EAD) target attributes (e.g., ed-ead1) use values from the EDHOC External Authorization Data registry.
  • Proposal: Clarify the text to state that these attributes use integers registered in that registry and add a concrete example illustrating this.
• Jon Madison's Comment 5: cred Target Attribute Registry
  • Idea: A cred target attribute indicates the supported credential type. Jon suggested creating a new IETF registry for EDHOC credential types (e.g., cwt, x509, rpk), possibly in this document or the EDHOC draft.
  • Authors' View: This is a good idea. For consistency, the registry should be created in the EDHOC draft, as other EDHOC-specific target attributes also derive their values from registries defined in EDHOC.
  • Discussion: Christian questioned the value of knowing the credential type without knowing the issuer, suggesting the issuer might be more relevant. Marco countered that knowing the type is still valuable, and issuer information could be orthogonal or conveyed via web linking. Carson suggested adding a private-use range for experimental credential types.
• Extra Point: Prefixing Target Attributes
  • Proposal: Prefix all EDHOC-specific target attributes with "ed-" (e.g., ed-method, ed-ead1) for clearer clustering.
  • Discussion: Re-evaluated the proposed flow/role attributes. A sense of those present indicated that ed-flow-forward and ed-flow-reverse might be redundant given the server's role. It was suggested to drop these and instead use ed-initiator and ed-responder (or ed-i/ed-r) if roles are to be indicated. The addition of an ed-prof attribute is contingent on decisions made in the EDHOC draft regarding application profiles.

Any Other Business (AOB)

• Christian mentioned he is reviewing draft-ietf-art-msync (Multicast Synchronization) for the ART WG, noting its relevance to multicast notifications, which may also be a topic in HTTP.

Decisions and Action Items

draft-ietf-core-coset (COSE-T)

• Decision: A third Working Group Last Call will be initiated soon for draft-ietf-core-coset, running in parallel with efforts to obtain feedback from Rob Wilton.
• Action: Marco (co-chair) will coordinate with Jari (Jaime) regarding the WGLC timing.
• Action: Authors will incorporate Rob Wilton's feedback and prepare the document for the WGLC.

draft-ietf-core-comi (CoMI)

• Action: Authors will incorporate simplifications based on implementation experience.
• Action: Marco and Francesca will manage the process of finding a new shepherd for the document and adjusting the author list to meet the five-person limit.

draft-ietf-core-target-attributes (CoRE Target Attribute)

• Action: Carson will incorporate Christian's latest changes into the document.
• Action: Generate draft-ietf-core-target-attributes-03.
• Decision: Submit draft-ietf-core-target-attributes-03 to the IESG. Marco confirmed he will be the shepherd for this document.

draft-ietf-core-profiling-edhoc-oscore (Profiling EDHOC for CoAP and OSCORE)

• Decision: Adopt the proposed payload format for EDHOC OSCORE requests (EDHOC Message 3 as CIBOR byte string, OSCORE ciphertext as raw bytes).
• Decision: Adopt the alternative text for server-side error handling as suggested by Christian (regarding edhoc-oscore option as an unprocessed critical option unless handled by a further mechanism).
• Decision: Change the document title to "EDHOC with CoAP and OSCORE".
• Decision: EDHOC error messages are always sent unprotected. Section 3.3 will be elaborated to clarify that the server must not establish a new OSCORE security context for sending error responses.
• Decision: Rely on the EDHOC specification for handling retransmission of EDHOC+OSCORE requests.
• Decision: Clarify in the text and add an example for EAD target attributes, indicating they use integers from the EDHOC External Authorization Data registry.
• Decision: Prefix all EDHOC-specific target attributes with "ed-". The specific names for role attributes (e.g., ed-initiator, ed-responder) will be finalized, dropping the ed-flow-* attributes.
• Action: Authors to internally discuss the redundancy of flow vs. role attributes and Carson's suggestion of using flag bits for grouped attributes.
• Action: Authors to further discuss with the EDHOC draft authors regarding the definition and registration of an application profile and a credential type registry in the EDHOC document. The decisions in profiling-edhoc-oscore for related attributes (ed-prof, cred) will follow those made in the EDHOC draft.
• Action: Authors to clarify that unprotected error messages should not contain sensitive details. Further discussion on generic encryption of error messages to be taken up by the EDHOC document authors.

Next Steps

• draft-ietf-core-coset: Initiate a third WGLC.
• draft-ietf-core-comi: Incorporate changes, new shepherd, modified author list.
• draft-ietf-core-target-attributes: Submit draft-ietf-core-target-attributes-03 to the IESG.
• draft-ietf-core-profiling-edhoc-oscore: Address remaining WGLC comments, submit version 7 before the upcoming cutoff. The pull request to core-target-attributes regarding renaming/addition of attributes is now largely irrelevant due to recent updates in core-target-attributes.