[core] CoRE @ IETF 108 - Minutes and summary

[Marco Tiloca <[e-mail]>]

Dear all,

The minutes for the two CoRE sessions are available at [1]. Thanks to
the fantastic note takers Niklas, Ivaylo, Francesca and Michael!

Please, send possible fixes and updates to [e-mail] or to
the mailing list, preferably within the next 7 days.

The recordings of the two CoRE sessions are now available at [2][3].

Finally, you can find below the usual summary of the two sessions, with
fewer technical details. This summary together with the raw minutes is
also available at [4].

Thank you all for your participation and contribution. Have a great
continuation of summer!

Best,
Marco and Jaime

[1] https://datatracker.ietf.org/meeting/108/session/core
[2] https://www.youtube.com/watch?v=rBmhQ_IkDQc
[3] https://www.youtube.com/watch?v=vli7kn7YoiU
[4]
https://github.com/core-wg/wg-materials/blob/master/ietf108/core-108-summary.md

----------

# Summary

## WG and document status
  * Published:
    * senml-more-units-06: RFC 8798 !!
    * senml-etch-07: RFC 8790 !!

  * In IESG Processing:
    * draft-ietf-core-resource-directory-25: IESG Evaluation
    * draft-ietf-core-stateless-06: IESG Evaluation::Revised I-D Needed.
A few comments remaining, Klaus is processing them.

  * In Post-WGLC processing:
    * draft-ietf-core-dev-urn-07: AD Evaluation::Revised I-D Needed.
After some discussion, publication was requested as Standards Track.
    * draft-ietf-core-echo-request-tag-10: On Shepherd's Writeup (Marco).
    * draft-ietf-core-oscore-groupcomm-09: WGLC finished last week now
comments to be processed.
   
  * In WGLC:
    * draft-ietf-core-comi-10
    * draft-ietf-core-sid-14
    * draft-ietf-core-yang-cbor-13
    * draft-ietf-core-yang-library-02

    The WGLC ended on July 29. Carsten will proceed with shepherding the
documents on mid-August.

## Echo-Request-Tag

* draft-ietf-core-echo-request-tag-10

   This latest versions addresses comments post WGLC, related updates
have been presented, concerning both the Echo and Request-Tag option, as
well as other document improvements. Ongoing shepherd writeup, plan to
request for publication soon after this meeting.
  
   No comment from shepherding, the write up will be written up next
week, then request for publication.
  
## Resource Directory

* draft-ietf-core-resource-directory-25

This latest version addresses review comments and adds especially
security considerations, related to security policies and to the use of
Echo for amplification mitigation and client identity in simple
registrations.

There have been a few interims, some about authorization and use of RD.
Not found anything that could be applied to the RD today, bu we will
continue with the current state and ship it. There are some ongoing
discussions about authentication/authorization with the RD, but they are
outside the scope of this current specification.

## CoRE Applications

* draft-ietf-core-problem-details-01

Updates were presented and open points discussed. Plan to work on Girhub
issues for following revisions. Everyone is free to join the draft repo
https://github.com/core-wg/core-problem-details and provide input.

From this version, it's just about CoRAL. Discussed how identifiers
should be compact, with a low entry barrier. Ongoing research for
different approaches to ID schemes. Naming things in a distributed way
is one of the two hard problems in computer science. Looking for a way
that works well for Problem Types and CoRAL in general. Ideas and
suggestions are welcome. Need also to address when a registrant goes away.

## Dynlink
   
* draft-ietf-core-dynlink-11

Presented updates and planned way forward. Most recent updates
incorporated feedback and added small changes. A small group of people
has been working on small set of features.

