**Session Date/Time:** 19 Jun 2024 14:00

# [CORE](../wg/core.html)

## Summary
The CORE WG held an interim meeting to address several open Pull Requests (PRs) related to the `core-clarifications` document. The primary focus was on clarifying aspects of CoAP, including Content-Format registry updates, URI path encoding, Request-URI terminology, and the complex interactions of message matching ("matchboxing") and re-keying across different security and transport layers (DTLS, OSCORE, KudOS, Group OSCORE, TCP). Key action items were identified for elaborating on these topics within the clarifications document and related drafts.

## Key Discussion Points

*   **Administrative Announcements**:
    *   The CoRP document is now in RFC editor queue 48; authors are addressing remaining questions.
    *   Updates to SeCore related to RFC 8610 grammar were made, addressing ISG comments.
*   **`core-clarifications` Document - General Approach**:
    *   The meeting focused on live discussions of PRs and issues for `core-clarifications`, with an aim to tackle four PRs in this meeting (PRs 7, 8, 9, 10).
    *   The document aims for clarification and potential work adoption.

*   **PR 8: Content-Format Registry Update Clarifications**:
    *   This issue (and corresponding PR) is largely resolved as the necessary registry changes were completed in January 2023.
    *   The clarifications document will point to the errata report for RFC 7252 (B2) which contains useful examples of valid/invalid Content-Format registrations.
    *   No further direct changes to the document for this PR, primarily an educational point.

*   **PR 7: URI Path Encoding of Trailing Slash**:
    *   This PR aims to clarify existing behavior rather than fixing a bug, as people often misunderstand URI path encoding.
    *   Discussion included specific corner cases in Sections 6.4 and 6.5 of RFC 7252:
        *   Section 6.4 (URI-Path option to URI Path Segments) cannot produce a single URI path option with an empty value.
        *   Section 6.5 (URI path options to URI) produces an empty path component if no URI-Path options are present (by appending a '/' to the authority component).
        *   If a request contains a single empty URI-Path option (which 6.4 cannot produce, but a server might receive), Section 6.5 produces a URI with a path component consisting of a single empty segment.
    *   It was noted that in CRI (CoAP Resource Identifier) space, a single empty slash is equivalent to an absent path due to URI resolution rules, similar to HTTP.
    *   Action: Add examples to the `core-clarifications` document (related to issue 7) to illustrate these corner cases and their implications, possibly researching RFC 9110 for HTTP comparison.

*   **PR 10: Term "Request-URI"**:
    *   This was identified as a definite bug in existing terminology.
    *   A proposed definition for "Request-URI" was provided, which looked good and consistent with its usage in sections like forward proxies.
    *   An implementation experience caveat was raised: there's a distinction between the URI requested and the base URI for resolving anything in the response (especially with multicast).
    *   Action: Define "Request-URI" and consider introducing a new term like "base for resolving responses" (potentially in CoRE-Resp) to clarify this distinction. The text should refer to "response for option" rather than "request for header."

*   **PR 9: Matchboxing and Re-keying**:
    *   This is the most complex PR, addressing challenges with state loss across re-keying events.
    *   **OSCORE**:
        *   OSCORE itself does not inherently have an inconsistency problem with message IDs or tokens; it relies on matched "matchboxes" (token/message ID scopes).
        *   Losing state on re-keying is problematic. OSCORE without an explicit re-keying mechanism (like KudOS) does not typically match requests/responses across security contexts, and observations are assumed to terminate.
        *   KudOS (RFC 9203) addresses some issues, including preserving observations across key updates and fixing a security issue related to partial IVs in responses across key updates (Section 3 of KudOS is proposed as a general fix that applies beyond KudOS itself, including to OSCORE RFC).
        *   Appendix B.2 of OSCORE was discussed; while it allows protecting a response with a different context, its specific design (intermediate contexts) makes it not suffer from the same security problems as a naive application of the KudOS Section 3 problem. It's largely superseded by KudOS.
        *   Action: Add explicit text on OSCORE's stance on token/message ID scope in relation to key updates, clarifying that without mechanisms like KudOS, scopes are terminated.
    *   **DTLS**:
        *   DTLS (as per RFC 7252 Section 9.1.1) mandates strict matching, with re-keying creating a new Epoch where no state can be carried over. This is consistent but unsatisfactory.
        *   To go beyond this, a secure way of linking "matchboxes" (token/message ID scopes) across Epochs is needed. This would require defining how Epoch chaining works and potentially signaling capabilities (e.g., via options or signaling messages).
        *   DTLS 1.3 session resumption introduces new factors that are not currently addressed in CoAP documents.
        *   Action: Elaborate on how to improve DTLS re-keying beyond the current strict model, considering DTLS 1.3 interactions.
    *   **TCP for Constraint Nodes (RFC 9060)**:
        *   Short-lived TCP connections also face similar state loss issues upon reconnection. Implications need to be considered.
    *   **Blockwise**:
        *   The implications of re-keying on blockwise transfers and the token space need to be addressed. If the lower layer switches, the token space may not be directly usable.
    *   **Group OSCORE**:
        *   Group OSCORE handles re-keying differently, with the group manager orchestrating updates. It has mechanisms to preserve observations across key updates and uses partial IVs similarly to KudOS (Section 3).
        *   Discussion touched on the crash resistance of group managers and the distributed system implications.
        *   Action: Add text to `core-clarifications` detailing how Group OSCORE handles these aspects.
    *   **General Goal**: Define secure ways to link "matchboxes" (token/message ID scopes) across re-keying/context changes for different security/transport layers (DTLS, OSCORE, TCP). This may involve signaling messages or options.

*   **Issue 35 (Christian's new issue)**:
    *   This meta-issue is about generalizing features and avoiding re-inventing the wheel across different transports, ensuring CoAP can use capabilities like BIRD everywhere and consolidating practices for implementers. This will be tackled as part of future clarifications.

## Decisions and Action Items

*   **PR 7 (URI Path Encoding)**: Add examples to the `core-clarifications` document to clarify corner cases related to empty URI path options/segments and their equivalence in CRI space.
*   **PR 10 (Request-URI)**: Update the terminology definition for "Request-URI" in `core-clarifications`. Explore adding a definition for "base for resolving responses," potentially within the `CoRE-Resp` document, to distinguish from the requested URI. Ensure accurate references (e.g., "response for option").
*   **PR 9 (Matchboxing and Re-keying)**:
    *   Review KudOS for completeness regarding handling non-observation pending requests across re-keying.
    *   Participants (Christian, Carsten) to draft text for the `core-clarifications` document:
        *   Clarifying OSCORE's implied default behavior regarding token/message ID scope termination upon re-keying and how KudOS (and Section 3) addresses related security issues (partial IVs).
        *   Detailing how Group OSCORE preserves observations and handles partial IVs across key updates.
    *   Further research and discussion needed on securely linking "matchboxes" across re-keying events for DTLS (especially considering DTLS 1.3 session resumption) and TCP connections, and the implications for blockwise transfers. This will likely involve defining chaining mechanisms and signaling capabilities.

## Next Steps

*   The next interim meeting is scheduled for two weeks from today (before IETF 120).
*   The group plans to resume meetings at the end of August (tentatively August 28th), alternating with SeCore.
*   Participants are encouraged to contribute the outlined text and PRs to the `core-clarifications` document as discussed. Any contributions made within the next two weeks can still be submitted before the draft deadline.