Minutes interim-2021-core-14: Wed 16:00
minutes-interim-2021-core-14-202112081600-00

# CoRE Virtual interim - 2021-12-08 - 15:00 UTC

Chairs:

* Marco Tiloca, RISE
* Jaime Jiménez, Ericsson

## Remote instructions

Material: https://datatracker.ietf.org/meeting/interim-2021-core-14/session/core
Webex: https://ietf.webex.com/ietf/j.php?MTID=mdd42b7c13deac94af584c4f5a7bf0ffa
~~Meetecho:
https://meetings.conf.meetecho.com/interim/?short=d0d8d377-c8f9-46ef-8708-1f13d069af9f~~
Jabber: core@jabber.ietf.org Notes:
https://notes.ietf.org/notes-ietf-interim-2021-core-14-core

Minute takers: Marco Tiloca, Christian Amsüss
Jabber scribes: Marco Tiloca

## List of Attendees

* Marco Tiloca
* Carsten Bormann
* Christian Amsüss
* Francesca Palombini
* Klaus Hartke
* Michael J. Koster
* Rikard Höglund
* Sean Turner
* Michael Richardson
* Thomas Fossati

## Agenda

### Note Well

Remember that the [note well](https://datatracker.ietf.org/submit/note-well/)
applies, for [IPR](https://tools.ietf.org/html/bcp79) but also for [WG
processes](https://tools.ietf.org/html/bcp25) and [code of
conduct](https://tools.ietf.org/html/bcp54). Try to be nice.

### Jabber & Minutes / Agenda bashing

### CORECONF - Carsten, Michael

https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/
https://datatracker.ietf.org/doc/draft-ietf-core-sid/

Presented slides:
https://datatracker.ietf.org/meeting/interim-2021-core-14/materials/slides-interim-2021-core-14-sessa-coreconf-cri-00.pdf

CB: Working on the IESG comments for yang-cbor and -sid, prioritizing DISCUSS
points. One remaining DISCUSS for yang-cbor, 2 remaining for -sid addressed in
v -18. Future v -19 will address COMMENT points. (Detailed progress/status on
p4) FP: Ben had also COMMENT points. Are they addressed? CB: I think most of
them, some may need additional discussions. FP: We need their replies, I'll do
the nagging. CB: Also, need to ensure everyone can get a SID.

CB: Almost addressed a DISCUSS from Rob Wilton, still working on some points,
plan to finish a big one this week. Then reply to Rob. Ben cleared his DISCUSS
and we'll reply to his comments. (Detailed progress/status on p5)

CB: Lot is happening through the design team meetings, involving both CoRE and
YANG people. One more meeting scheduled in December. Also got better ideas on
what to do later for core-yang-library and core-comi.

CB: Summary of latest technical updates (p7)
FP: New version planned?
CB: -18 isn't out yet; many are in editor's version, and when -18 is out then
the comments out there now will also be addressed, except for a few comments
that'll need -19s in both documents from responding to the comments. FP: But
comments there right now will be addressed in -18? CB: Y...y..yes, but look at
comment of p4 where we're really not sure. We'll have to send him an answer,
nothing to nag him about yet.

### HREF - Carsten

https://datatracker.ietf.org/doc/draft-ietf-core-href/

Presented slides:
https://datatracker.ietf.org/meeting/interim-2021-core-14/materials/slides-interim-2021-core-14-sessa-coreconf-cri-00.pdf

CB: (p8) Had extensive discussion at IETF112. Some open issues from there we
haven't really addressed yet, but these are about best ways to use CRIs, not
about the definition of CRIs.

CB: (p9) technical updates on CDDL features and percent-encoded text. Upcoming
v -09 should be an implementation draft incorporating those changes. Also have
to update test vectors with a PR to merge.

### KUDOS - Rikard

https://datatracker.ietf.org/doc/draft-ietf-core-oscore-key-update/

Presented slides:
https://datatracker.ietf.org/meeting/interim-2021-core-14/materials/slides-interim-2021-core-14-sessa-key-update-for-oscore-kudos-00.pdf

RH: document in two parts: limits of key usage and key update.
RH: focus on key update procedure today. Based on extending the OSCORE option,
to exchange parts of a nonce in a new 'id detail' field. The nonce is used to
derive a new OSCORE Security Context. RH: three open points: observations
surviving a key update or not; key update possibly without perfect forward
secrecy (PFS); possible (separate) update of OSCORE identifiers.

RH: on keeping observations, if nothing special is done, responses can
cryptographically match different requests (since OSCORE partial IVs are reset
after rekeying). Always and simply terminating observations after rekeying for
now, but there are two possible approaches to avoid it. RH: (p6) one approach
is "long-jumping", i.e. after rekeying, set the Sender Sequence Number (SSN) to
be higher than the highest PIV of any ongoing observation. Simple but with some
communication performance downside. RH: (p7) another approach is "skipping",
i.e. keep a list of already taken SSNs and don't use them. Better communication
performance, though check to be done for every request. CA: you need to take
into account any observation that the server has not yet acknowledged as
terminated, not just the current ones. CB: the client can still terminate the
observation, so there would be no waste of SSNs. RH: Right. CB: So you can have
a choice for the device between terminating and long-jumping. MT: But do you
prefer "long-jumping" over "skipping", right? CB: Yes, "skipping" sounds
onerous to do for each and every request. CB: Rekeying is disruptive anyway, we
need to understand what this means for an application, especially one thinking
real-time. Describe how desctructive it is. RH: And what should not be done
while rekeying. CB: Yes. The above is useful to reduce disruptiveness,
specifically as to observations. CA (on the disruption not only to observations
while this runs): Gotta go over the document again, but I *think* we can make
it continuously usable. (So that at every point in time the device can send a
message, even if it's using the intermediary context) RH: Right, it's most
about understanding which OSCORE context to use to protect messages in the
meanwhile.

RH: (p8) on PFS, the original design and main mode is about preserving PFS.
This requires that devices are able to store in persistent storage, which may
not be possible. For such devices, we define a possible alternative mode
without PFS. RH: (p9) this affects also the best key update a device can go for
after rebooting. RH: (p10) actual working of the no-PFS mode, setting one more
bit to 1 in the OSCORE option. The peers will always start from the "old
context" built from bootstrap Secret/Salt, so always the same at every reboot,
so no PFS. RH: (p11) the original way with PFS is still valid and to be
normally used; the no-PFS mode is for when at least one peer can't do better;
in a hybrid pair, it's possible to start in PFS mode and "agree to shift" to
no-PFS mode to accommodate the less capable device. RH: Overall good to do and
to do this way? CB: Is this exposed to a downgrade attack? RH: It should not be
possible the way the no-PFS mode is defined now. CA: The OSCORE option is not
protected though. RH: True, but the sender peer wishes to genuinely downgrade
anyway and proves that. An attacker might still flip the bit to force an
upgrade to PFS mode (which would not work anyway since at least one device is
not capable to). RH: Content to still add to the draft.

RH (p12): procedure to update OSCORE Sender/Recipient ID. It can be used
stand-alone or embedded in a KUDOS execution. Not to use right after a reboot
to avoid reuse of AEAD nonce. An exception is when OSCORE Appendix B.1 is used,
and thus the node can restart from a safe SSN. CA: Might be easier to phrase in
terms of "when having lost state", and being explicit about which state is lost
(here it's probably the set of Sender IDs ever used on this Master Secret). RH
(p13): defined new CoAP option to transport the new OSCORE Recipient ID of the
sender node. It's class E for OSCORE. Proposed number 24, elective to allow the
recipient to refuse updating the OSCORE IDs. Good to be an elective option?
Anything better than an option? RH (p14): example when run stand-alone (not in
KUDOS). An important point is when it is earliest safe to delete the old IDs
and the Security Context using those, to avoid running into an unrecoverable
deadlock. RH (p15): next steps on both limits of key usage and KUDOS
refinements (also based on GH issues and point discussed today). Can KUDOS
messages also transport data payload? Also plan to implement.

### AOB

MT: Biweekly interim meetings will resume on Wednesday, January 19th, at 15:00
UTC.

---

*[MT]: Marco Tiloca
*[JJ]: Jaime Jiménez
*[FP]: Francesca Palombini
*[CB]: Carsten Bormann
*[CA]: Christian Amsüss
*[KH]: Klaus Hartke
*[RH]: Rikard Höglund
*[TF]: Thomas Fossati
*[DN]: David Navarro
*[GS]: Göran Selander
*[BS]: Bilhanan Silverajan
*[AS]: Alan Soloway
*[MCR]: Michael Richardson
*[AK]: Ari Keränen
*[MJK]: Michael Koster
*[JM]: John Mattsson
*[NW]: Niklas Widell
*[ED]: Esko Dijk
*[EB]: Henk Birkholz
*[ST]: Sean Turner
*[ML]: Martine Lenders
*[MW]: Matthias Wählisch