Minutes interim-2021-core-03: Thu 16:00
minutes-interim-2021-core-03-202102181600-00

# 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.