Minutes interim-2021-core-12: Wed 16:00
minutes-interim-2021-core-12-202110131600-00
Meeting Minutes | Constrained RESTful Environments (core) WG | |
---|---|---|
Date and time | 2021-10-13 14:00 | |
Title | Minutes interim-2021-core-12: Wed 16:00 | |
State | Active | |
Other versions | plain text | |
Last updated | 2021-10-13 |
minutes-interim-2021-core-12-202110131600-00
# CoRE Virtual interim - 2021-10-13 - 14:00 UTC Chairs: * Marco Tiloca, RISE * Jaime Jiménez, Ericsson ## Remote instructions Material: https://datatracker.ietf.org/meeting/interim-2021-core-12/session/core Meetecho: https://meetings.conf.meetecho.com/interim/?short=3cedb9b5-b3ec-4685-ab43-5bff97c4b642 Jabber: core@jabber.ietf.org Notes: https://notes.ietf.org/notes-ietf-interim-2021-core-12-core?both Minute takers: Christian, Jaime Jiménez, Marco Tiloca Jabber scribes: Marco Tiloca ## Agenda ### Note Well Remember that the [note well](https://datatracker.ietf.org/submit/note-well/) applies, for [IPR](https://tools.ietf.org/html/bcp79) but also for [WG processes](https://tools.ietf.org/html/bcp25) and [code of conduct](https://tools.ietf.org/html/bcp54). Try to be nice. ### Jabber & Minutes / Agenda bashing ### Document status (15 min) * echo-request-tag approved for publication * https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/ Which is also good news for documents in the cluster 280 (including resource-directory and new-block from CoRE) !! :trophy: * senml-data-ct * https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/ * Presented slides: https://datatracker.ietf.org/meeting/interim-2021-core-12/materials/slides-interim-2021-core-12-sessa-senml-data-ct-last-round-00.pdf CB presenting senml-data-ct (see slides) issues: * Different ABNF now in httpbis for parameters in media-type. Should we have to allow legacy expressions like HTTP chose to? (Agreement from CA, AK) * internal structure in parameter value: We don't allow quoted pairs right now. Parameters coming in containing double quotes or backslashes, we need to allow quoted pairs. Should we leave out the obsolete stuff (obs-text) but allow quoted pairs? (It's substantive change, but I think we need this to avoid surprises). AK (via chat) pointing out application/cose;cose-type="cose-encrypt0". CB: cose-type is parameter name, value is a quoted string, that we can do today already. What we can't do right now is embedded double quotes in there. AK: So like application/cose; cose-type="cose-\"encrypt\"0" CB: Not hearing opposition; as AK said "we don't want to deviate from substance, only legacy baggage" (AK, CA agreeing via chat to go ahead) * error handling: SenML documents may live long enough that producer doesn't know consumer (because it's consumed in the future). Thus use "must be understood" when needed. Here we don't know yet whether recipient will know any of the details (numbers, parameters, content codings). Recipient knows when it needs to be updated. Would be editorial change highlighting this. (AK via chat agreeing with doing as proposed) CB: Plan is to have a new version in a few days, then BK and Murray can clear their discusses, FP can approve if all good. FP agreeing on chat. (AK on chat says: And we could consider later on updating SenML RFC with guidance on error handling in general, but don't think there's much -ct specific.) * CORECONF documents * https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ * https://datatracker.ietf.org/doc/draft-ietf-core-sid/ Ongoing design team meetings, latest last week, one planned for Monday next week. MCR: Several issues were opened. Hope to have bulk of work done before cut-off. Please comment on Github if you have any stake in it. CB: Lots of things going on in the issues, which essentially boil down to answering the DISCUSSes. ### CoRAL (20 min) https://datatracker.ietf.org/doc/draft-ietf-core-coral/ Presented slides: https://datatracker.ietf.org/meeting/interim-2021-core-12/materials/slides-interim-2021-core-12-sessa-constrained-restful-application-languager-coral-01.pdf CA presenting: * (slide 2) On last status update: * Information model merged to the main Editor's copy. * Handling literals. Either each literal is an item of its own vs literal value and its attributes as a single entity. Latter easer. * (slide 3) new things: Packed CBOR, CBOR diagnostic notation (thus file is human-readable), mapping with link-format and CoRAL with RDF. * CoRAL should convey information the device can directly act upon. We can't just define link-format to coral conversion and expect 1to1 conversion. Link-format may have other items that are not expressed in coral, and applications using those would break. * (slide 4) Sample link-format mapping * ct is numeric, interfaces are split up into semantic relations that have meaning on their own. * (slide 5) some of the current issues * #5 deterministic encoding. Section probably a remnant from when CRIs where part of main spec. * #10 lock in the "property" model of literals * #9 do without circular visitation * #3 open/close world AK (via chat): are there examples of the CoRAL CBOR diag format vs the original text format? CA: I've none right available but can pick up some. \[ CA scribbling the example \] ``` #using rdf = <http://www.w3.org/1999/02/22-rdf-syntax-ns#> #using foaf = <http://xmlns.com/foaf/0.1/> foaf:maker null { rdf:type <http://xmlns.com/foaf/0.1/Person> foaf:familyName "Hartke" foaf:givenName "Klaus" foaf:mbox <mailto:klaus.hartke@ericsson.com> } ``` ``` [2, 6(101), null [ [2, 6(33), cri'http://xmlns.com/foaf/0.1/Person'], [2, 6(102), "Hartke"], [2, 6(103), "Klaus"], [2, 6(104), cri'mailto:klaus.hartke@ericsson.com'], ]] ``` ### Key update for OSCORE (20 min) https://datatracker.ietf.org/doc/draft-hoeglund-core-oscore-key-limits/ Presented slides: https://datatracker.ietf.org/meeting/interim-2021-core-12/materials/slides-interim-2021-core-12-sessa-key-update-for-oscore-00.pdf RH presenting: * (slide 2) Recap. Key usage needs to follow certain limits due to AEAD. Therefore draft has 2 parts: there is (1) a study on AEAD, its limits and how an endpoint tracks it's approaching them; and (2) a new method for rekeying OSCORE. * (from slide 3) On key limits * Limits needed to be set to stay within good security levels expressed as probabilities. Computed using the CFRG formulas, building on recommendation from John Mattsson. * Clarified how to practically not exceed the limited on message size. CA: Would be easier to just express that in terms of bytes, to not think of cipher blocks. * It was fine to have a higher 'l' limit for most ciphers, it's still safe enough, according to a "bound" probability from CFRG. Maybe some limits can be increased even more. * Different story for CCM_8, limits have to be lower to stay around good proabilities. Found a good set of limits to practically recommend, still following the overall CFRG direction. Good, or fine to deviate? CA: Probably the 'l' limit does not matter so much for us, given the possibility of inner blockwise limiting to 1 KB and outer blockwise bringing more limits. That should releave the pressure from having the best 'l' limit since this is all very specific to OSCORE anyway. * (from slide 6) On actual key update * Recap of the procedure and its properties * In the client-initiated version, removed a nonce R1 from the server's response as not really needed * Clarifications on the server-initiated version; checkings on the server aligned to OSCORE Appendix B.2; more of this to add * Size of exchanged nonces as 8 bytes like in OSCORE Appendix B.2. Ok? CA: Might be good, but some devices may keep it shorter if sure of no reuse. Similar to what raised in the Echo-Request-Tag document. * Now observations have to terminate after a key update. There's a way to let me safely continue, but the price to pay does not look worth it. * Aligned with new exporter interface of EDHOC if this was used to originally establish the Security Context. This implies a MUST support of that interface if EDHOC is used (it's a SHOULD support in the EDHOC draft). * This key update can replace the use of OSCORE Appendix B.2 in 6TiSCH, with additional convenience, since it does not change the Context ID which is used as node (pledge) identifier in 6TiSCH. * This would "deprecate and replace" OSCORE Appendix B.2 in RFC 8613. Ok? * Do we need a name for this procedure? CB (via chat): Names are good CA (via chat): yeah name it RH: KUDOS was something we internally thought about GS (via chat): this key update is preferred to Appendix B.2 in all aspects, I think. ### DNS over CoAP (20 min) https://datatracker.ietf.org/doc/draft-lenders-dns-over-coap/ Presented slides: https://datatracker.ietf.org/meeting/interim-2021-core-12/materials/slides-interim-2021-core-12-sessa-dns-queries-over-coap-doc-00.pdf ML: DNS is not encrypted, clearly risky if used by IoT devices. Big traditional security solutions don't fit constrained environments. Advantage over DNS-over-DTLS: Can share resources (socket, buffer, retransmission mechanism) ML: Basic encapsulation process at the moment. Use CON messages, thought of GET/POST/FETCH as possible methods. Defined new content format. ML: How to indicate a response as non out-of-date? Max-Age option? 1. Minimum TTL for Max-Age; 2. adopt Max-Age to TTL; 3. new "Age" option like HTTP (maybe hard to sell here). ML: Comparison of the different CoAP methods. POST not caching-friendly, GET cannot have payload. FETCH looks great, but maybe not widely deployed yet. Then compromising use of GET/POST in Appendix. ML: Investigation on implementations with FETCH. Most support it. FETCH is trivial to implement, shouldn't be too generous with implementations still not supporting FETCH. CB: We really might want to use FETCH at this point as the right thing. Completely favorable in abandoning GET/POST as alternative for legacy applications. CA (via chat): Agreed. ML: Authentication method proposed in this group can be used. MCR (via chat): I think this should happen in DNSOP, with review from CoRE. CB: That's a good point, with things to discuss here as well. MW (via chat): To be clear, the draft is not only about DNS queries MCR (via chat): DNS started on UDP. Then all this moved to DTLS/UDP, then TLS/HTTPS, now DNS over QUIC... and here we show up with DNS over CoAP (which is over UDP). MCR: Will be bizarre for the DNS group why we are not doing DNS over QUIC or UDP. Scoping why the current solutions are not valid will be key. CB: +1 CB: what would be the expectation on progress? MT: resubmission before cutoff? ML: If we decide that GET/POST should go out, maybe. We were planning to have the topic done asap, not to spend years on this. MW: Done soonish if possible. RIOT has an implementation. What would be the expectation of the update? Is it the scope a justification of why not DNS+DTLS? CB: It would be good to spend a couple of sentences elaborating. No epic text on that. Just mention URIs, proxies, encryption, etc. MW: Then before cutoff possible. CB: Looking for MvP (Minimal viable Protocol) ML: POST removed or appendix? CB: No appendix - No confusion. ### New charter text (10 min) * https://notes.ietf.org/BkpQ-gttSRuVKlEgxho5gw?both * https://github.com/core-wg/core-wg.github.io/blob/master/core-charter.txt * https://github.com/core-wg/core-wg.github.io/commit/133861a92ef62a2130427521455fb58bce23aa3e?branch=133861a92ef62a2130427521455fb58bce23aa3e&diff=split GS: I read the proposed new charter, it's a bit long. Rechartering is good as there are things out of date and that can come back to us. GS: The first proposal is 3 page long and up-to-date. I took out content from its second half about ongoing/planned activities, that I tried to structure as bullet list. This is a starting point. MT: Have to share for everyone to see and edit. CB: Main issue is that this exposes explicitly the work. FP: thanks Göran! Still looking for the WG opinion on this, we have your point of view. CB, I wonder if your view of being cautious has changed or not. Anybody else has opinions? MT: Hope that more input and opinions come. CB: Would like to do a PR on Github. There is a danger people wake up to the size of our plate. In this respect, the already long ongoing charter might actually help. CB: Worst that could happen is that we do not recharter. If ask for rechartering and it's not approved, what's the possible consequence? FP: That might result in even closer looking than now when documents are submitted for publication. So we need to be sure and in agreement on the content when doing that. MT: Will make Göran text available on the same CodiMD (see above) and Github repo as a PR. Please, give your comments and input there or on the thread we already have for this on the mailing list. --- *[MT]: Marco Tiloca *[JJ]: Jaime Jiménez *[FP]: Francesca Palombini *[CB]: Carsten Bormann *[CA]: Christian Amsüss *[KH]: Klaus Hartke *[RH]: Rikard Höglund *[TF]: Thomas Fossati *[DN]: David Navarro *[GS]: Göran Selander *[BS]: Bilhanan Silverajan *[AS]: Alan Soloway *[MCR]: Michael Richardson *[AK]: Ari Keränen *[MJK]: Michael Koster *[JM]: John Mattsson *[NW]: Niklas Widell *[ED]: Esko Dijk *[EB]: Henk Birkholz *[ST]: Sean Turner *[ML]: Martine Lenders *[MW]: Matthias Wählisch