# 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