CoRE Virtual interim - 2024-07-03 - 14:00-15:30 UTC

Chairs:

• Marco Tiloca, RISE
• Jaime Jiménez, Ericsson
• Carsten Bormann, TZI

Remote instructions

Material:
https://datatracker.ietf.org/meeting/interim-2024-core-10/session/core
Meetecho:
https://meetings.conf.meetecho.com/interim/?group=47f04466-563b-475e-9737-d50a53359259

Notes: https://notes.ietf.org/notes-ietf-interim-2024-core-10-core
Zulip: https://zulip.ietf.org/#narrow/stream/core

Minute takers: Christian Amsüss, Rikard Höglund
Chat monitor: Marco Tiloca

Note Well

Remember that the note well applies, for IPR but also for WG
processes and code of conduct. Please be nice to each other.

Chat & Minutes / Agenda bashing

MT doing introduction.

Agenda

corr-clar incremental progress (PRs)

https://datatracker.ietf.org/doc/draft-bormann-core-corr-clar/

https://github.com/core-wg/corrclar

https://datatracker.ietf.org/meeting/interim-2024-core-10/materials/slides-interim-2024-core-10-sessa-corr-clar-04-update-00.pdf

CB presenting: Aiming for more discussion than slide presentation.

PR #32 (Now merged)

https://github.com/core-wg/corrclar/pull/32

Intended to close issue #7

CB (p2): On meaning of trailing slashes. Currently well-defined, but add
examples.
CB: This is a formal addition. Remaining question: are these examples
enough?

CA: Can we also have one example with the question mark used?
CA: Like coap://authority?foo=bar
CB: OK.
MT: I had in mind 3 corner cases that I mentioned at the previous
interim meeting. I will check again the examples.

CB: Having an example with something after the question mark, or a
fragment identifier can be useful.
CA: Swapping the authority/foo with authority/// can make sense as one
is the normal case. Maybe even state that a server is under no
obligation to support coap://authority/// if it does not mint them.
CB: Noted.

PR #31 (Now merged)

https://github.com/core-wg/corrclar/pull/31

Intended to close issue #8

CB (p2): This is related to an erratum that also led to an IANA update;
the PR just points to the errata report.
CB: Do we want to copy additional notes from the erratum? So far, I have
heard "no".
CB: Unless this needs further work, I think that issue #8 is done.

CA (on chat): :+1: on #8 being done.

PR #33 (Now merged)

https://github.com/core-wg/corrclar/pull/33

Intended to close issue #10

CB (p4): Merged because the first round on it is done, but it still
needs more checks. Another question is the relation between "target URI"
and "base URI". Shall we put them in relation with each other?
CB: The context here is that "base" for responses to multicast requests
is adequately explained in section 8, but it assumes that we already
understand what a "request URI" is. What makes this more difficult is
that HTTP has transitioned terms. RFC 7230 had "Request URI", in RFC
9110 it is "Target URI".
CB: Do we want to copy/emulate what HTTP did or continue using "Request
URI"? HTTP does not have content corresponding to the section 8 of RFC
7252, because HTTP does not do multicast.

CA: Opinions would need concrete suggestions.
CB: The PR was merged, but the issue is still open. There is still work
to do on this topic.

PR #34 (Now merged)

https://github.com/core-wg/corrclar/pull/34

Intended to further address issue #9

New tentative contribution related to OSCORE, KUDOS, and Group OSCORE.

CB (p5): "Match boxing", or "how do you keep your Observe relations
alive while something changes below you".
CB: We have a good understanding of the current state. Things are well
defined for DTLS and RFC 7252.
CB: RFC 7252 handles the unextended DTLS 1.2 case.
CB: One can see as an opportunity the fact that a specified semantics is
undesired, because the state goes away needlessly. The current text
suggests 3 approaches: (see slides). We could write up how a DTLS
connection identifier could be used across epochs. This may mean needing
some kind of negotiation, so that both peers know if they support
it/require support from the other side.
CB: For example, DTLS is able to have a connection survive after a
change of IP address. We will want to look at that for OSCORE. Things
like that probably need to be negotiated.

MT: Relaying a comment from Achim Kraus on GitHub: consider the use of
Connection IDs in DTLS. They are an extension in DTLS 1.2, and natively
available in DTLS 1.3.
CB: That's why RFC 9146 is listed on the slide. But the DTLS 1.3 case
also needs to be addressed. The semantics defined by text in RFC 7252
may be very undesirable.

PR #36

https://github.com/core-wg/corrclar/pull/36

Intended to close issue #9, as a follow-up to #34

MT: Discussed PR #36 with Carsten yesterday, about PR-merging strategy.

MT: This new PR proposes 3 different parts about OSCORE, KUDOS, and
Group OSCORE. Different aspects come back for all of them: i) the
non-relation with CoAP Token and MessageID used for match-boxing; ii)
the survival of observations on change of Security Context; iii) how to
handle the delicate case where a response is protected with a Security
Context different from the one used to protect the corresponding
request.
MT: Chronologically, we noticed these in Group OSCORE first, then the
same constructs or features were defined in KUDOS in the interest of
OSCORE. The PR discusses match-boxing and the aspects above for OSCORE,
KUDOS, and Group OSCORE.

