Minutes IETF110: core: Mon 17:00
minutes-110-core-202103081700-00

# IETF 110 - Constrained RESTful Environments (CoRE) WG

Chairs (core-chairs@ietf.org):

* Jaime Jiménez (jaime at iki dot fi)
* Marco Tiloca (marco dot tiloca at ri dot se)

Stand-in Chair for IETF 110:

* Carsten Bormann (cabo at tzi dot org)

# Monday, March 8, 2021

Number of participants: 16:10 (44); 16:50 (50); 17:30 (52)

Meeting material: https://datatracker.ietf.org/meeting/110/session/core

Etherpad: https://codimd.ietf.org/notes-ietf-110-core?both

Meetecho video stream:
https://meetings.conf.meetecho.com/ietf110/?group=core&short=&item=1

Audio stream: http://mp3.conf.meetecho.com/ietf110/core/1.m3u

Minute takers: Michael Richardson, Göran Selander, Marco Tiloca (helping)

Jabber scribe: Marco Tiloca

**16:00 - 18:00 UTC**

Numbers in parentheses are minutes of time allocated.

## Intro, agenda, status (Chairs) (10)

huzzah for new working group chairs (jaime has a new child)

Carsten standing in as chair for Jaime

Thanks to Barry Leiba as outgoing AD, welcome to Francesca Palombini as new AD.

Two sessions, Monday + Friday, agenda trying to avoid conflict with Friday's
DANISH BOF.

WG and document status

* Published
    * RFC 8974 (was draft-ietf-core-stateless)

* RFC Editor Queue
    * draft-ietf-core-dev-urn-11

* IESG Processing:
    * draft-ietf-core-resource-directory-28: Approved-Announcement Sent
    * draft-ietf-core-echo-request-tag-12: Approved-Announcement to be
    Sent::Revised ID Needed

* In Last Call
    * draft-ietf-core-yang-cbor-15:  In Last Call, until 2021-03-17
    * draft-ietf-core-sid-15:  In Last Call, until 2021-03-17

* In Post-WGLC processing:
    * draft-ietf-core-yang-library-03: waiting for shepherd write-up
    * draft-ietf-core-comi-11: waiting for shepherd write-up
    * draft-ietf-core-oscore-groupcomm-11: processed WGLC comments and one more
    review; ongoing work on open points * draft-ietf-core-senml-data-ct-03:
    processed WGLC comments; synch with
    draft-bormann-core-media-content-type-format *
    draft-ietf-core-new-block-07: processed WGLC comments

## Groupcomm-bis (Esko) (15)

* draft-ietf-core-groupcomm-bis-03

   - Discuss updates and open points

ED: Latest updates include also support for reverse proxies.

ED: Also added caching of responses; this requires two types of cache entries
at the proxy, i.e. "aggregated" cache entries and "individual" cache entry.

ED: A validation model is also defined, between client and servers with a new
Multi-ETag option, and between client and proxy with a new Group-ETag option.
If you want to go through multiple proxies, then you need multiple tags.

GS: Why would I want to validate a number of reports at the proxy with
Group-ETag?

ED: Say you're querying a number of device status reports, and one is large and
the client doesn't want to get it sent again. The last full collection of
reports at the proxy is still valid in its entirety.

CB: Is the Multi-ETag option actually repeatable?

MT: It is mimicking the ETag option.

