Minutes IETF109: core: Tue 12:00
minutes-109-core-202011171200-01

# IETF 109 - 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)

# TUESDAY, November 17, 2020

Number of participants: @05:05 UTC 41, @06:15 UTC 47, @06:45 UTC 46

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

Minute takers: Christian, Francesca, Marco (helping)

Jabber scribe: Marco and Jaime

**05:00 - 07:00 UTC**

Numbers in parentheses are minutes of time allocated.

## Intro, agenda, status (10)

Jaime doing introductions, IPR policies, note-well, agenda etc.

* WG and document status

* IESG Processing:
    * draft-ietf-core-resource-directory-26: IESG Evaluation::AD Followup
    * draft-ietf-core-stateless-07: IESG Evaluation::AD Followup

* In Post-WGLC processing:
    * draft-ietf-core-dev-urn-08: AD Evaluation::AD Followup
    * draft-ietf-core-echo-request-tag-11: AD Evaluation::AD Followup
    * draft-ietf-core-comi-10: under shepherd write-up
    * draft-ietf-core-sid-14: under shepherd write-up
    * draft-ietf-core-yang-cbor-13: under shepherd write-up
    * draft-ietf-core-yang-library-02: under shepherd write-up
    * draft-ietf-core-oscore-groupcomm-10: processed WGLC comments

## Resource Directory (Christian) (10)

* draft-ietf-core-resource-directory-26

   - Processed IESG review; remaining open points

Presenting update following IESG review - highlights.

Open points:
* DTLS replay protection should be considered -> #291 in github
* How much can you trust links from the RD? -> would like more discussion
outside of RD doc * Ambiguity on reading link format usage from RFC 6690,
especially related to the 'Anchor' parameter; usage on the wire to be relaxed.
* -27 will come in December addressing three remaining points.

BL: Remember to followup on a point from Ben Kaduk.

GS: Can you elaborate more on verifying what the client really intended to do?

CA: (goes through slide)

GS: What to do about it?

CA: For the application to differentiate between what is a hint and what is a
statement that is necessary to come from a trusted source.

FP: On the possibilities to explore, are they alternatives?

CA: Yes, they may be possible to combine, not part of the RD document itself.
They can land on the work on CoRAL.

MG: Could you rely on link layer security?

CA: Link Layer security won't get you to origin server so it won't get any
better security on the statement.

## Stateless (Michael Richardson) (10)

* draft-ietf-core-stateless-07

   - Discuss updates and open points

Stuck on review comments since May; several marked as WONTFIX.

Automatic Key Management issues: Precise key doesn't matter, as long as it's
resisting a fast attacker. Replay window size needs to be considered carefully.
Attacker can still replay seen tokens.

-08 just uploaded, DISCUSS just cleared. One more cycle may or may not be
necessary.

BL: Let me know when you think it's ready to go, I'll give a final check.

MR: I think -08 is ready to go. Could have one word here or there, but minor
editorial and nothing DISCUSS worthy.

BL: Will send out.

JJ: Klaus's positive comments this morning from issue tracker?

MR: Have not seen them yet. Will check.

JJ: Any last comments?

## Groupcomm-bis (Esko) (10)

* draft-ietf-core-groupcomm-bis-02

   - Discuss updates

Obsoleting RFC 7390 towards a standards track, now that there is a possible
security mode.

-02 updates:
* Server may respond from different UDP port
* Response suppression based on code class
* Group definition (CoAP, application, security), added best practice
* FETCH, also with Observe and block-wise

Next steps:
* Handling multiple responses from same server in the application
* Cachability of responses, validity of caches
* Pending reviews (Christian, Francesca)
* Implementation tests for more exotic features

CB: Wouldn't be nice if we could send etags for all responses in cache?

ED: We are thinking about it

CA: We had a discussion at the hackathon about that. It would work. Only, the
client wouldn't know if servers have collisions with each others' ETAGs.

CB: You would have to include server identifications together with the etags,
which is why it becomes big and ugly.

CA: The client might send a request in a very small block size.

ED: Short message back, or first small block.

## Group OSCORE (Marco) (15)

* draft-ietf-core-oscore-groupcomm-10

   - Discuss updates following WGLC

Updates in -10: addressing WGLC and later comments.

Interop during hackathon with 3 implementations, including pairwise mode.

Algorithm and key parameters updated.

