# IETF 109 - 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, November 20, 2020 Number of participants: @09:07 UTC 55, @10:16 UTC 58, @10:49 UTC 55 Meeting material: https://datatracker.ietf.org/meeting/109/session/core Minute takers: Michael Richardson, Göran Selander and Marco (helping) Jabber scribe: Marco **09:00 - 11:00 UTC** Numbers in parentheses are minutes of time allocated. ## Intro, agenda (5) Some documents have move forward yesterday. - stateless was approved by IESG, and entered the RFC-EDITOR Queue. - dev-urn entered LAST CALL - echo-request-tag entered LAST CALL ## OSCORE with EDHOC (Francesca) (10) * draft-palombini-core-oscore-edhoc-01 JM: Should probably not use the last remaining flag bit of the first flag byte. Better to save that for other stuff that are sent in every message. -> Agreed, do not use last flag bit. -> prefer to register a new CoAP option. [Minute taker Göran's comment: I think the conclusion above is wrong. John's comment was that to not use the last flag bit of the first flag byte, but a flag bit in the second flag byte.] CB: will the new option really be one byte? FP: the option will be empty. CA: yes, if the delta is less then 13 from the previous CoAP option. FP: both alternatives require an IANA registration, either for a flag bit in the OSCORE option, or for a new CoAP option. CB: Let's grab the option number. GS: Stefan Hristozov planned to implement, we should check with him about status and his preference. Discussion about how to get a CoAP option number through IANA, it can be an early registration through the WG chairs; to be taken to the list. CA (on Jabber): CoAP option numbers in that range are "IETF Review or IESG Approval", which is what Early Allocation works for JM (on Jabber): Having it in a new EDHOC option makes it clearer that this includes EDHOC, without digging into the OSCORE option. FP: There seems to be a preference for specifying an EDHOC option. ## SenML Versions (Carsten) (5) * draft-ietf-core-senml-versions-01 CB: Minor edits in the latest -01; waiting for reviews (promised from Bill and Jaime), before moving to WGLC. Are there any implementations? AK: I have implemented it, seems to be working. MG: If you are not using version, what is your solution? MR: the actual problem is using NUMBERS (monotonically incrementing integers), not versions per se, this sets bits AM (on Jabber): every bit is a feature (used if set) AM: I did review earlier versions, looks sensible BS: I commit again to review in the next days. JM (on Jabber): Version numbers vs. bitfield remind me of discussion of negotiating cipher suites vs. negotiating individual algorithms in IPsec/TLS. Benefits/disadvantages with both. For many applications the best solution might be a combination of the two approches. ## SenML Data CT (Carsten) (10) * draft-ietf-core-senml-data-ct-02 CB: Since IETF 108, WGLC happened, then comments followed. Plan to integrate the comments, then ship to the IESG. MG: Question about the use case that the draft addresses. CB: Indicate a content format when binary data are sent in SenML, using a new CT field. MG: Ok. AM: Does the referenced draft (draft-bormann-core-media-content-type-format) need to be DISPATCHed? If I remember correctly, the referenced draft doesn't belong to EMAILCORE or CORE BL: It's certainly not in scope for EMAILCORE. AM: And it's very generic for CoRE. BL: So, yes, take it to DISPATCH. AM: I volunteer to shepherd it. CB: Can we submit this to the IESG with the reference dangling? It happens often. BL: No particular opinion on it. If a normative reference is not ready, the RFC Editor holds on anyway. We're good as long as a referred document is available for people that reviews. CB: It would be good if the referenced draft was adopted before IESG submission of this data-ct document AM (in Jabber): Barry could potentially AD-sponsor the referenced draft. ## New Block (Jon) (15) * draft-ietf-core-new-block-02 JS: Naming of block, poll resulted in "Q-Block", but may not work globally MR, CA, IM: preference for "Tough Block" MB, JJ, MG: preference for "Q-Block" Tie between "Q-Block" and "Tough Block". Authors prefer "Q-Block", so WG decided on that. Discussion on whether we can tolerate the ack timeout? JJ: More reviewers? Christian Amsüss volunteers JS: Will soon submit -03 (minor change), then we would target WGLC. MR: What security is required? Can it be used with OSCORE? CA (in Jabber): Will be covered in my review MR (in Jabber): OSCORE does not validate the originating IPaddress, I think. JM (in Jabber): TLS, DTLS and ESP does not validate IP address either, you need AH for that. MR (in Jabber): If I see (offpath possibly) a valid OSCORE + Q-Block request, I can change the IP address and send it again. ## Dynlink (Bill) (10) * draft-ietf-core-dynlink-11 BS: The epmin and epmax parameters are included in the editor's copy. Open issues on allowing pmin == pmax - Impact on current wording in the draft; related suggestions for OMA. AM (in Jabber): it is reasonable to allow this Latest OMA specification: http://www.openmobilealliance.org/release/LightweightM2M/V1_2-20201110-A/ Another open issue is about the new "edge" attribute CA: How does this work with a proxy? Another open issue is about the new "con" attribute, about sending notifications on confirmable transports. What does confirmable mean exactly? - DN: If CoAP over UDP, use CON messages. - CA: This works for origin servers, but it does not work for proxies. Assume you set up an observation. If CON attribute is set, the proxy needs to decide on how to send the notification on. You can request the server to do this, but you can't expect it to work along the whole end-to-end chain of nodes. - JJ: This applies also to other attributes. This is the time for the WG to discuss this. - HT: In LwM2M there are no proxies. - CA: If you want this to work with REST, then you have to assume the existence of proxies. This is the scope of CoRE. - JJ: Need to set up an interim meeting to discuss this. BS: Please comment on the Github issues. There will be discussions also at coming interims, focus on end-to-end and hop-by-hop. ## Fasor (Markku) (10) * draft-ietf-core-fasor-01 MK: Status and next steps, need reviews and feedback also from the transport area, WGLC would be a target after integrating those comments. CG: Important work. Do you have a plan for further evaluation of this mechanism? MK: Currently no plans. We have emulated characteristics. More tests are welcome. JJ: Reviewers? Needed to progress the draft. We'll check with the chairs of the transport area for possible reviewers there. CG: I can review within ~2 months ## CoAP over GATT (Christian) (15) * draft-amsuess-core-coap-over-gatt-01 CA: Discuss updates. Is this a good work to do? JM (in Jabber): Making sure that CoAP can be used in more environments/platforms is a good thing. BLE is popular. Experimental seems correct. CB: +1 AM: Experimental sounds good at the moment. JJ: (in Jabber): back on the scheme discussion: coaps+tcp:// coaps+bluetooth:// , etc. MG: Why is this not done in 6lo? CB: 6lo is IP over foo. This is not IP. MR: How is bluetooth authenticated? CA: Opportunistic authentication in Bluetooth. Rely on higher layer end-to-end security. MG: If it is not IP, why in the IETF? MR/CB: Because CoAP is in the IETF. CB: Comparable to https://tools.ietf.org/html/draft-bormann-t2trg-slipmux-03 AM (from Jabber): GATT specific new COAP URI scheme might need detailed examination. This was rather contentious in the past. CB: Good stuff ## Rekeying for OSCORE and AEAD limits (John) (20) * https://mailarchive.ietf.org/arch/msg/core/bbzZCt6ZZn4ysR7yLujPNscBF3g/ JM: Discuss the issue; maximum encryptions or maximum failed decryptions (modeled as 'q' and 'v') before needing to rekey; rekeying in OSCORE or with EDHOC JM: We may need something lightweight with the right properties; something similar will be needed in Group OSCORE too JM: Plan to have a new draft discussing the problem according to the two parameters q and v, and what more is needed. BK (on Jabber): I don't think we had a huge amount of justification for the 2**(-60) and 2**(-57) bounds in TLS, FWIW BK: I think "might not close the connection and might send an error message saying please rekey" is not strictly keeping with the theory behind these limits. Perhaps if you only send it once and then close the connection it is close enough CB (on Jabber): The main reason why we never switched away from CCM is that it is much less brittle, or in today's parlance, it is moderately misuse-resistant. Since more misuse-resistant modes are coming up, there might be a time to reconsider. JM (on Jabber): I think sending an error message without verifying the ciphertext would not give the attacker any more information. Verifying without using the plaintext would give the attacker some additional information. In GCM the attacker would get quite a lot of information regarding the authentication key but it would not matter. In CCM the attacker gets very little information as shown in the multi-forgery paper by mcgrew et al. GS: We need to go also through what is used today (CCM_8) and find ways to handle it. CB (on Jabber): Sure MR (on Jabber): Yes, we need to talk about EDHOC+DTLS/OSCORE/CCM_8-rekey as a group. MG: Any group in mind that can provide feedback? GS: For instance industry groups that use CCM_8, which is MTI for CoAP This is material for future interim meetings. Σ 120 --- *[MT]: Marco Tiloca *[JJ]: Jaime Jiménez *[GS]: Göran Selander *[JM]: John Mattsson *[FP]: Francesca Palombini *[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 Gilmore *[MB]: Mohamed Boucadair *[DN]: David Navarro *[CG]: Carles Gomez *[MK]: Markku Kojo *[HT]: Hannes Tschofenig *[BK]: Benjamin Kaduk *[AM]: Alexey Melnikov