Minutes interim-2021-core-04: Wed 16:00
minutes-interim-2021-core-04-202104281600-00

# CoRE Virtual interim - 2021-04-28 - 14:00 UTC

Chairs:

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

## Remote instructions

material: https://datatracker.ietf.org/meeting/interim-2021-core-04/session/core
webex: https://ietf.webex.com/ietf/j.php?MTID=m888a990760425271a1327f53c6714b07
jabber: core@jabber.ietf.org
codimd: https://codimd.ietf.org/notes-ietf-interim-2021-core-04-core?both

Minute takers: Esko Dijk, Marco (helping)
Jabber scribes:

## Participants

1. Marco Tiloca
2. Rikard Höglund
3. Francesca Palombini
4. Scott Rose
5. Esko Dijk
6. Carsten Bormann, TZI
7. Peter Yee, AKAYLA
8. Alan Soloway
9. Göran Selander
10. John Preuss Mattsson
11. Klaus Hartke
12. Michael Koster
13. Michael Richardson
14. Dave Robin
15. Oliver Borchert

*[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
*[JM]: John Mattsson

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

### Bluesheets / Jabber & Minutes / Agenda bashing

Fill the "Participants" list and other info above.

### AEAD limits and key usage
  * Background
     - https://datatracker.ietf.org/doc/draft-irtf-cfrg-aead-limits/
     - https://mailarchive.ietf.org/arch/msg/core/h5JHgX5wTBkJtrKl_ezswiCdUBI/

JM: John presenting slides (from the SAAG presentation at IETF 110)
*
https://datatracker.ietf.org/meeting/110/materials/slides-110-saag-analysis-of-usage-limits-of-aead-algorithms-00.pdf

JM: Need a process to come up with the values for the limit; start from the
ones in TLS, relax some of them in CoRE, others should become stricter.

JM: Possibly no limits for the ChaCha algorithm.

JM: 'l' and the limit for 'q' can be reduced; the limit for 'v' can be
increased with CCM.

GS: What's the practical aspect of multi-key?

JM: in literature, it is single user = single key. In practice it doesn't
matter who owns the key(s).

JM: (slide 10) completely different conclusion than for the TLS analysis. CCM_8
very close to ideal 64-bit MAC.

CB: this is an online attack scenario?

JM: Yes

JM: (slide 11) CCM_8 is perfect MAC for IoT. We can use a much higher 'v' value
for CCM_8, for (OS)CoRE. If we stay in the shown range it will be very secure.

RH: we can lower the 'q' limit?

JM: the TLS process that was used makes no sense. Probabilities used in those
formulas are not so useful except for forgery attack case.

GS: this would all go into security considerations in Rikard's draft?

RH: Yes. We need to use some probability values.

JM: No, prefer not doing probability values. Use 'security level'. Deriving the
limits from the formulas as currently done (TLS) is arbitrary/flawed. The
inequalities could still be used to calculate security level. But not worth the
effort to do this. Don't spend much time on it. We improve on TLS security.

RH: ok we pick lower value for ... and motivate this.

JM: e.g. pick value 2^20 for 'q' and 'v' limits, for both algorithms.

MT: about raising the value 'v', how can we motivate it has been raised enough?

JM: (slide 10) see right graph, up to 2^35 at least is ok.

RH: check also what the effect is of lowering 'l'.

JM: again, we shouldn't spend much time on it; already did that enough.
 Note that TLS assumes in the analysis that all messages are max length. (Not
 so in practice.)

JM: will do a Pull Request for draft-hoeglund-core-oscore-key-limits to give
input. Use numbers suggested on slide 11 as a start.

RH/MT: can start a mail thread on the list for these numbers.

JM: yes, can get input from others e.g. Christian also.

### Key usage limits in OSCORE
  * https://datatracker.ietf.org/doc/draft-hoeglund-core-oscore-key-limits/

Presented slides:
  *
  https://www.ietf.org/staging/slides-interim-2021-core-04-sessa-aead-key-usage-limits-in-oscore-core-20210428-ss1213.pdf

(RH: presents the slides.)

RH: starting from the CFRG approach, to come up with limits for 'q' and 'v'
considered for rekeying. Mentioned existing methods for rekeying.

RH: some updates in the editor's copy: covered more algorithms; added the LwM2M
re-bootstrapping as a way to rekey; 'v' is not incremented in case of replays;
added an 'exp' parameter to the security context as expiration time.

(slide 6)
JM: should clarify the lifetime of a context vs lifetime of a key.

RH: if supporting Appendix B.1 of OSCORE, convenient to do a similar regular
storage of count_q and count_v. Need considerations on storing rates vs.
rekeying rates.

JM: is storing the numbers the only solution, or is rekey-on-reboot also ok?

RH: yes, that's also fine - rekey if I lose the sequence number, or on reboot.

CB: so the counts saved are a limit on what numbers can be re-used? Can use a
clock and apply a linear formula / line instead; no need to store anything in
reboot scenarios - as long as you can rely on the local clock. Only do "store"
operation if the count goes beyond the linear line. RFC8613 scheme can be
extended for this.

JM: we should allow many different implementations on this; what's presented is
one way. (Can include those in an appendix). These are suggestions for
implementations to stay in the limits.

CB: the only reason to show this in the draft is to make people aware it can be
done like this; and to avoid patents on such methods.

RH: agree

(CB: clarifies the proposed method. Application has to make sure it stays on
the safe side of the line before reboot; then no saving needed.)

RH: thanks everyone for the feedback.

RH: (slide 7 - only writing here additions to the content) on 3rd point,
understood from JM that probabilities p_q / p_v aren't needed.

JM: two important aspects -
   1) how do the different limits affect applications;
   2) how do we do (light-weight) rekeying with or without SSN reset, keep
   forward secrecy.

RH: draft describes rekeying methods, are there more?

GS: we said before we should write another draft to list the key update / rekey
methods.

JM: could include in the same draft; why do we need a new one?

RH: it does describe the current methods for rekeying. More updates could be
done to these.

GS: JM are you saying that such new draft would be closely linked to (update
of) the current draft?

RH: putting the methods in the current draft is an option. Based on current
Appendix B.2

MT: any strong opinion on single document vs separate documents for covering a
new lightweight rekeying method? (None heard)

RH: (slide 10) more details on possible optimization to not store 'count_q'; it
relies on the SSN, by overestimating 'count_q' and possibly requiring rekeying
more often. GS: is this from client point of view? RH: Yes, but it actually
works both ways for requests and responses.

RH: (slide 11) this could work for both client/server. X is the estimate of the
other party's SSN.  It may be overestimating count_q.

JM: how large is the overestimation (worst case)?

RH: the highest is 2x overestimation of actual 'count_q'.

GS: so this corresponds to one 'power' so estimate is 2^21 instead of actual
2^20 count_q ?

RH: Yes.

MT: In summary

* We can build on John's new numbers with supporting security considerations
and there will be a mailing list thread to discuss more.

* Approaches building on Appendix B.1 of OSCORE can be further expanded on
storage optimization here.

* More details on light-weight rekeying procedures can actually be here rather
than in a separate document as originally planned (point (2) above).

* Have to discuss limits for applications. (point (1) above)

JM: can we use 2^23 for all applications? Do we consider values 2^20,21,22,23
for applications? This has no security relevance, it's for applications and
their preferences/needs.

JM: (Discussion also on the 'l' value, 2^8 blocks or 2^9 blocks); it could also
sum up length of all messages and use that for l size, but that's probably not
suitable.

### AOB