5.03 can be returned by the server as "I Don't Have A Recipient Context Right
Now, come back soon".

Non-Recycling policies in GM: "Never ever reassign sender ID", based on latest
review to be relaxed, see later. Group ID to never ever be re-assigned to the
same group.

Single SSN space shared for both group mode and pairwise mode; SSN reset to 0
when a new context is established. Helps in understanding change of key
material. Own SSN needed to use for the server, when answering a request across
key changes (i.e. response protected with a context different than the one used
to protect the request).

request_kid_context added to external_aad to allow observations across key
changes, while still ensuring a notification cryptographically matches with
only one observation request.

Observations: Client and server store original Group ID of the observation
across rekeyings, if intended to survive key changes. The client additionally
stores the invariant group identifier ("group name" in ACE documents).

From latest review:
* distinction between replay and freshness requirements, and related
"synchronization" terminology.

* Appendix E to be updated from the surrounding discussions, E.1 and E.2
already follow from a correct implementation and can be removed.

* Loss of recipient context can happen due to server memory limitations.
    * Following an overflow of recipient contexts, new ones start with an
    invalid replay window. If the server cares about replays, it has to run an
    Echo exchange (getting also freshness) or be rekeyed. (To be clarified in
    next version)

* Relaxing non-recycling: "never ever" -> KIDs grow in size irreversibly. Relax
to limit non-reusage only under a same GID -- can we?
    * GS: How do you make sure you actually only recycle when you've changed
    GID? * MT: It's under control of the GM, all managed there. * GS: So it's
    assigned from GM, OK. * ED: Group ID value, will that ever change? * MT:
    GID changes when key material changes, which happens when the GM decides
    that. * ED: Sounds safe to me.

* Converging on single external_aad format for both encryption and signing?
Before adding 'request_kid_context', the encryption version mirrored the
structure in OSCORE, now it's not the case anymore. So now we're deviating from
OSCORE anyway, then maybe use single format for both?
    * GS: Sounds reasonable, but need to look at details.

* algorithms field: There's redundancy between parameters from algorithm and of
keys. Trivial for implementation, but should we do this?
    * CA: Align with COSE.

* par_countersign: Can we generalize this for possible future algorithms to be
admitted into COSE, which may have any number of capabilities. Currently,
that'd still be what we have already hardcoded in the document.
    * ED: backward compatible or changes?
    * MT: Yes, just more flexible for possible future algorithms.
    * ED: So the definition is then future-ready. Sounds good.

## OSCORE Group Discovery (Christian) (10)

* draft-tiloca-core-oscore-discovery-07

   - Discuss updates and open points

CA presenting recap, updates from -07
* registration GM->RD and discovery of OSCORE groups node->RD
* names of application groups specified when creating the sec group, that makes
the GM aware of them when registering the security groups in the RD * multiple
sec groups can be retrieved from a same app group, guidelines are given, more
details are in draft-ietf-core-groupcomm-bis

next steps: more updates and reviews needed

ED: is this an optional thing (link of application to sec group)?
CA: someone needs to provide that information to the client. That someone needs
to get all information from the GM. In principle this does not need to be done
by the GM but it seems like the logical choice.

JJ: doesn't seem to be only tailored to OSCORE.
CA: The retrieval of the link to the Authorization Server in slide 5 can be
used more generically. Hope it gets picked up in ACE. JJ: Do we need to
coordinate with ACE? MT: Several meetings ago it was mentioned as a
possibility, with no hurry.

GS: What do you want to be picked up by ACE?
CA: The link relation between security group (link to join it) and the
Authorization Server (link to get the token to join the group).

CB: Most important is to have the right security considerations. Clients that
rely on this info retrieved in this way have to go through the right steps to
validate it.

CA: In the current way ACE works: the client contacts resource server, gets
back an unprotected response with that same link to the AS (just not in link
format) and acts back on that.

FP: About ACE, I would say this would be a different document for ACE.

GS: There is time in the ACE agenda tomorrow, so why not present it there?

CA: Yes, will talk to the ACE chairs.

CB: As to an Authorization Server relationship with the client - how do you
validate the server in the first place? Right now a client has to know all this
information or it has to have a secret relationship with a Group Manager which
has this validated information.

CB: The ace-actors document has been on hold, maybe resurrect and complete this
now. Trust anchors are great, but whether trust anchors provide the right
information, that requires more info.

