Minutes interim-2022-lake-01: Tue 18:00
minutes-interim-2022-lake-01-202201251800-00

# Lightweight Authenticated Key Exchange (LAKE) - Interim Meeting

## Tuesday, January 25, 2022 -- 17:00 - 18:00 UTC

## Present

* Mališa Vučinić
* Stephen Farrell
* Marco Tiloca
* Timothy Claeys
* Rikard Höglund
* Francisco Molina
* Göran Selander
* Ira McDonal
* John Mattsson
* Marek Sarefin
* Michael Richardson
* Rene Struik
* Sean Turner
* Uri Blumenthal
* Marek Serafin
* Carsten Bormann

### [Chairs](mailto:lake-chairs@ietf.org):

* Mališa Vučinić
* Stephen Farrell

### Useful Links:

* [Charter](https://datatracker.ietf.org/group/lake/about)
* [Mailing list](https://www.ietf.org/mailman/listinfo/Lake)
* [Jabber room](xmpp:lake@jabber.ietf.org)
* [Minutes](https://notes.ietf.org/notes-ietf-interim-2022-lake-01-lake)
*
[Webex](https://ietf.webex.com/ietf/j.php?MTID=m8ade28bd80c498144a134fb9818df388)

### Agenda:

* Administrivia and Agenda Bash
-- chairs, 5 mins
* Wrap up on MTI text
-- chairs, 5 mins
* draft-ietf-lake-edhoc
-- Göran Selander & John Mattsson, 30 mins
* draft-ietf-lake-traces
-- Göran Selander & John Mattsson, 15 mins
* Next steps
-- chairs, 5 mins
* AOB

### Minutes:

Thanks to Timothy and Marco for the excellent notes.

(meeting starts at 17:05 UTC)

* Administrivia and Agenda Bash (chairs, 5 mins)

MV: reminder about the note-well, proposing bashing as per below (swapped slot
2 and 3) GS: Sounds ok

SF: We plan a session at IETF 113 (hybrid meeting)
MV: Hybrid meeting, we'd like to know who plans to attend in person so please
inform the chairs so they get an idea how many people are joining. It's fine
to say you a) plan to be there in person, or b) plan to be remote, or c) are
not yet sure.

* Wrap up on MTI text (chairs, 5 mins)
SF: We are getting lots of input on the topic (please keep it coming but be
succinct, as to which option you prefer). Keep the discussion on the email list
until February 14th and then we can have consensus before IETF 113. MR: Not
satisfied with the current options. Scenario is different for IoT devices and
browser (they get upgraded quickly). IoT devices do not (often) get upgrades.
Some of our experiences in other WG do not really apply. An algorithm is
obsoleted by the device being obsoloted and not the way around (for example too
aggressive revmoval of MD5/SHA1 in IPSEC makes the system unusable). Are we
concerned about device code space, testing or bits on the wire. In this WG we
are mostly concerned about bits on the wire. So what is the usability of the
cipher suite with the longer MAC. SF: some of these arguments have been said
before. Yes there are differences in the IoT space compared to other
environments. SF: call for opinions on the topic. RS: To what degree do
security issues have to put to rest before deciding on MTI? SF: Chairs will
forward RSs mail (references deterministic noise draft) to the CRFG mailing
list to see if the vulnerability of RS mentioned is as serious as considered.
RS: Not sure if the CRFG is the right oracle. It is just a technical topic. SF:
This is an issue that impacts more the lake wg so it needs to be discussed in
the CRFG. JM: CFRG is on this, adoption of a related draft about
non-deterministic signatures got stuck.
https://datatracker.ietf.org/doc/draft-mattsson-cfrg-det-sigs-with-noise/ JM:
IETF has a good practice of sending crypto questions to CRFG. RS: CRFG is kind
of dead right now w.r.t. ECC. SF: Ask CRFG if the vulnerability is really bad,
so we wouldn't adopt EdDSA as a signature algorithm for EDHOC. It may be a
valid argument that the scenario is different in the IoT space. RS: It is a
political discussion. JM (on chat): As I wrote this draft I obviously agree
with Rene about that this is a serious issue. I do however think it is fine to
use in EDHOC anyway, we just have to state that we recommended that the
per-message secret number is generated in a non-deterministic way. EDHOC and
COSE already have considerations on this. RS (on chat): we need authoritative
specs and not handwaving arguments and shadow-specs. One has BCPs for a
reason.... Plus, what is the point of lake formal review if the "real" spec is
something different than what is being studied by supposed domain experts (why
would one waste people's time on studying not the real thing). RS (on chat): to
my knowledge, the lake draft is currently being reviewed by people in academia.
One should take their dedication serious and provide them with an accurate
spec, that can be referenced, papers written about, etc. SF(?) (on chat): sure,
isn't that the situation? if not, why not?

* draft-ietf-lake-traces (Göran Selander & John Mattsson, 15 mins)
GS: Marek do you want to present what you have been doing?
Marek: Sure
GS: Introduction. No new drafts since december. Working on GithUB to resolve
some issues and test vectors. All yellow labels are related to traces and test
vectors. We use test vectors in three contexts: 1. vectors on GithUB 2. vectors
in draft-ietf-lake-traces 3. ciphers suites implemented to claim complaince GS:
focussing on the traces: detailed printouts. CUrrently two traces. During last
meeting talked about changing/adding traces but no clear consensus. Our
proposal is to improve trace 2. MV: your proposing to replace trace 2 with
another one (marked in blue). GS: it is kind of teduious exercise. We didn't
see the need to have more traces but we want different traces (trace 1 is
different from 2). MV: Maybe shorten the traces only keep export. Different
mixtures of keys and signing protocols. MV: Makes sense? GS: No. Marek: The
essence for the traces is to use the signature (EdDSA and ECDSA) and then a
different credential type. UB (on chat): I support both of Göran's proposals,
and would prefer to *not* keep EdDSA - not maintain EdDSA traces. Marek: I can
jump in. GS: Take your time to explain what you have been doing. Marek (shares
screen): We all known that the vector generator was getting some comments
(problems with building). Not covering all combinations. I want to generalize,
unify crypto API. Use PSA crypto API which presents a unified, API but only
driven by ARM. Modified test vectors generator to use PSA. Hopefully we can
modify the code in the future to be more generic. Unfortunaluy no twisted
edwards. No support for EdDSA, it can do DH but no signatures. The API is
there, we can mock it but it will generate an error from the PSA side. What I
really did is switch out libsodium to PSA. PSA can be linked with hardware on
some platforms. We haven't changed anython on the implementation (no CBOR
changes). We hardcoded the authentication keys so we don't have to regenerate
the certificates everytime you generate testvectors. Implementation is now
cross-platform. Marek: links about PSA Arm Platform Security Architecture *
https://www.psacertified.org/ * https://armmbed.github.io/mbed-crypto/html/

GS: Any questions?
GS: Please join the discussion on issue #169. If someone thinks that replacing
trace 2 is a bad idea please shout out. GS: Minor changes in traces draft (see
slides). If no comments continue. GS: We had MV testing the old code. Found
some issues. If you have some time to test Marek's code MV? MV: tested it and
works out of the box. GS: Issue #222 by Stefan. GS: Plans for interop testing,
contact Marco if you have code or plan to update. Next interop will probably
take place at the IETF 113 Hackathon or (before then) online. Contact Marco
Tiloca to schedule tests. GS: Thanks a lot for everyone contributing. JM (on
chat): As I wrote in a mail some time ago, it would be good to get more
highlevel comments on the JSON test vectors and the traces document. The
authors view and intention is to have a large number of JSON test vectors for
testing implementation and a small number of human readable traces with
comments and CBOR diagnostic notation in the traces document to increase
understanding and provide a bridge between the spec and the JSON test vectors.
We have gotten a lot of comments on test vectors. It would be good to
understand if people agree or do not agree with the current division. Maybe
people have other requirements that we the authors have not understood. Or
maybe people have not understood the current division.

* draft-ietf-lake-edhoc (Göran Selander & John Mattsson, 30 mins)
GS: Reviewing some of the open issues (see slides). Sean Turner will do a
review? MV: Make sense to break up the issues in smaller issues? So it is
easier to track for the chairs. If it is an non-editorial issue put in seperate
issue from editorial issues. JM: It makes sense (but the issue was just
closed). Should we redo? MV: No redoing, just for future reference. ST (on
chat): PR #225 was fine to merge

GS: Now single slides on clusters of issues. On going discussions. Take over JM.
JM: Different comments/reviews from Marco and Sean on draft - issue #208 (see
slide 9). GS: are there any spontaneous comments? JM: this is not done, it
requires more input. GS: We need to comment that this is WIP.

