Session Date/Time: 08 Nov 2021 16:00

core

Summary

The core working group meeting at IETF 112 covered updates on several in-progress drafts, including CRI (Concise Representation of URIs), CoRAL (CBOR-based Resource Abstraction Language), CoAP Group Communication, Group OSCORE, and Key Update for OSCORE (Kudos). A new draft on a CoAP option for performance measurement was also introduced. Key discussions centered on URI data model representation, application group naming, enhanced security advice for group communication, mandatory-to-implement algorithms for Group OSCORE, and a new rekeying mechanism for OSCORE. The working group also formally adopted the "Key Update for OSCORE" (Kudos) draft.

Key Discussion Points

Working Group Status:
- RFC 9100 (CoAP Sentinel Versions) was published.
- Two documents were approved for publication as Proposed Standard and are in the RFC Editor Queue.
- Two CoAP-CoNf documents are in ISG processing, with positive reviews.
- Group OSCORE had its first working group last call (WGLC) comments addressed, approaching a second WGLC.
- Chairs plan to update working group milestones. An informal meeting/interim for CoAP applications was discussed.
- Rumors about the working group concluding were dispelled by the chairs.
CRI (Concise Representation of URIs):
- Aims to standardize a CBOR-based, concise URI format addressing common URI implementation errors.
- Current version (08) defines CRI and CRI references, is CBOR-based, and is considered feature-complete for RFC 3986 subset supported by CoAP. Includes parsing for URNs and hostnames.
- Open Issues:
  - Prefix Compression: Difficulty supporting prefix compression (e.g., JSON-LD @context) for partial paths due to CBOR-packed limitations. This represents a functional deficiency.
  - Percent Encoding: CoAP's restrictive stance on percent encoding prevents full support for structures like W3C DIDs. A proposed solution involves alternating unencoded and percent-encoded parts within an array, though this introduces complexity.
- A preference was expressed for a solution within CRI over falling back to URIs, to calm the "wilderness" of URI usage.
CoRAL (CBOR-based Resource Abstraction Language):
- A data model and language for describing resource metadata and interactions, optimized for constrained devices.
- Provides semantic information via predicates, similar to RDF but more compact and constraint-device friendly (e.g., option numbers for URI predicates).
- Users include Problem Details, PubSub, ACE group management, and potentially SDF.
- Key Updates: Information model (RDF-ish basic model + tree structure for processing), dictionary definition (leveraging packed CBOR tags, pre-populated dictionaries via media types, or named dictionaries). Text serialization has been removed in favor of EDN and Turtle examples.
- Queries and reification are deferred to later phases.
- Next steps include coordinating with target applications to gather a corpus for binary serialization evaluation and defining a core feature subset.
Group Communication for CoAP (groupcom):
- This draft serves as a normative successor to RFC 7390, covering general group communication, including CoAP Observe, Block-wise, and Group OSCORE security.
- Key Updates (v05):
  - Removed the "Multi ETag" option for simplicity.
  - Clarified details on updates/obsoletions of RFCs.
  - Expanded section on "Application Group Naming," allowing identifiers in URI path, query, host, port, or as a CoAP option, or implicitly.
  - Expanded section on "Group Discovery," including examples of discovery via CoAP and Link Format.
  - Stronger Security Advice: Explicitly states that unsecured group communication is "not recommended," with exceptions like discovery requiring careful consideration and mitigation of risks (e.g., amplification attacks).
- The document is deemed ready for WGLC, with additional reviews planned.
Group OSCORE:
- Version 13 incorporated minor updates following the first WGLC.
- Key Updates:
  - Terminology aligned with AD-HOC draft for public keys (referring to CCS).
  - Fixed an oversight in Group Encryption Key derivation size.
  - Mandatory-to-Implement (MTI) clarified: Aligned with AD-HOC; non-constrained devices expected to support both EDDSA and ECDSA, constrained devices at least one. Similar rationale for pairwise key agreement curves.