ED: If Group OSCORE is used end-to-end, cacheability can still be achieved
using the deterministic requests of draft-amsuess-core-cachable-oscore.
However, this is limited end to end between client and servers, with response
validation also still possible although trading flexibility against efficiency
of caching at the proxy. Instead, no validation involving the proxy as active
aware party is possible (i.e., the proxy can't use the Multi-ETag option as if
it was client, and clients can't use the Group-ETag option with the proxy).

CA: We should treat the E-Tag options in the draft-tiloca-core-groupcomm-proxy
document that would progress at its own pace, so that this new content does not
hold this document.

CB: Agree.

ED: That's easy to imagine for the Group-ETag option as really related to
proxies. But where should the Multi-Etag option be? It's not directly related
to proxy operations.

CA: Right, but it uses the transport information structure and encoding defined
in the proxy document to identify a server, so that may still be a good place.

ED: Next steps are about addressing open Github issues; moving some content to
the rights places / different documents; implements aspects involving e.g.
observe and blockwise.

## Group OSCORE (Marco) (15)

* draft-ietf-core-oscore-groupcomm-11

   - Discuss updates following WGLC and new open points

Marco presenting.

MT: updates in -11 address Christian's review ...

https://mailarchive.ietf.org/arch/msg/core/pXEyxhbf-s2wgGDzrDhUNPsHZZc/

... and more points agreed on during IETF 110.

MT: New open point 1: Observations and GIDs. Currently forbidden to recycle GID
values, to prevent bad things when using observation. Solution: the Group
Manager stores also the "birth GID" of each group member, i.e. the GID that the
group uses when that member joins. If, upon rekeying, the Group Manager would
set as new GID the "birth GID" of any current group members, the rekeying has
to exclude also those nodes, cancelling their membership. They will eventually
rejoin, thus closing all ongoing observations, thus solving the problem. Then
GID values can be recycled and a group can "live forever". It just requires
some additional mechanics and storing of the various birth GIDs on the Group
Manager.

No objections to do the change.

MT: New open point 2, also in Github issues #72, #73. Using the same identity
key for two purposes, i.e. signing and Diffie-Hellman key derivation for the
pairwise mode. Not really a common practice, need to be proven secure. Point
raised by Ben Kaduk

https://mailarchive.ietf.org/arch/msg/core/ujj_I-LlqW9fq__quh-YqKS0fF0/

MT: There's ongoing work by Ericsson to produce a proof that what we are doing
is secure, possibly with minor adaptation to the key derivation process. An
alternative would be to have and provide separate signature and DH keys (which
could be done in
https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/), but it
would mean more provisioning and storage overhead. We should have more on this
point in the next months.

GS: How is this draft related to the Group CoAP document
draft-ietf-core-groupcomm-bis ?

MT: They refer to each each other, and have to move forward together. The
original idea was to request publication for both of them together.

ED: About the mentioned proof. Are you waiting for this paper to be reviewed
before advancing this?

GS: There's a pre-print in progress; mainly putting things together, possibly
just a note on how proofs relate. It's probably sufficient that there is an
IETF review on it; I don't think the paper needs peer review for progress here.

MT: The plan for v -12 is to address the two open points above. That should be
a stable version, there are no other known issues.

## OSCORE Group Discovery (Christian) (10)

* draft-tiloca-core-oscore-discovery-08

   - Discuss updates and open points

CA: using the Resource Directory to discover links to an OSCORE group manager,
hence to discover OSCORE groups and how to join them.

CA: latest updates specify also information on the pairwise mode of Group
OSCORE; consider also the signature verifier as possible client; revise the
examples.

CA: Marco's implementation has been tested against Christian's RD, covering all
the steps defined in the draft.

https://bitbucket.org/marco-tiloca-sics/ace-java/src/master/src/test/java/se/sics/ace/interopGroupOSCORE/CoAPEndpointToResourceDirectory.java

coap://rd.coap.amsuess.com

CA: Next steps are about elaborating security considerations; aligning certain
RD aspects to what added in the last version of the RD document; integrating
the individually implemented steps into the actual joining node and Group
Manager. Then we need reviews.

No questions.

## Multicast Notifications (Christian) (10)

* draft-tiloca-core-observe-multicast-notifications-05

   - Discuss updates and open points
   - Ready for adoption ?

CA: This enables a server to send multicast notifications to a group of
clients. Possible to also use Group OSCORE. The server sends a phantom
observation request to itself; observe notifications are responses to that
request.

CA: recently added a new encoding for informative error responses to the
clients; a new encoding for expressing addressing information in the
informative responses; optimization for a server self-managing its OSCORE group
and for having the phantom request as a deterministic request
(https://datatracker.ietf.org/doc/draft-amsuess-core-cachable-oscore/).

CA: Next steps include considering also reverse proxies and deterministic
requests used together with proxies.

ED: Intention with appendices, examples or normative?

CA: Implementation guidance, no need for normative additions. Appendix C
specifies a simple way to manage a group.

GS: What is the state of the content, are all components in place?

CA: Yes.

CB: Is this work the WG wants to take on?

+13 on adopting, no objections.

Reviews? Esko, Göran would review.

Planned implementations? Christian, Marco (the authors)

CB: Would be good to have non-author implementor to ensure it's implementable
if you haven't invented it.

CB: Energy is there, outside implementors are no prerequisite. Sounds like
in-room consensus.

## Groupcomm proxy (Esko) (10)

* draft-tiloca-core-groupcomm-proxy-03

   - Discuss updates and open points

Esko presenting.

ED: Signaling protocols with two new CoAP options, to enable proxies in group
communication.

ED: The encoding of server's addressing information conveyed in one of the
options is also aligned with the format from
https://datatracker.ietf.org/doc/draft-tiloca-core-observe-multicast-notifications/

ED: Now added also support for reverse proxies (with two examples).

ED: For when OSCORE is used between client and proxy, together with Group
OSCORE between client and servers, we have simplified the high-level
characterization of options to be protected as class E between client and proxy.

GS: Can it be solved with two separate OSCORE connections?

MT: Group OSCORE between client and servers is one thing. Then the proxy needs
to verify authenticity of client, before forwarding at all. That requires a
separate secure association between client and proxy, which leads to OSCORE in
OSCORE.

ED: And OSCORE in OSCORE is actually forbidden. This would require proper
definition, analysis and update of RFC 8613. Better to move out from this
appendix and rather to a separate document?

GS: Supporting separate document.

CA: Supporting separate document.

JM: As to why this is forbidden now, we were worried about collisions of
identifiers. Nothing that can't be addressed.

CA: Pretty sure it won't come to that because transport information differs.

GS: It's also interesting to consider a chain of proxies, i.e. whether this
results in more than two OSCORE layers applied to a message, or in just two
layers with the outer one replaced at each hop.

ED: Next steps are about addressing the points raised today and covering the
case where client and cross-proxy talk HTTP. Earlier promised reviews:
Christian and Carsten.

## Cacheable OSCORE (Christian) (10)

* draft-amsuess-core-cachable-oscore-01

   - Discuss updates and open points

CA: Enabling caching of OSCORE-protected responses; all group members can act
as a deterministic client with a well-known Sender ID and Sender Key. The exact
encryption key is derived for each different request. The key derivation
process is similar to the one in the pairwise mode of Group OSCORE; will have
to consider the feedback from Göran about it. Overall, you safely trade some
security properties with enabling cacheability. This also improves the way
things work in
https://datatracker.ietf.org/doc/draft-tiloca-core-observe-multicast-notifications/

CA: During the hackathon, Marco and I interoped and came to decrypt each
others' deterministic requests. Finding from the hackathon improved some design
aspects, already in the editor's copy.

CA: Next steps would be about more interop, process the feedback and then go
for a proper review with security in mind.

ED: For deterministic request it is not possible to determine the order, but
for the server responses?

CA: Yes, but you cannot determine that the response is later than the request
(by design, since the intent is to reuse cached responses)

## OSCORE with EDHOC (Rikard) (10)

* draft-palombini-core-oscore-edhoc-02

   - Discuss updates and open points
   - Ready for adoption ?

RH: Combined last EDHOC message to establish an OSCORE context together with
the first request protected with that OSCORE context.

RH: Based on feedback also from implementors, converged to a single approach
based on a new EDHOC option (zero-length). Proposed option number 13 to keep
the overall option size 1 byte; number 21 would also work fine.

CA (on jabber): if option number 21 also works, pick 21. Another future
protocol might make a better use of 13.

RH: Further optimization, i.e. only part of the EDHOC message goes on the wire,
while the rest can be reconstructed by the server, saving at least 2-4 bytes.

RH: Keep in synch with the main EDHOC document; something specific of CoAP and
OSCORE may better fit in this document.

ED: Recap, what's the purpose of EDHOC?

RH: Establishing keys for OSCORE in a secure way. This optimization just
reduces the round trips around the last EDHOC message.

JM and CA (in jabber): +1 on (calling for) adoption.

Adoption call: +9, one "not raise hand" (ED explaining: not against, but not
sure either), no opposition. In-room consensus, to be taken to the list.

## AEAD limits in OSCORE (Rikard/John) (10 + 10)

* draft-hoeglund-core-oscore-key-limits-00

   - Present new work

RH: This considers the AEAD cipher limits defined in
https://datatracker.ietf.org/doc/draft-irtf-cfrg-aead-limits/ , and defines
additional actions for OSCORE (so updating RFC 8613). Need to count key usages
and renew the OSCORE context of the two peers when a limit is passed. One limit
'q' is about performed encryptions with a key, while 'v' is about failed
decryptions using a key. Plan to cover more algorithms than CCM_8 and give
optimizations for constrained devices and implementation guidelines.

* https://mailarchive.ietf.org/arch/msg/core/h5JHgX5wTBkJtrKl_ezswiCdUBI/

   - Broader discussion on the topic

JM: What the draft has described is important to happen in OSCORE. Renewing the
security context might also be useful to do for other reasons like for
counteracting key compromise, especially if the rekeying provides perfect
forward secrecy.

JM: The original procedure used to compute the limit considers arbitrary
assumptions that yield the actual limits now considered in the draft. It's also
unfair to some particular algorithms. It would be good to have an overall
revision of that procedure. OSCORE in particular may possibly consider a same
value 2^20 for the two limits and a smaller block size of 2^8 rather than 2^10.

MT: So the possible revision of the procedure is not something for the
presented draft.

JM: No, it belongs somewhere else. The presented draft can still end up with
recommending the right limits to use, with some short explanations.

***Meeting closed at 18:07 UTC***

---

*[MT]: Marco Tiloca
*[JJ]: Jaime Jiménez
*[GS]: Göran Selander
*[JM]: John Mattsson
*[FP]: Francesca Palombini
*[CG]: Cenk Gündogan
*[CB]: Carsten Bormann
*[CA]: Christian Amsüss
*[KH]: Klaus Hartke
*[BS]: Bill Silverajan
*[NW]: Niklas Widell
*[IP]: Ivaylo Petrov
*[MR]: Michael Richardson
*[BL]: Barry Leiba
*[AK]: Ari Keränen
*[JS]: Jon Shallow
*[MB]: Mohamed Boucadair
*[AS]: Alan Soloway
*[BL]: Barry Leiba
*[MG]: Matthew Gillmore
*[ED]: Esko Dijk
*[HB]: Henk Birkholz
*[MG]: Matthew Gillmore
*[DN]: David Navarro
*[CG]: Carles Gomez
*[MK]: Markku Kojo
*[HT]: Hannes Tschofenig
*[BK]: Benjamin Kaduk
*[AM]: Alexey Melnikov
*[RH]: Rikard Höglund