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