- The document is considered ready for a second WGLC.
- Test vectors are being produced, expected to be extensive, and may warrant a separate informational draft.
- It was noted that Group OSCORE and Group Communication for CoAP should ideally proceed to WGLC in parallel.
Key Update for OSCORE (Kudos):
- Addresses key usage limits (encryption, failed decryptions) for AEAD algorithms, as per the C4G document.
- Part 1 (Key Limits): Defines fixed values (Q, V, L) for various algorithms, with 'L' (message size limit) now explicitly calculated in bytes. Probabilities for confidentiality and integrity advantage (CA/IA) are within safe margins, prompting an open question about increasing Q and L further.
- Part 2 (Kudos Procedure): A new one-round-trip rekeying method where client and server exchange nonces (R1, R2) to derive new contexts via UpdateCtx. It preserves the ID context and is compatible with AD-HOC. Extends the OSCORE option with a new flag bit and id_detail field.
- Observation Handling: Proposes terminating observations after rekeying due to cryptographic binding issues, as re-establishing is simpler than complex workarounds. This raised concerns about visibility at the application layer.
- Deprecates and replaces Appendix B.2 of RFC 8613.
- The document foundation and protocol are considered stable, with implementation plans.
Cacheable OSCORE:
- Focused on ensuring robust request-response binding, particularly in scenarios lacking source authentication for requests (e.g., non-traditional responses, group communication with untrusted members, non-authenticated GETs).
- The proposed solution involves embedding a hash or key information of the request into a Class I OSCORE option, making it part of the Additional Authenticated Data (AAD).
- This approach augments the standard OSCORE binding mechanism, allowing receivers to verify responses are tied to specific requests even without source authentication.
- This enhances cacheable OSCORE's readability and verifiability and enables new use cases where full signatures on requests are not desired.
OSCORE Capable Proxies:
- Aims to update the OSCORE RFC to define intermediaries as OSCORE endpoints, allowing for "nested OSCORE" (multiple layers of protection for the same message).
- Use Cases: Group CoAP proxy, multicast notifications, LwM2M server as a CoAP proxy, transport indication proxies, firewalls, and potentially long proxy chains for client location privacy.
- Key Updates (v01):
  - Lifted the previous limit of two protection layers.
  - Introduced a generalized, simplified algorithm for message processing applicable to any endpoint (client, intermediary, server).
  - Explicitly states no explicit signaling is needed; presence of CoAP options is sufficient.
  - Endpoints should not panic if an OSCORE option remains after decryption.
  - Certain options (e.g., CoAP corruption, proxy-intended options) must be protected.
- Next steps include adding caching examples (leveraging cacheable OSCORE), elaborating on use cases for more than two layers, and exploring compression with RFC 8824.
CoAP Option for Performance Measurement:
- Motivation: Address the lack of simple, low-overhead performance measurement for constrained CoAP nodes, especially in unreliable modes. Existing CoAP reliability mechanisms are resource-intensive for measurement.
- Proposal: A new CoAP option carrying "performance measurement bits" inspired by IETF IPPM's Explicit Flow Measurement, Quick's Spin Bit, and Alternate Marking Methodology's Square Bit.
- Mechanism:
  - Spin Bit: Creates a square wave signal whose length directly indicates RTT, reducing the need for extensive timestamping.
  - Square Bit: Uses a fixed number of packets in a square wave for loss measurement.
  - Event Bits: Reserved for advanced usage.
- Benefits: Easier RTT, delay, and loss measurement for constrained nodes, potential for advanced usage (e.g., adaptive protocol parameters based on network conditions).
- Further clarification on user scenarios, especially involving proxies, is needed.

Decisions and Action Items

Decision: The "Key Update for OSCORE" (Kudos) draft (draft-ietf-core-oscore-key-update) was adopted as a working group document, pending confirmation on the mailing list.
Action Item (Chairs): Initiate a working group last call for both "CoAP Group Communication" (draft-ietf-core-groupcom) and "Group OSCORE" (draft-ietf-core-group-oscore) in parallel.
Action Item (Chairs): Send a formal adoption call for "Key Update for OSCORE" (Kudos) to the mailing list.
Action Item (Chairs): Update the working group milestones on the data tracker to reflect ongoing work and upcoming documents for ISG submission.
Action Item (Chairs): Discuss and potentially schedule an informal meeting or interim focusing on CoAP applications, possibly in December.
Action Item (Authors - groupcom): Review updated parts, address open issues, and consider adding more concrete request/response examples for group discovery.
Action Item (Authors - oscore-key-update): Prepare test vectors (potentially in a separate document), further refine key limits, and address open issues on the GitLab repo.
Action Item (Authors - oscore-capable-proxies): Add caching examples, elaborate on use cases for more than two layers, and investigate RFC 8824 for compression.
Action Item (Authors - coap-performance-measurement): Clarify user scenarios and deployment models, especially concerning proxies.

Next Steps

CRI (href): More implementation and implementer reviews are needed before a working group last call. Address the functional deficiency regarding prefix compression and the percent encoding challenge.
CoRAL: Coordinate with potential users (e.g., problem-details, pubsub, SDF) to gather examples and define a core feature subset for the initial iteration.
Group Communication for CoAP (groupcom): Conduct further reviews of the updated sections, close outstanding issues, and potentially add more detailed examples.
Group OSCORE: A second working group last call will be initiated. Production of extensive test vectors will continue, with a decision needed on their publication location (e.g., separate informational draft).
Key Update for OSCORE (Kudos): Following working group adoption, continue refining the draft based on feedback, particularly concerning key limits and observation handling. Implementation efforts are planned.
Cacheable OSCORE: Continue to refine the request-response binding mechanism, particularly in scenarios without source authentication for requests.
OSCORE Capable Proxies: Add examples, elaborate on use cases for multi-layered protection, and explore integration with CoAP compression mechanisms.
CoAP Option for Performance Measurement: Further develop the draft, clarifying user scenarios and welcoming community feedback and collaboration.