Open points are about: observed notifications to reflect restful state
change; behavior of pmax in the presence of proxies; possible support
for epmin/epmax already used by LwM2M (discussion in Github issue #18).

There is one IPR disclosure from Qualcomm, on the current draft not
containing epmin/epmax. To keep in mind for future discussions.

Next step is to reflect editorial changes and state transfers. Plan to
continue discussion in small discussion group, synchronize with Bill if
interested to be invited. Meetings over Jitsi. This topic will be also
covere in interims after summer.

## SenML Documents

* draft-ietf-core-senml-versions-00

Summarized concept of versions signaling as set of features, through a
bit array. This doc is also used by RFC 8798 (senml-more-units). It
should be ready for WGLC, more reviews would be appropriate. Feature
deprecation is hard to predict, but it shouldn't be a problem.

People who will review: Bill, Jaime.

* draft-ietf-core-senml-data-ct-02
   
Indicate the Content-Format of the binary data in the SenML record, so
that it can be interpreted correctly. This version removes the
must-understand ct_ until a way to use is found. The document will go on
a 2-week WGLC.

## Blockwise for DOTS

* draft-bosh-core-new-block-04

DOTS creates challenges where there are DDoS attacks and needs
mitigation, which is problematic in lossy environments given the large
body packets. Proposed two new CoAP options for blockwise transfer,
Block3 & Block4 akin to Block1 & Block2.

BLOCK3 can send packets without waiting for response, and introduces
congestion control to avoid DDoS. GET and FETCH with BLOCK4 trigger
BLOCK4 responses provided that the response is big enough.

Need for possible better clarification of the document scope, while it
claims already that this is not a generic solution, but rather specific
to the DOTS use case.

The draft discussed at two interim meeting. This latest version
incorporates all received comments. The authors request adoption as a WG
document. Assessed support for adoption to be confirmed on the mailing
start. A call for adoption will start.

Christian will provide a review.

## AIF

* draft-bormann-core-ace-aif-09

This work was originally for both CoRE and ACE, now ACE has picked it up
by ACE, but it is also interesting for CoRE.

AIF models access control as a control matrix, with subject and set of
permissions. Protection of capabilities is not in scope.  The capability
list is an array of pairs, it takes RESTful case as starting point, but
other cases can be specified (e.g. MQTT). Objects are paths, while
permissions are expressed as bitmaps. This is good for most
applications. Good for static resources, but dynamic action resources
can also be around, for which permissions are derived from the base
resources, by doubling the bits.

First version in 2014, now in WG adoption in ACE. Ben Kaduk asked if
there is anything else like this. Most web services have more
complicated needs, so AIF is probably too simple. On the other hand,
when done, this might be used elsewhere, so we should not block such uses.

The AIF pattern is very similar to IPSO (CRUD instead of REST). It's
worth writing up for CRUD so a new set of registration bits is not
needed every time.

A possible extension can provide also dynamic permissions; model the
difference between resources that have been created or could have been
created by a subject; model time aspects such as the lifetime of an
Access Token vs. the lifetime of the resource (e.g. pub-sub topic). This
may intersect with identity management.

## EDHOC+OSCORE

* draft-palombini-core-oscore-edhoc-00

Based on a discussion started at IETF 106, this new work proposes
different approches to combine an execution of EDHOC with the first
OSCORE exchange following it. The different approaches can also be
signaled in different ways. Essentially, the EDHOC verification on the
client is merged with the first OSCORE request protected with the
derived security context. This optimization would reduce the overall
number of roundtrips. The goal is to select only one approach signaled
in one way.

Approach 1. EDHOC in OSCORE
    - Define new CoAP option indicating that message is both EDHOC and
OSCORE
   
Approach 2. EDHOC in OSCORE
    - Use the OSCORE option and a new flag bit to tell that the payload
contains both  

Approach 3. OSCORE in EDHOC
    - Define new CoAP option indicating that the message is both EDHOC
and OSCORE

Approach 4. OSCORE in EDHOC
    - Signal with new content format.

Approaches 1 and 2 seem preferred, with most preferences for Approach 2.
A short-enough EDHOC message can go in the option. Carsten and Klaus can
provide feedback on this point.
           
People who will review: Christian, Carsten, Jim.
           
## Group Communication

* draft-ietf-core-groupcomm-bis-01

Discussed current Github issues and other open points. Agreement
regarding port number in responses; criteria consistency for response
suppression; usage of URI-host for naming application groups; usage of
admin-local scope; rationale for mapping between security groups and
applications groups. Next version will focus on closing these open points.

People who have read this or a previous version: Jim, Christian, Francesca

People who will review: Carsten, Jim, Christian

* draft-ietf-core-oscore-groupcomm-09

This last versions addresses all open point raised at the April virtual
meeting.

More open points were discussed (mostly coming from the WGLC), requiring
more thinking:

    1. For the pairwise mode, it should be possible to signal the curve
used for the secret derivation, e.g. Montgomery or Weierstrass. It
should work to have it as additional information in the security
context. Then the same MTI as today can be kept.

    2. It's convenient to reset the SSN after group rekeying, which
becomes easier to detect.
   
    3. For observations, useful to store the Context ID of the original
request. This would prevent notification misbinding across group
rekeying if the SSN is reset. There may be further ways to look into.
   
    4. New proposal for separated PIV spaces, for the group mode and the
pairwise mode. Early discussion of pros/cons to be continued. Impact on
communication overhead, space synchronization with the Echo option, and
privacy implications. Some people expressed concerns.
   
People who have read: Jim, Christian

People who will read: Carsten

* draft-tiloca-core-oscore-discovery-06

The document defines a method to use the Resource Directory to find
links for joining OSCORE groups at their Group Manager (GM). Now it has
full support for Link Format or CoRAL. The Fairhair example was polished
and also translated to CoRAL.

The next version will address some open points, and align with other GM
administrative drafts.

A future document collecting all target attributes can include also the
ones defined in this document.

Possible interest can be discussed with Fairhair/BACnet and others.
T2TRG can be a good venue, with CoRE invited.

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

The document defines a method to send observe notifications to a set of
clients observing a same resource at the server, by using multicast
responses. This latest versions updates the encoding of the informative
error response to the clients; the mechanism for roughly counting the
active clients; and alternative ways to obtain the phantom request
associated to the group request.

Feedback would be needed on having optional or mandatory also the latest
notification sent inside the informative response. Next updates will be
about adapting the approach to work also with proxies.

People who will review: Jim, Göran, Jaime, Carsten

* draft-tiloca-core-groupcomm-proxy-01

The document defines a method to have proxies working in a group
communication setting. It addresses the issues in the groupcomm-bis
document. The proxy forwards back to the client the individual responses
from the servers. The client distinguishes the servers originating the
responses and learn their addresses. Two new CoAP options are defined.

An appendix describes "Nested OSCORE", to further protect with OSCORE
(client to proxy) the group request already protected with Group OSCORE
(client to servers). This allows the proxy to still identify the client
(as required), as an alternative to DTLS as a separate protocol on the
Client-Proxy leg.

Next steps will focus on chains of proxies and HTTP headers analogous to
the two new options, for cross-proxies.

People who have read or are interested: Jim, Christian, Carsten, Francesca

* draft-amsuess-core-cachable-oscore-00

The documents defines the concept of "Consensus Request", protected with
Group OSCORE but yet enabling proxies to serve cached responses to it.
Related paper: https://arxiv.org/pdf/2001.08023.pdf

A possible type is a "Ticket Request" generated by the server, of which
the phantom request used for multicast notifications is a particular case.

Another type is a "Deterministic Request", that all clients have to be
able to generate as a one and same request. It becomes tricky with
Partial IV and key to use. A possible way is proposed based on a
"Deterministic client". Some encryption algorithms might have to be
ruled out, none of them are in COSE.

Next version will give clarifications and more details.

Positive feedback on CoRE being the right venue and the importance of
the problem

People who will review an updated version: Francesca, Jaime

----------

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: [phone]
https://www.ri.se