# WEDNESDAY, April 08, 2020 13:00-15:00 UTC Note takers: Francesca, Amelia, Marco, Jaime Jabber scribe: Jaime, Marco Queue manager: Jaime, Marco Numbers in parentheses are minutes of time allocated. ## Intro (10) 13:00 Note well presented. Agenda reviewed (no objections). Introducing Marco as new chair. Welcome Marco, thank you Carsten! New AD: Barry. New: interims every other week. Time will be 14:00UTC and meeting docs will available at core-wg.github.io * WG and document status * Published: * multipart-ct-04: RFC 8710 !! * hop-limit-07: RFC 8768 !! * RFC-Editor's Queue: * draft-ietf-core-senml-etch-07 * draft-ietf-core-senml-more-units-06 * IESG Processing: * draft-ietf-core-resource-directory-24: In Last Call * draft-ietf-core-stateless-05: In Last Call * In Post-WGLC processing: * draft-ietf-core-echo-request-tag-09 * WGLC to be issued: * draft-ietf-core-dev-urn-04 ## CoRECONF cluster (Ivaylo) (15) 13:18 * draft-ietf-core-yang-cbor-12 --- Ivaylo * draft-ietf-core-yang-library-01 --- Ivaylo * draft-ietf-core-comi-09 --- Ivaylo * draft-ietf-core-sid-12 --- Ivaylo Objectives: - Outcome of WGLC, possible discussion on relevant issues * draft-ietf-core-sid-12 --- Ivaylo All remarks are still not processed. Carsten Bormann (CB): the intention is that we are doing the same thing we would be doing in the early allocation process. Is that correct representation? Ivaylo: yes CB: then we probably need a little bit of text because the early allocation is aimed at IESG and DE does not operate exactly how IESG does. Need text for that. Esko: You don't need an early allocation anymore because you get a quick allocation now. CB: Bug or feature? Early allocations are reviewed after a year and go away if nothing happens. Provisional allocations would be very quick and get back them back if nothing happens, which is different than permanent. Esko: OK, I see the intention. CB: SIDs aren't quite as scarce as other things we're seeing in allocation. Was just trying to explain what we gain by having an early allocation process. Ivaylo: Let's continue discussion on mailing list. Jaime: continue the discussion in the mailing list, pretty mature and no major things. Ivaylo: yes. * draft-ietf-core-yang-cbor-12 --- Ivaylo Do we want to have normative references from CBOR to SID or the other way around? Jaime: You have to submit another version of this document regardless. Do people have opinions on normative references? Ivaylo: Yes. CB: I have very strong opinions on normative references. In the past normative references that were not necessary caused big delays to our work. Since YANG-CBOR is a free-standing document, even if it sits on YANG, it doesn't need all the other machinery that we are creating. Let's try to process with a minimal amount of normative references, keeping in mind that the document should be free-standing in the sense that someone who just wants to use YANG-CBOR can do that without referencing other docs. Jaime: did you reply to Tom Petch for the feedback he gave for this? Ivaylo: I might have missed it? Jaime: let's make sure all comments are adressed in next resubmission. * draft-ietf-core-comi-09 --- Ivaylo It is not clear whether Security Considerations really need to very extensive, or whether a more general observation is acceptable that authorization requires care. No further discussion. * draft-ietf-core-yang-library-01 --- Ivaylo Jaime: Actually the comment from Tom Petch was here, not on CBOR. Do you have a time-line for resubmissions? Ivaylo: Will probably have all the editorial changes by tomorrow or end of the week. The other changes depend on the level of detail required to solve concerns. The SID-draft may take longer time to work out than the others. We are hopeful it will not be a big delay. Jaime: Bear in mind to send the latest versions to other potential reviewers who may be interested. We will do another WGLC when the new documents are submitted. ## Groupcomm (Marco, Christian, Esko) (60) 13:44 * draft-ietf-core-groupcomm-bis-00 (10) --- Esko Objectives: - Discuss updates (addressed reviews and closed TBDs) - Discuss open points (handling different group types, reusage of tokens for observation, explicit signaling of multicast messages) - Ask for reviews Esko: intended to obsolete RFC 7390, updating RFC 7252 and 7641; insecure and secure (with Group OSCORE) communication are in scope Esko: Taken care of Jim's and Thomas's reviews, improved definitions, discussed group discovery with the RD, improved security considerations Esko: Distinction between CoAP/OSCORE/Application groups, they use different types of identifiers, example figure Esko: open issue #1 on Github, the port number may change in the server response compared to the port number of the multicast request, discussed on the list Esko: open issues #26 and #35 on Gitlab, on using URI-Host for identifying application group and for consistency requirements for suppression of responses Esko: Next steps are working on the open issues and process last review comments. Test selected functions in CoAP implementations. Jaime: issue 35 what is that? Esko: a non WG-adopted draft issue, see https://gitlab.com/crimson84/draft-groupcomm-bis/issues. Jaime: reviews by Thomas and Jim, sufficient or more reviews needed? Esko: Always good with more reviews. Maybe next update. Jaime: Any volunteers to review current or next version? Please indicate in chats on Webex or jabber. Christian Amsuess , Jim and Thomas Fossati volunteer for next version. * draft-ietf-core-oscore-groupcomm-08 (15) --- Marco 13:55 Objectives: - Discuss updates (addressed review, sec con, optimized and pairwise mode) - Discuss open points (support for pairwise mode, Sender ID for silent servers, remove IANA registries from signature+key params, appendix E.2 on client sequence number) - Ask for reviews Marco: We hope to do more testing of message protection, and then to go to WGLC Jim: number of issues. sl.10. Basenline sync, it should be optional to discard the first baseline request. If you do pairwise: problem with EdDSA MTI since both montgomery and edwards implementation would have to be MTI in HW. Christian: E2 appendix: careful to differentiate between application's freshness requirements and requirements for reusing the sequence number. Jim: draft in LWIG that talks about EdDSA with a mapped coordinates where you can do both key agreement and signing, which could become the MTI -- https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/ Francesca: there is a discussion in the mailing list on making this document update OSCORE. : There's a requirement of HMAC-based HKDFs in OSCORE, which may not really be necessary. Could have sentence in Group OSCORE about "Any [H?]KDF is fine"; is doing it in this document the best option? Want to do it fast, but if it's in this document there'll be an "Updates" link that gives the wrong impression of Group OSCORE being mandatory for OSCORE now. Jim (on Jabber): I have succesfully done the multicast + observe as well Jaime: If anyone wants to review, say now. Christian (on jabber): raises his hand for reviewing the next version of groupcomm * draft-tiloca-core-oscore-discovery-05 (10) --- Christian 14:16 Objectives: - Discuss updates (addressed review, registration of link to AS, examples in CoRAL) - Discuss open points (no re-introduction of group member registration --- BACnet example) - Solicit reviews Christian: just deployed nodes may miss information on how to join an OSCORE group through the Group Manager (GM). Then we use the CoRE Resource Directory (RD), it works even if the GM is not deployed yet. Christian: addressed Jim's review, added to the link to the group also the link to the ACE Authorization Server associated to the GM. This spares the client from an unouthorized access just to learn of the AS. Christian: clarified relation between application and security groups (but still to finalize across documents) Christian: Examples added also in CoRAL, the link to the AS cannot be formally "navigated", it's metadata. Christian: we have a long example from BACnet, where devices start from scratch. Right now the RD is not expressing nodes' membership to a group, but this example is doing that out of the blue. It's just an example though. Better to just pull that part of the example out or can confuse, can be defined just in a separate document. Christian: we got 1 of the promised reviews, we would need more. Jaime: on the first example, that's a registration? Christian: yes, it would look very similar in a look up Jaime: on the payload? Christian: on the payload the GM announces one of its join resource, to join one of its OSCORE groups? Jaime: in the payload the group and the token to register with? Christian: the AS. Jaime: volunteers to review. Jim volunteers on Jabber. * draft-tiloca-core-observe-multicast-notifications-02 (15) --- Christian 14:26 Objectives: - Discuss updates (congestion control, error response encoding, observation cancellation, alternative retrieval of phantom request) - Discuss open points (rough client counting, alternative encoding) - Ask for reviews Christian: allow the distribution of resource updates over multicast, to a lot of subscribers all observing the same resource on the server. Aligns well with pubsub. Christian: the group of clients as a whole "controls" the multicast IP address and the Token value used for all the multicast notifications. Christian This starts from a common "phantom request" as sent *from* the multicast IP address of the group. The server creates it and sends it to itself. Then it's serialized and sent to the clients to align them, as included in an error response to the clients as they come to try observing. Christian: added discussion on congestion control, more explicit encoding of phantom request and other information inside the error response to the clients Christian: described alternatives to retrieve the phantom request in different ways, e.g. pub-sub when discovering a topic, or introspection during network debugging by querying the server Jaime: related to Thomas's error response draft. are you aware of that draft? Christian: yes, not exactly the same problem but may be possibly considered. Jaime: do you have CBOR or CoRAL examples? Christian: now mainly in CBOR, pointing that they can well be also in CoRAL. Thomas: the last "problem draft" is also mainly in CBOR. Jaime: sounds like an interesting topic for an interim. We need to schedule a discussion for later on, on the connection between different documents: draft-fossati-core-coap-problem, draft-core-coap-pubsub and this draft draft-tiloca-core-observe-multicast-notifications. Christian: then it's about how the server can cancel a group observation. We propose a CoAP option that the server can use to communicate and update its own estimation of the group size. If the updated count falls below a threshold, the server can cancel the group observation. Carsten: you may make a probabilistic estimation on the group head. Christian: isn't this what we are doing? Carsten: you may send a sense to select a small subgroup to send a response. You need to maintain a group size estimate at the group head. Based on that, you can choose the size of the head. Christian: pretty much what we are doing, we just describe it based on random events to fall within a range. Carsten: that's good. Christian: we want to spend more time thinking about alternative serializations inside the error response, possibly with more serialization of content intended to go on the wire. Jim (on jabber): It will be interesting to try and implement this when the details are more nailed down. Jaime: I have no additional comments. If no one else has any comments maybe we can move on. We will have to move some stuff until Thursday. * draft-tiloca-core-groupcomm-proxy-00 (10) --- Esko 14:44 Objectives: - Present new work - Christian's comments on the list - Ask for reviews Esko: handling a request from a client, to go through a proxy and forwarded over multicast to multiple servers Esko: we condsider an approach where the responses from the different servers are sent back to the client individually (no aggregation). Group OSCORE is used for security. Esko: the client uses one new CoAP option to indicate to the proxy it is fine with all this. Each server uses a second new CoAP option, to indicate its own IP address all the way to the original client. Esko: presenting the two new options and their properties. Esko: presenting the workflow, client --> proxy (which identifies the client, set a timer for how long to wait for responses, observation is handled) --> server --> proxy --> client (that can retrieve the address of each of the servers from their response). Esko: got a review from Christian, we have open points as to an alternative use of the two options and their properties; it seems also a use case opening for "nested OSCORE" between client and proxy Esko: main next steps are about addressing open points and Christian's review. Jim: this seems to assume there is no address mapping involved, if the server provides its address but it's behind a NAT Marco: the alternative approach suggested by christian would address this. Esko: If the proxy is also the nat, the client can reach the proxy then through the proxy it can access the devices even if the addresses are changed. Christian: the client has to find out anyway in some way that that particular address is usable. It's premature to think of this particular interactions. Addresses that come back even from a proxy will make sense. Jaime: We don't have any time for further presentations so we will have to move them to the next session. Thank you all for your time! Hope to see you next Thursday at the same time. Σ 120