Minutes IETF108: core: Fri 14:10
minutes-108-core-202007311410-02

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

# FRIDAY, July 31, 2020

Etherpad: https://codimd.ietf.org/notes-ietf-108-core

Minute takers: Michael Richardson, Francesca Palombini

Jabber scribe: Francesca Palombini

**14:10 - 15:50 UTC**

Numbers in parentheses are minutes of time allocated.

## Intro (5)

Trying to start on time.

## CoRECONF Documents (Ivaylo) (10)

* draft-ietf-core-comi-10
* draft-ietf-core-sid-14
* draft-ietf-core-yang-cbor-13
* draft-ietf-core-yang-library-02

   - Highlight from concluded WGLC, presenting the slides

"SID" -> "YANG SID", or "YSID"

Carsten Bormann (CB): I'm the shepherd and I am a bit behind, will do soon, and
will ping some people to answer WGLC. Jaime Jiménez (JJ): YANG validation
warning, for nits. Michael Richardson (MCR): have read the docs (not the last
iteration), not all of them.

JJ: Carsten do you have a timeline in time?
CB: I can do next week, but need to ping more people. Hopefully mid-august.
JJ: We'll keep an eye on the ml.

## Groupcomm Documents (Marco, Christian) (65)

* draft-ietf-core-groupcomm-bis-01 (10) --- Marco

   - Discuss updates, addressed reviews and open points

Any issues with \#1 (admit change of port number in responses) --- hearing none.
Any issues with \#2 (response suppression) --- hearing none.
Any issues with \#3 (URI-Host) --- CA says it is good to allow. CB +1

sl.7, point on admin-local scope:
JS: need to go back and look at the original message.

sl.7, mapping of app and sec groups: no objections to add text aligned with the
proposal in the slide.

JJ: Who has read this or a previous version: Jim, Christian, Francesca

Carsten, Jim, Christian volunteered to provide a review.

* draft-ietf-core-oscore-groupcomm-09 (15) --- Marco

   - Discuss updates and relevant open points from WGLC
\[14:38] (3 min behind schedule -- 17 min flex left)

sl. 6 poin 1
No objections to removing replicated info from the security context.

sl.6 point 2
Marco Tiloca (MT): add Wei25519 and ECDH25519 as hightlighted alternatives or
have them even as new MTI? Jim Schaad (JS): Don't have a preference. Lwig
people may have a preference. I don't know if there is a way to indicate the
choice of curve. MT: what we have now as MTI is safe and stable. Something else
will require more time for implementation and testing. JS: Doc needs to be
clear that's what it's doing. MT: Would it work to add this indication in the
security context while keeping the current MTI? JS: Yes. MT: will add some text.

sl.6 point 3
Christian Amsüss (CA): why are we talking about wrap around?
MT: we use exhaustion in the draft.
JS: might be a bad point, not what I was thinking about.

sl.7 point 1
JS: it can be useful in case the stored 'kid' has a relevant meaning only for
some particular 'kid context' value. MT: so it's a second layer of checking
when matching notifications with the original observation request. Ok we can
store it.

MCR: counter signature in COSE - change should not impact here, is that correct?
MT: yes, no impact, but we would have to point to the different document when
that happens. MCR: any preference? Also don't believe you need to point to a
new document. MT: we point now to struct-bis. MCR: Ok

sl.7 point 2
CA: wouldn't that mean that 2 requests could have same kid and same external
aad that the response could match to? This could endanger request response
binding. JS: reset of seq numb makes detection of key rollover easy. CA: if
client sends Obs req with the same seq numb both before after rekey, they would
share the same data in external aad JS: key context in ext aad? sl.6 point 3:
when it gets to the max value? MT: yes. JS: everytime I rekey I keep moving to
the max value MT: yes, until exhaustion. then get a new sender ID or rekey. JS:
How do I tell the difference between the 2 rekeys? MT: 1st case directly to the
node, second case to all nodes. JS: as the server, it might be difficult to
tell. that's why prefer to have ssn reset to 0. JS: Christian concerns will be
valid either way and we need to think them through. MT: So, if we reset SSN to
0 after rekeying, the two options seem to be either have also the stored kid
context of the observation request also in the external_aad, or kill
observations in case of rekeying. CA: Or a 3rd option: including the n of the
key generations in the external aad, but this requires more thinking through
pen and paper. MT: Ok to think more.

