# CoRE Virtual interim - 2021-02-18 - 15:00 UTC Chairs: * Marco Tiloca, RISE * Jaime Jiménez, Ericsson ## Remote instructions material: https://datatracker.ietf.org/meeting/interim-2021-core-03/session/core webex: https://ietf.webex.com/ietf/j.php?MTID=mb6a8494e161c079941cba71c5c26a212 jabber: core@jabber.ietf.org codimd: https://codimd.ietf.org/notes-ietf-interim-2021-core-03-core?both Minute takers: Marco Jabber scribes: Marco ## Participants 1. Marco Tiloca, RISE 2. Rikard Höglund, RISE 3. Peter Yee, AKAYLA 4. Göran Selander, Ericsson 5. Christian Amsüss 6. Carsten Bormann, TZI (late) *[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 *[MR]: Michael Richardson *[MB]: Mohamed Boucadair *[JS]: Jon Shallow ## 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. ### Limits of key usage for OSCORE (Rikard) Background: * https://datatracker.ietf.org/meeting/109/materials/slides-109-core-sessb-ietf-109-core-aead-limits-oscore-00 * https://mailarchive.ietf.org/arch/msg/core/bbzZCt6ZZn4ysR7yLujPNscBF3g/ Curent background draft: https://datatracker.ietf.org/doc/draft-irtf-cfrg-aead-limits/ Presented slides: * https://datatracker.ietf.org/meeting/interim-2021-core-03/materials/slides-interim-2021-core-03-sessa-limits-of-aead-key-usage-for-oscore-00.pdf Rikard Presenting slides Problem early raised at the IETF 109 meeting; related to too many usages of a same key in OSCORE, beyond which the security would break. You need to count the number of key usage, separately: * 'q': use for encryptions with the Sender Key * 'v': failed decryptions with the Recipient Key A CFRG draft gives formula to compute the limits, for AES-CCM and other algorithms (now an adopted draft) - https://datatracker.ietf.org/doc/draft-irtf-cfrg-aead-limits/ To compute the actual limits, one also needs to assume exact value for two attack probabilities, p_q and p_v; for now, the same values considered in DTLS 1.3 are considered. From this, limits for 'q' and 'v' to use in OSCORE can be computed for the MTI algorithm AES-CCM-16-64-128. GS: something on this is considered also in LAKE; the assumptions on the two probabilites are pretty arbitrary. MT: more for coordination among CoRE and LAKE Discussing open points. CA: on regularly storing 'q' like in OSCORE Appendix B.1, check also if the two parties can help each other so that only q-half can be stored. MT: Most of responses don't consume a Sender Sequence Number, but still the server uses its Sender Key to encrypt the response. CA: But a request has at most one non-notification response associated. That can practically make you store less. MT: if the limits are really something "related to the algorithm" (rather than to OSCORE), they can be part of the algorithm registration; something possibly for COSE (like the deterministicity feature). Safe to NOT increment 'v' if the message is discarded as a replay? Christian and Göran agree it is safe. Next steps: new document soon submitted to CoRE defining the limits, how to track them and what to do with what you have today. GS: People in LAKE may help nailing down the right numbers to consider. CA: DTLS has an 8-byte tag value, it has up to 2^7 failed decryptions if the same MTI algorithm of OSCORE is used. ### AOB MT: interim meetings will resume on the second half of April, meaning six interim meetings before IETF 111; plan to move back to every other Wednesdays at 16:00 CET / 16:00 CEST (same time of today), as it used to be. No objections from attendees. CB: Plan to handle the agenda conflict at IETF 110? MT: All security-related topics will be on Monday, to avoid the conflict with DANISH on Friday. Even so, agenda simulations suggest that all fits. CB: Can you ping Ivo about the COMI document requiring a revision? MT: Yes, will do. CA: now processing last items on the Resource Directory about 'anchor' and frehsness; good to have a look at those from Esko and Göran respectively. Plan to submit a revision before the cut-off.