Chairs (core-chairs@ietf.org):
Date and time: Tuesday, 2025-07-22, 12:30-14:30 UTC
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20250722T1230&p1=1440&ah=2
Meeting material: https://datatracker.ietf.org/meeting/123/session/core
Notes: https://notes.ietf.org/notes-ietf-123-core
Recording: https://www.youtube.com/watch?v=ltaPJEyW0bI
Zulip: https://zulip.ietf.org/#narrow/stream/core
Note takers: Ivaylo Petrov, Christian Amsüss, Rikard Höglund, Thomas
Fossati. Thank you!
Numbers in parentheses are minutes of time allocated.
Presented slides:
https://datatracker.ietf.org/meeting/123/materials/slides-123-core-chairs-slides-02
MT doing introductions.
ML: We will swap Christian's and my slot.
MT: Giving the status of documents in the WG and of related documents in
other WGs (p8-16).
MT: Reporting results from the Hackathon. Topics were DNS over CoAP and
AI agent operating devices using CoAP.
MT: Thanks to people who reviewed documents. Enjoy the ducks!
MT: Plan for future CoRE interim meetings.
MT: Esko will present "Leverage CoAP for Network Management" in the
OPSAREA session.
Presented slides:
https://datatracker.ietf.org/meeting/123/materials/slides-123-core-uris-00
CB presenting.
CB (p1): Back at the beginning of the WG: we can't use HTML, we can't
use HTTP, but we can use URIs ... well, we still use them, but there
are things to do.
CB (p2): Default value for the CoAP option Uri-Host. Over TLS, SNI
influences the default value (originally the destination IP address of
the request) in RFC 8323 (for "CoAP over TLS", we didn't want to change
RFC 7252).
CB (p3-4): Now that SNI is more widely used, I wish that we had made
that the default for DTLS too. Proposal: Update RFC 7252. (Not a
clarification: the text was clear, we just do not like what it (doesn't)
say anymore.)
CB (p5): Should we just change the text? What is the impact on
deployments? Is that an issue for implementations? We have to find out
whether new semantics apply. It is ugly. Can we couple this with
explicitly considering DTLS 1.3 too? (RFC 7252 is explicitly about 1.2,
we will have to write something.) Opinions are welcome.
CA: If we ask what people deployed, we can also ask people who deployed
DTLS 1.2 if anything in their implementation cares about the Uri-Host
option. Many implementations ignore those things, e.g., when using CoAP
in LwM2M. I suggest evaluating the impact on existing implementations
and deployments.
CB: What you say may soften the impact of a change.
CA (in chat): It's not easy to get a good DTLS implementation for
constrained devices in the first place.
ED: We can start with thinking about implementations that use CoAP that
I know about (Thread, mesh networking protocol). They are all based on
DTLS 1.2, no SNI use at all. This would not impact them.
JJ (on chat): why is it hard to find a good dtls 1.2 implementation? Is
it because of the constrainedness, the complexity? Just curious.
CA (on chat): Most are geared toward WebRTC, and the few ones that are
good and generic have small warts such as WolfSSL's implementation
disabling the 7252 MTI algorithm by default because they consider it
unsafe.
JJ (on chat): Very good insight, thank you!
CB (p5): It's all in the issue #49, please comment there (or on the
mailing list).
Presented slides:
https://datatracker.ietf.org/meeting/123/materials/slides-123-core-uris-00
CB switching seamlessly to -href (p6)
CB (p7): The topic of the default value for the Uri-Host option comes
back when considering the translation between CoAP messages and CRIs.
CB (not on slides): Also, we have an explicit issue in
draft-ietf-core-corr-clar that would prefer not having that algorithm
rewritten for every transport. A given authority component may mean
different things for different transports. A PR is open, it needs work.
CB (p8): Zone identifiers break things. That happened here too. I
thought we solved it and RFC 6874 defined how to include a zone
identifier in a URI, but the browser implementers ignored it. That RFC
is now obsoleted. So currently there is no way to include a zone
identifier in a URI. CRIs do not have that syntax problem (no percentage
encoding is used). Link-local addresses are important in many CRI
applications, thus we keep zone identifiers in CRIs.
CB (p9): The situation is in flux, with white areas on the map. Mike
Bishop's review: "situation is in flux, but white areas don't have to be
that large". We have a resolution PR, as to not translating such CRI
references into URI references.
CB (p9): People told me that they use zone IDs on IPv4 addresses.
CB (p10): Zone identifiers are assumed to be UTF-8, although not
everyone agrees with that due to complex history. We can keep that and
clean the CDDL, thus allowing more things than before.
CB (p11): The IESG approved RFC 6991bis, including IP with zone ID.
CA (on chat): Not unhappy? I am unhappy about zone IDs going away. As
long as you can say "localhost" or "10.0.0.1", there are just some URIs
that can't meaningfully be sent over the network.
ML presenting.
ML (p1): This work is about a problem statement. The goal is to define
SvcParam to bootstrap security for CoAP.
ML: Is there still a problem that needs stating?
(no opinion in the room)
MT: If the answer is no, isn't this useful information to have in
draft-ietf-core-transport-indication, maybe as an appendix?
ML: Yes.
MT: Please weigh in on the mailing list!
Presented slides:
https://datatracker.ietf.org/meeting/123/materials/slides-123-core-coap-transport-indication-01
CA (p1): Continuing with the topic that Martine started.
CA (p2-4): Parallel perspectives: Web-links and DNS. Clients can
discover means to reach a host.
CA (p5): Example scenario: "Find temperature at /t of sensor1".
CA (p6): Where is that (IP)? Client does name resolution, e.g., using
DNS. ALPN originally came from TLS, but in the registry there are
entries that do not come from there, so using it here makes things
easier.
CA (p7): Which transports are available? As a result of the lookup
process, there is the need to also indicate what transport to use (e.g.,
coap over TCP). It gets more complicated when it comes to considering
other future IP-based transport, which will not get a coap+X scheme.
CA (p8): If we had a hypothetical CoAP over QUIC, then ALPN could be
used to indicate that, e.g., with "ALPN: coqu".
CA (p9): As a client, how do I know whom to talk to? This might also
mean that I need to discover security information to use with the target
peer. This can be encoded in the URI as hexhexhex.cred.service.arpa/t,
and in a "cred" ALPN parameter.
CA (p10): Additional notes.
CA (p11): We need feedback from the WG about the modeling, e.g., about
what metadata we want to have and what belongs where. Does this fit with
SVCB? How does DANE fit with SVCB?
MB: Not speaking as AD but as SVCB co-author.
I don't think we have any precedent for a nonencrypted protocol being
indicated by a SVCB record.
I don't see a reason why it wouldn't work.
You can have ALPN tokens and there is already one ALPN token reserved
for an unencrypted protocol, h2c.
I just filed an issue for you in your draft: h2c has a helpful note in
the registry that says this should never actually appear in a TLS
handshake.
You probably want a similar note.
Conceptually the way the way it works with HTTP is that if you ask for
h1 or h2, then we're going to try over TCP with TLS.
If you ask for h3, we're going to try over QUIC.
So I think this follows a similar pattern: the ALPN token actually
implies the transport
Then what actual application layer protocol you pick over that transport
might vary.
In this case you only have one but I think conceptually this can work
it's just novel.
ED: Do we need to consider that this may not be resolved via DNS?
(That's not required by RFC 7252)
CA: The list on p4 is not exhaustive.
CA: There can be many ways for a system resolver to do this. DNS
provides a good example. E.g., CoAP over GATT has mechanisms there (map
a MAC address to a CoAP endpoint).
https://datatracker.ietf.org/doc/draft-ietf-core-oscore-key-update/
https://datatracker.ietf.org/doc/draft-ietf-core-oscore-id-update/
Presented slides:
RH presenting.
RH (p2): KUDOS protocol: what and why.
RH (p3): Components, nonces, using Z bit to indicate who has received
which nonce.
RH (p6): Recent changes; collisions are relevant in non-FS [FS =
forward secrecy] mode where they can happen, and thus long random
nonces are needed.
RH (p7): More protections and interactions.
RH (p8): State machine optimization / simplification: a complicated path
is avoided by not transitioning back, if the peer can verify that the
pair (nonce, X) has been processed this way already. It is easy to
verify that, by comparing the derived OSCORE Master Salts.
RH (p9): Next steps. Comments, reviews welcome!
RH on ID update.
RH (p2): We can update the OSCORE Sender ID and Recipient ID (plaintext
identifiers!). Switching identifiers effectively switches keys. This
mitigates privacy issues due to trivial message correlation on the event
of a path switch (e.g., in case of network migration).
RH (p3): Redesigned as based on an approach aligned with KUDOS. The
newly offered Recipient ID is explicitly acknowledged by the other peer.
The offer and the acknowledgement rely on two new CoAP options.
RH (p4): After at least 2 sent id message and 3 received id-ack
messages, it is done. The new OSCORE Security Context based on the new
IDs can be used but should not be used yet; it is intended for use when
a network switch occurs, and other identifying information changes too
(e.g., addresses).
RH (p4): Recipient IDs cannot be reused on a single key.
RH (p7): Emphasize that new IDs should not be used on the old network
segment.
RH (p7): We also added some security considerations pointing out that
you can track peers by looking at oscore partial IV (PIV) in the OSCORE
option.
If you see PIV 100 and then something pops up on a different network
with PIV 101, it's quite likely that's actually the same peers
transitioning to a new network.
Fortunately because we're deriving a new OSCORE security context CTX_B
is a brand new context with the new ids and that means the partial AV
the sender sequence number resets back to zero.
(And obviously there's other information that can be used to track the
pairs you know like the network information.)
So upon network migration you would hope to switch network address and
also switching the link layer address because otherwise those could be
used to to track the peers.
RH (p8): Next steps. Plan to implement. Comments and reviews welcome!
Presented slides:
https://datatracker.ietf.org/meeting/123/materials/slides-123-core-observe-notifications-as-coap-multicast-responses-00
MT presenting as an individual.
MT (p2): Recap and mechanism (information to participate in group
observations is transported in error 5.03 responses).
MT (p3): Updates in version -12: updated to use the CBOR type ~time for
the "ending" parameter of the error informative response, thus being
more granular when expressing the cancellation time of the group
observation; generalization of the payload of the informative response
and its semantics (other documents can use the same structure for
different purposes, see, e.g.,
https://datatracker.ietf.org/doc/draft-tiloca-t2trg-sw-update-groupcomm/
).
MT (p4): More updates in version -12. Updated the CBOR type of one more
parameter ("exp" also in the informative response, to be aligned with
the change in "ending"), and corrected the name of another one.
MT (p5): The biggest change is about the understanding of the transport
to use, based on the pair (scheme, authority) in the CRIs specified in
the error informative response. In general, the scheme alone is not
sufficient to identify the transport anymore; we restructured on how
transport is indicated and understood. Part of that was changing the
structure of the newly defined IANA registry on transport for CoAP,
which becomes simpler. This is also relevant for parsing details
(specified in the "tp_details" parameter of the error informative
response), based on transport used.
MT (p6): Next steps, including discussion among authors on minor
technical points. Plan to address two comments from IANA. The main big
point is to split the document into two separate ones: a new one with
all content related to proxies taken away from the present document; and
the present one with the rest of the content (strong request at IETF 122
in Bangkok).
MT (p7): Split is being planned and can be now enforced. Question:
should the new document about setup with proxies have intended status
Informational (as suggested by CA)? Interested in other opinions.
MT: Opinions on intended status from the Chairs?
CB: If it does not have a normative intent, it is informational. It
seems obvious to do that. As a high-level statement, let's make sure
that our documents stay under 100 pages. Informational additions should
not take over, I support this.
MT: So Informational it is.
MB (as an individual): You are using 5.03 as response code for the
informative error response. It is similar to HTTP and it is a server
error. Looking what you are doing here, it is not really a server error
though. Why do you use that response code?
MT: It means service unavailable. If the server receives a traditional
Observe request from a client, the server uses it to say: "I reject this
request the way you want it (that service is not available) and I have
something better to offer. Here's the information to participate in the
better way".
MB: And CoAP does not have 3.00 (redirect), so ...
MT: It is a redirect (3xx) in disguise, while are in fact forbidding
actual redirection.
Presented slides:
https://datatracker.ietf.org/meeting/123/materials/slides-123-core-cacheable-oscore-00
CA (p2): This makes OSCORE responses effectively cacheable. We cannot
cache with vanilla OSCORE, since each request is individually encrypted
and the responses are bound to the requests. This new construct builds
on Group OSCORE (draft-ietf-core-oscore-groupcomm).
CA (p3): What will cacheability cost?
CA (p4): Luckily not too much: replay protection and source
authentication of the protected Deterministic Requests. Replay
protection is moot anyway in this case, since this is about cacheable
resource representations (e.g., retrieved with the GET method). Source
authentication is now bound to the single "virtual" Deterministic Client
that any real client in the group can act as. Freshness is limited and
request privacy is limited (a proxy needs some information). We hope
that applications that want caching can make these trade-offs.
CA (p5): What happens to OSCORE when there is no source authentication
of requests? This uses deterministic requests with best-effort
determinism. Key material is needed that multiple parties can use, but
there is no AEAD nonce reuse.
CA (p6): Describing the different mechanisms used. One specific
particular message will be encrypted with a specific key.
CA (p7): Which AEAD algorithms are deterministic? All of the current
ones. We would like more eyes on the security: is it relevant anywhere
to have constant-time operations? Does anyone need more text in Section
2?
CA (p8): We had a successful interop test between Marco's implementation
for Californium and my implementation for aiocoap. The draft includes
test vectors based on that.
RM (in chat): Is MLS possible here for shared crypto? Or is it too big
objects to transmit for key setup?
RM: I have seen too many shared key protocols. MLS is the only one
mathematically sound... Lots of things to leverage to share keys
cheaply, but you pay in other ways.
CA: I need to read up on MLS.
RM: MLS derives one key that can be used to encrypt data between
multiple parties.
CA: We already have a key shared between multiple parties (from Group
OSCORE).
Presented slides:
https://datatracker.ietf.org/meeting/123/materials/slides-123-core-coap-over-bp-00
CG (p2): Revision -04 addresses various feedback.
CG (p3): Updated ToC with new and modified sections.
CG (p4): Payload length information. Considered defining header
parameter for Bundle Protocol (BP), but it will not work for other
transports like UDP. We defined a CoAP option Payload-length. This
option is now unsafe to forward.
CG (p5): The Payload-length option will be class U for OSCORE. When
using OSCORE, the Payload-length option will contain the OSCORE message
payload size.
CG (p6): Message aggregation in supporting proxies, which may
disaggregate and aggregate. The diagram could represent clients on
Earth, proxy in Mars orbit, and servers on Mars.
CG (p7): We added a section about implementation status. The main
implementation is Space CoAP. (Note: other implementations exist but
they did not implement the Payload-length as they predate it)
CG (p8): Security considerations: listing risks and possible solutions.
CG (p9): Want to ask for WG adoption.
CA (in chat): Those security considerations almost sound excessive: If
things were not aggregated, the lengths would be just as visible.
ED: Did you consider bundling other protocols like CoAP + something or
proto + CoAP?
CG: Our concern with a specific option for BP was that other transports
like UDP would not be supported.
MT: How many have read the last version of draft (authors excluded)?
(1 hand raised)
MT: How many have read any version of the draft (authors excluded)?
(5+ hands raised)
MT: Better already.
Poll: Do you think that CoRE should adopt draft-gomez-core-coap-bp as a
Working Group document?
Poll results: 12 yes, 11 no opinion, noone is against. (+1 on chat)
MT: The Chairs will issue a WG Adoption Call on the mailing list.
Presented slides:
https://datatracker.ietf.org/meeting/123/materials/slides-123-core-encrypted-partial-iv-in-the-constrained-application-protocol-coap-oscore-option-00
MT presenting as individual.
MT (p1): For OSCORE and Group OSCORE, this encrypts the Partial IV in
the OSCORE option.
MT (p2): Mostly in requests, as the Partial IV is less common in
responses while it is a must in requests. The OSCORE option is overall
unencrypted. There is a risk of tracking nodes across network segments
and of profiling their traffic leveraging the plaintext Partial IV. This
was raised in an old issue of the OSCORE Github repository, but was
considered not useful if nothing can be done about peer IDs too (e.g.,
encrypting or updating those). Now we have a means of updating the
peer IDs, see draft-ietf-core-oscore-id-update presented before.
MT (p3): The intent is to update the OSCORE RFC, i.e., RFC 8613. This
document provides a lightweight method for encrypting the Partial IV. It
works as an optional pluggable add-on. There is no in-band signaling.
Using it or not is a property of Security Context that is set when
establishing the Security Context (just like it is the case for the
encryption algorithm). So it needs to be agreed on Security Context
establishment. By default, it is NOT used, to ensure retrocompatibility.
MT (p4-5): Describing details of how the Partial IV encryption works
step-by-step. High-level: derive an additional key once and for all at
Security Context establishment; after protecting a message, derive an
IV_KEYSTREAM using as input the new key and some (padded) bytes taken
from the message payload. The encrypted Partial IV is the XOR between
IV_KEYSTREAM and the plaintext Partial IV.
MT (p6): Considerations on info leakage from the Partial IV length. This
solution is cryptographically safe against passive adversaries, while
active adversaries have more leeway and may use side-channel attacks to
figure out some info due to replay checking happening before decryption
(the OSCORE processing of incoming messages is not meant to be
constant-time).
MT (p7): How to decide whether to use this or not is out of scope, but
still it needs to be done when establishing the Security Context.
Possible ways to do this will come in next versions and the draft
already mentions them as placeholders.
CA: You mentioned that encrypting the PIV only makes sense if you change
the IDs. But when the IDs change the PIV resets to 0. So isn't it
pointless to encrypt the PIV?
MT: You may want to hide that you start again from 0. The attacker
already sees that the ID has not been used yet so...
CA (chat): Let's follow that offline, I think it may be easier to more
often change the identifiers and start off with non-zero PIVs.
MT (on chat): That would make the new ID not usable for a non-trackable
network migration, and the new (not necessarily 0) Partial IV will still
be shown as growing monotonically. Anyway, happy to continue discussing
offline.
CA (chat): If, of course, the key to use were set by the recipient, and
the recipient could send the same key to all its peers, then also the
recipient ID could be encrypted.
MB (chat): This feels very reminiscent of QUIC's packet number
encryption. Thoughts from having survived that process: TCP deals with
intermediaries that try to be helpful by inspecting packet numbers and
rearranging packets. Does CoAP have a similar problem you're trying to
solve here? Hardware offload paid a price for this functionality,
because most NICs were not able to offload the two-step encryption. Does
CoAP depend on any hardware offload that would need to be considered
before doing this?
CB (on chat): Christian: Why does the key need to be the same? (That
creates a lot of linkability and opportunities for collusion, I think)
CA (on chat): Well, if the KID field is encrypted, the server doesn't
know which peer the request is coming from, can barely try all
established ones.
CB (on chat): I'm interested in how barely...
CB: For TLS ECH, we have spent the last 5 years watching the TLS WG
developing this based on some privacy requirements. Then things are
deployed worldwide, and then discarded because they missed some more
privacy considerations. We should be really careful here.
MT: True and not intending to radically change vanilla OSCORE.
https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-grasp/
https://mailarchive.ietf.org/arch/msg/core/sIwzOAweYaLfVLaJEgBR_9xdm80/
Presented slides:
https://datatracker.ietf.org/meeting/123/materials/slides-123-core-constrained-grasp-00
TE (p2): Giving background on GRASP. Not meant to replace HTTP or CoAP.
(Typo: RFC8995 should be RFC8990)
TE (p2): Simple CBOR, simple header, no transport/security in it (done
on outside).
TE (p2): Unique features: no layer of request/reply, URL etc., unless
brought through fields.
TE (p2): Multi-exchange transactions can be established, with failure
canceling all operations. (Not just once back, once forth.)
TE (p2): The second big feature is service announcement and information
flooding. It works via hop-by-hop agents. We know the pain of attempting
reliable multicast.
TE (p3-4): CoRE interactions, options for how to take advantage of
functionalities from CoAP for GRASP. We want feedback on the options.
CA: The one I could suggest most is option 3, but as you ask about 1 and
2: on 2, what do you mean for message types?
TE: Method code.
CA: That was last touched before I got to CoRE seriously.
CA: On option 1: if you want to extract a reliability mechanism, you can
alter the CoAP version field (or you do not even need to, since it is
another protocol). Option 1 would be about copying out the parts of CoAP
that you want.
TE: Hard to hear, let's continue on the mailing list.
MT: This is also a good topic for an interim meeting.
Σ 120