Sharing space of Sequence Numbers

CB: sequence number moving might be disclosing something.
MT: good point.
JS: might say that you respond, not how.

GS: might want to take a step back. The main point of pairwise mode was to
reduce overhead of the many responses, avoiding the signature. This would add
back some overhead, for the pairwise PIV to possibly add to responses. CA: at
least for code reuse and saving 1bit per message, separate SSN is not to follow
up. Also look up to CB point. CB: we should document the problem at least. MT:
we'll continue the discussion to assess pros and cons.

Who has read: Jim, Christian
Who will read: Carsten

* draft-tiloca-core-oscore-discovery-06 (10) --- Christian
\[15:07] (17 min behind schedule -- 3 min flex left)

   - Discuss updates, addressed reviews and open points
   - Ask for reviews

Method to use the Resource Directory to find links for joining OSCORE groups at
their Group Manager (GM). Now full support for Link Format or CoRAL. Polished
Fairhair example, also translated to CoRAL. Plan to address some open points,
align with other GM administrative drafts.

JJ: New link attributes defined in a new doc. This also has more, maybe we
should sync. CA: yes, fine to cover parameters to that new doc. JJ: maybe this
could just use CoRAL. JS: +1 in jabber about just using CoRAL. CA: something to
keep open considering also how CoRAL advances.

JJ: if there is interest for collaboration also with Fairhair/BACnet mentioned
in the example, T2TRG can be a good venue with CoRE invited. CA: to check with
Peter also about possible changes in the use case.

* draft-tiloca-core-observe-multicast-notifications-03 (10) --- Christian
 \[15:18] (18 min behind schedule -- 2 min flex left)

   - Discuss updates and open points
   - Ask for reviews

Method to send observe notifications to a set of clients observing a same
resource at the server, by using multicast responses. These are responses to a
phantom request that the server creates.

This latest versions updates the encoding of the informative error response to
the clients (including also the phantom request); the mechanism for roughly
counting the active clients; and alternative ways to obtain the phantom request
(e.g. as metadata of a pub-sub topic).

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.

GS: fantastic work.
CB: +1 (from jabber)

Jim Göran Jaime Carsten volunteered to review.

* draft-tiloca-core-groupcomm-proxy-01 (10) --- Marco
 \[15:29] (19 min behind schedule -- 1 min flex left)

   - Discuss updates, addressed reviews and open points
   - Ask for reviews

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

An appendix describes "Nested OSCORE", as a way to further protect with OSCORE
(client to proxy) the group request already protected with Group OSCORE (client
to servers). This is convenient to allow the proxy to still identify the client
(as required) while avoiding 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.

JJ: anybody interested or have read a version of the draft?
Jim, Christian, Carsten, Francesca

* draft-amsuess-core-cachable-oscore-00 (10) --- Christian
 \[15:39] (19 min behind schedule -- 1 min flex left)

   - Present the new work
   - Ask for reviews

This is proposing the concept of "Consensus Request", as protected with Group
OSCORE but yet enabling proxies to serve cached responses to it.

A possible type is a "Ticket Request" generated by the server, of which the
phantom request used for multicast notifications would be 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 when it comes to the
Partial IV and key to use. A possible way is proposed based on a "Deterministic
client".

Next version will give clarifications and more details. Is CoRE the right place
for this work?

Related paper: https://arxiv.org/pdf/2001.08023.pdf

FP: Yes CoRE is the place imo. Will read and review after update.
JS suggests in the that: on the second method, there is a class of encryption
algorithms for which it is not going to be doable. There was a discussion about
whether or not this constitutes nonce re-use.

JJ: Clarify about ticket request in the error response?
CA: That's how it would work with multicast notifications, and observations is
the only case where it make sense to consider that way. JJ: So probably a
normative reference to this doc would be required. CA: This is the strawman
proposal to get from one step to the other.

JJ: Will put this too in my bucket list of reading.

CB: Solving this problem would be great

JS: Can't use some encryption alg, because they use some randomness during the
encryption process CA: Are there criteria related to them, or columns in COSE
registries? JS: no such algorithms in COSE at the moment. There may be 1 or 2
in CFRG, will have to check them. We have to also avoid altogether another
class of algorithms that don't have any IV. CA: But then they're not usable
with OSCORE in the first place, right? JS: Right.

## Wrap up

JJ: interim in September, syncing up with other SDOs, WGs, etc...

Σ 100