# 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