CB: I have an issue with the "has no impact" wording. We need to be more
explicit.
MT: For Token and MessageID, OSCORE and Group OSCORE are agnostic.
CB: I want clarifications for this.
MT: Should we say that Token values and MessageIDs are not input to
OSCORE processing?
CB: We can say that. It would be good also to have text about why
security properties continue to work.
CA: It's also helpful to consider that OSCORE can be used across
proxies, so MessageIDs and Tokens will change for each communication leg
without issue.
MT: When using OSCORE and Group OSCORE, they have their separate level
of match-boxing under the control of OSCORE (through the COSE
external_aad built by OSCORE).
MT: Also, the key material can be updated without changing Token values,
as the two things belong to different conceptual layers.
CA: But that is the hairy part, and, if you do that, you have to be
careful.
MT: Yes, that's why KUDOS has the possible confirmation for mutually
agreeing on preserving observations or not. Instead, Group OSCORE
achieves that by relying on the Group Manager as managing the OSCORE
identifiers of the group members and of the group in a particular way,
also to ensure long-living observations across group rekeying
executions.

RH: CB mentioned negotiation; KUDOS does that.
CB: And in Group OSCORE we have unilateral "negotiation" from the Group
Manager saying how it is.
MT: So elaborating on these points would help?
CB: Yes.
MT: Fundamentally, the Token and the MessageID do not take part in
OSCORE security processing.
CB: And there is a dedicated way (the COSE external_aad built by
OSCORE) to bind a request with the corresponding responses.
RH: The Token is used in some situations for retrieving the OSCORE
Security Context to use.
CB: Do you have a risk that you pass a successful matching by Token, and
then still manage to decrypt successfully while you should not?
RH: No, you are supposed to start with good entropy for the OSCORE
Master Secret (and the Master Salt, if set, also helps.)
CA: Also, for each OSCORE Security Context the quartet (Master Secret,
Master Salt, ID Context, Sender ID) "MUST be unique". This is a hard
requirement from OSCORE. (See Section 3.3 of RFC 8613).

CB: Does it make sense to do a -05 before the Vancouver meeting? Will I
get enough material?
MT: I need to think about what to write.

CA: Question: DTLS now allows for connections to switch address. Do you
think OSCORE does not enable that? I do not remember any requirement
about OSCORE binding the Security Context to specific addresses.
CB: Will every implementation ignore incoming transport address?
RH: It is doing the lookup based on the 'kid' in the OSCORE Option.
CA: And, if the KIDs are not unique, there are KID contexts (but OSCORE
is wobbly on when to use/send them; I never saw them in action).
CB: Basically, if the underlying CoAP implementation does not give you
the message, then OSCORE cannot process it.
CA: OSCORE does not alter that the response needs to come from where the
request was sent, but that just follows from using transports where that
is a requirement.
CB: We may want to record that in text also.
MT: OSCORE itself does not use the 5-tuple.
CA: OSCORE does not touch any low-layer identifying stuff; it is putting
data into a request-response mechanism, and however that matches
responses to requests is what OSCORE gets (5-tuple, MessageID or no
MessageID, file handle, whatever).
CB: So what we do below OSCORE to handle changes in the transport
address so that is transparent to OSCORE? But it needs to work well
enough to get the data to OSCORE.
MT: A server receiving a request needs to be pointed to the OSCORE
Security Context to use for decryption. An incoming response uses the
same Security Context as the request used (unless there is a key update
in between, which does not come as a surprise, and a proper protection
of the response in that particular case has been defined).
MT: You can even change transport across proxies.
CA: You can even change address between requests. It's more the other
way round: in Onion CoAP, we have to enforce that some OSCORE Security
Contexts should not just be looked up by 'kid', but by the client's
address (actually which-tunnel-it-came-from) and the KID together.
MT: You had a similar comment related to
draft-ietf-core-oscore-capable-proxies (CA: Yes, that's where it
eventually wound up), where we added considerations that the server
should perform additional checks before decrypting a request. A
malicious client could otherwise attempt to get a server to reveal its
network location, while the server's intention is to remain hidden
behind a reverse-proxy.

CB: This can easily exceed this document's scope.
MT: Does it help to split out a separate section about OSCORE etc.?
CB: Yes, we can start with general text and then sub-subsections for
DTLS and OSCORE, and briefly CoAP over TCP.

CA: Multi-path TCP (MPTCP) can also switch addresses "mid-connection"
like DTLS.
CB: Meaning that you need a new connection.
CA: There is no unique new connection through which the application
comes.
CB: We need some type of connection identifier.
CA: We may not need to deal with that, but just to be aware that "the
peer's IP address" is not as unique as we think, so care is needed about
that.

CB: The best thing to happen is having a few PRs that have text, maybe
overlapping, maybe contradicting, but then we merge them and continue
processing. It's better to have attention on the items than not having
attention on aspects we are waiting to be resolved.
MT, CA: Agreed.
CB: We can restructure things later, it's better to have text in place
for now.
MT: I will clarify according to my plan.
CB: You can also introduce a subsection for OSCORE if you wish.

MT: Do you plan follow-up PRs?
CB: Yes, for issues #9 and #10. Issue #8 is done. Issue #7 is done
modulo CA's new example(s).

MT: You had comments on my PR #36 yesterday. I replied to those on
Github, please check.
CB: Will do.

AOB

MT: This was the last meeting before IETF 120, where we have a 2-hour
slot on July 24

CA: Off-topic: "The Internet" (OK, the fediverse) is making fun of IETF
for not having IPv6 on their own infrastructure:
https://bsd.network/@florian/112717858906705257
https://chaos.social/@onepict/112718750623441835