Skip to main content

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

Meeting Minutes Constrained RESTful Environments (core) WG
Date and time 2021-02-18 15:00
Title Minutes interim-2021-core-03: Thu 16:00
State Active
Other versions plain text
Last updated 2021-02-18

# CoRE Virtual interim - 2021-02-18 - 15:00 UTC


* Marco Tiloca, RISE
* Jaime Jiménez, Ericsson

## Remote instructions


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](
applies, for [IPR]( but also for [WG
processes]( and [code of
conduct]( Try to be nice.

### Limits of key usage for OSCORE (Rikard)



Curent background draft:

Presented slides:


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)


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.