GS: Three more clusters of issues.
GS: Cipher suite cluster with three issues. Two issues we wont close to day.
The last one is WIP. GS: Section 3.5 cluster of issues (see slide 11). Change
the outline of the document --> shorter documents GS: Second cluster on EAD. No
further discussion.

* Next steps (chairs, 5 mins)
GS: Compliance requirements.
GS: Target for IETF 113: close all issues. Seems realistic, we might need some
help on traces/test vectors issues. Can't make changes to traces unless we have
a new draft. SF: Status on formal verification? Is this the right time for a
new version if people are doing a verification? GS: I think they still have to
start, need to check. MV: We have one team that show interest for the symbolic
analysis. team is invited to present progress/results during IETF 113. MV:
Another team, inquiring for doing computational prove. Not sure about the
status. I want to also invite then for IETF 113.

MV: MTI discussion is on its way. Please post your arguments on the mailing
list. Chairs will try call consensus before IETF 113.

SF: What about draft -13 wrt formal verification.
MV: need to check with the teams ask if the proposed changes for draft -13 have
impact in their analysis. SF: check and come back to mailing list. MV: Ok, If
the teams don't mind do not freeze edhoc draft.

MV: wrap-up. One more meeting before IETF 113?
SF: lets ask on list.

* AOB
    * ()

(meeting ends at 18:00 UTC)