CA: sounds like I have to spend more time with Ace.

CB: Maybe this is what we need IoT-OPS for. ACE stuck in OAuth path [?], need
more comprehensive view of authorization flows. Onboarding discussion is a good
source of information here; had that in T2TRG, and if IoT-OPS takes off, that
may be good focal point.

JJ: any meeting for IOTOPS?

HB: No. Timing issue.

ED: advertising iotops mailing list from Jabber

## Multicast Notifications (Christian) (15)

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

   - Discuss updates and open points

Presenting what, why, how and updates.
- encoding of informative response (transport-dependent and transport-specific
information, flexible for non-UDP tranport); - improved rough counting of
clients, building on feedback from Carsten - given support for proxies, need
some more fix also in the examples

Open points:
* Proxy examples need more work
* negotiation for client supporting this or not
* last notification in the informative response to become optional?
* add an appendix about how a server could be its own GM

JJ: I have it on the todo list to do a review of this one. Urgency?

CA: No. Important to make sure we converge on the understanding of the basic
principles, which have not changed for a while now.

ED: intention the server becomes the GM for its own group? Advantage?

CA: Yes. that group would only be used between that server and that client. No
larger audience than the audience of the server itself. This might be kind of a
shortcut option.

FP: Adoption?

JJ: I understand Christian wants one more round.

CA: Not necessarily, if we have rough consensus on the basic approach. Work is
needed on the details.

FP: For information, I am also authoring, I think it should move forward.

MT: Speaking as author, I agree with my co-authors.

JJ: Counting on Meetecho for interest in adoption:
- 12 say "Raise your hand"
- 1 says "Do not raise your hand"

Potential reviewers are Göran, Jaime and Carsten.
Other volunteers: Esko, Thomas

## Groupcomm proxy (Esko) (15)

* draft-tiloca-core-groupcomm-proxy-02

   - Discuss updates and open points

This specifies how proxying can be done towards groups: the client sends
unicast, the proxy translates that to multicast, then forwards back responses.

Client indicates capability to handle responses, and its listening timeout,
using a Multicast-Signaling option. Proxy includes Response-Forwarding option,
so the client can distinguish the individual responses and the servers
originating them.

Group OSCORE possible between client servers; any security between client and
proxy.

-02 updates: clarifications on support for notifications, updated security
considerations,  semantics and usage of the new CoAP options, chaining of
proxies.

C->P option: Multicast-Signaling indicating response-forwarding time interval
to the proxy. New: can be 0 (send request, don't forward responses), which
should be paired with the No-Response option. Issues? (none raised)

P->C option: Response-Forwarding indicating network address. Helps client
contact the server either through proxy or directly. This now has the servers'
addressing information as address+port, rather than a URI which would have been
more flexible for DNS resolution. OK anyway? (no objections).

Proxy chaining: Next hop configured except on last proxy in the chain. If
there's a long chain a proxies, a proxy may not determine a feasible timeout
value to pass on that would work. In that case, return 5.05 to the previous
hop, including the minimum timout acceptable time value in a
Multicast-Signaling option.

OSCORE between client and proxy can coexist with group OSCORE between client
and servers. In the client-proxy leg, this means protecting some options as
class E, rather than as class U as usual. We list some of those options. Can we
have a future-proof general rule to identify these Class-U-to-E options? Shown
a proposal; good enough? anything simpler?

CA: it should be ok to apply that simply to all options that the proxy needs to
understand and process.

Next steps: enable HTTP-to-CaAP cross proxying; this would enable HTTP clients
to talk to a group of CoAP servers.

We need reviews, some promised at IETF 108 from Christian, Carsten and
Francesca.

## OSCORE with EDHOC (Francesca) (10)

* draft-palombini-core-oscore-edhoc-01

   - Discuss updates and open points

Postponed to the Friday session.

## Flextime (15)

Σ 120

---

*[MT]: Marco Tiloca
*[JJ]: Jaime Jiménez
*[GS]: Göran Selander
*[JM]: John Mattsson
*[FP]: Francesca Palombini
*[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
*[BS]: Bill Silverajan
*[AS]: Alan Soloway
*[BL]: Barry Leiba
*[MG]: Matthew Gillmore
*[ED]: Esko Dijk
*[HB]: Henk Birkholz