# Lightweight Authenticated Key Exchange (LAKE) Virtual Interim Friday, December 18th, 1500-1700 UTC Chairs: Mališa Vučinić, Stephen Farrell Charter: https://datatracker.ietf.org/group/lake/about Mailing list: https://www.ietf.org/mailman/listinfo/Lake Etherpad: https://codimd.ietf.org/notes-ietf-interim-2020-lake-04-lake Github: https://github.com/lake-wg Attending: 1. Francesca Palombini 2. Michael Richardson 3. Malisa Vucinic 4. Dominique Barthel 5. Stephen Farrell 6. Rikard Höglund 7. Marco Tiloca 8. Rene Struik 9. John Mattsson 10. Peter Blomqvist 11. Göran Selander 12. Carsten Bormann 13. Christian Amsüss 14. Timothy Claeys Note taker: Michael Richardson, Goran Selander https://duckduckgo.com/?q=aeriel+photo+lake&atb=v147-3__&iax=images&ia=images Agenda: 1. Administrivia and agenda bash (chairs, 5 mins) 2. Remaining open issues in the EDHOC draft (John Mattsson, NN mins) 3. Report from EDHOC interop testing (Francesca Palombini, 5 mins) 4. AOB Minutes: (meeting starts at :05) Action Points: * John to formulate the problem details on ID encryption in message_2 and contact Rene for input 1. Administrivia and agenda bash (chairs, 5 mins) * Fit in Rene's input, perhaps in connection to related issue. * Potential interim before IETF 110 2. Remaining open issues in the EDHOC draft (John Mattsson, NN mins) * Issue updates since IETF 109 * issue 11, issue23: resolved with an appendix in -03. * issue 32, issue 33: resolved with kid,c5u,c5t * issue 8: further clarification about MACing the identity is included in -03 * issue 30: Marco has added a way to distinguish between message_1/message_2/message_3. Why doesn't connection identifier solve the problem? More implementation guidance is welcome. * Error messages: Michael: IKEv1 suffered from not providing sufficient information. * Carsten: General property. Influence on the state machine: If it does, standardize; if it doesn't you don't standardize. * Michael: Standardized code points can be used for translation to different languagues. * The error messages should work as with CoAP: a code and some text, which guide the engineer when they debug. * issue 19: replace HKDK with more general extract-and-expand to allow KMAC?: not to standardize any new cipher suite. * issue 17: specify EDHOC in terms of KEM * signature mode maps well. * static DH does not map well and increases message size. * Register cipher suites with high security (#35) * multiple requests to standardize high-security suites. -03 adds 2 new cipher suites. * CNSA cipher suite will not incur the minimal overhead as described in draft-lwig-security-protocol-comparison where the assumptions on cipher suite are explicit. * Rekeying OSCORE AEAD (#20) * -03 includes a mechanism for forward secrecy by hashing of pseudo-random key generated by EDHOC * QUESTION: about mixing of EDHOC and OSCORE nonces? * OSCORE normally calls EDHOC exporter interface "give me a key". it would then call exporter PFS interface with nonce, then ask for another key. * Highlevel: EDHOC will provide for rekey (not excluding that OSCORE might do something itself) * ID encryption in message_2 (#34) * Last meeting proposal to go for option 3. Turned out to be complicated both to specify and implement. Since more data neeeds to be encrypted, the construction from TLS using only a block cipher does not carry over. * Options 1 and 2 are better in this respect. Current specification is using option 1, which builds on XOR. Further clarifications of its use would need to be included if option 1 were to be chosen. * Malisa: Which AEAD algorithms does not have an explicit tag that can be removed. * John: Potentially Aero by McGrew et al. * Michael: so we are removing the authentication part (tag) because it has no value, as a space saving measure. If someone couldn't do that, they would have to live with more bytes (a block size: 16 for AES-types) * Action Point: John to formulate the problem details and contact Rene time: :56 * Delivery receipt for message_3 / key confirmation (#10, #18) * Optional 4th message, requested by the initiator. * Michael: Message 4 should be defined, but optional to implement. Signal in message 1 or message 3. * Malisa: Wait with long term storage until confirmation. Do we need to specify message 4? * John: Do we want to require an application layer protocol, or could you just use EDHOC? * Malisa: OK, in case there is no explicit application confirmation, message 4 can be used. * TEE Assumptions (#5) * John: Realistic that only key derivation remains in TEE * Michael: we need to say which keys relate to other keys, whether a key can be replaced (such as during an upgrade), without affecting the long-term relationships, etc. * Forward and backward secrecy (#24) * John: Working assumption is either do full EDHOC exchange, or hash-based forward secrecy which requires no asymmetric operations. No formal ratcheting. * SHA-512, signature algorithms, and MTI cipher suite (#2, #21, #22) * Rene: Is FIPS compliance necessary? Rene will raise an issue. * Malisa: Preference to select an MTI for interoperability reasons * Stephen: IESG personnel unpredictable. Potential formulation: If device less constrained, then SHOULD implement both. If device constrained SHOULD implement one of these two. * Michael: okay, we should allocate a code point to this. We should not decide upon MTI in this document, we should do what IPsec does with RFC8221. * ECC Cipher Suites Discussion (Rene Struik, 10 mins) * Rene presents the slides * Agreement to add a suite based on Wei25519 4. Report from EDHOC interop testing (Francesca Palombini, 5 mins) * Francesca: Test according to Appendix B.1 between Fraunhofer and Inria implementations. One setting (Initiator/Responder) ran successfully, the other direction did not work due to connectivity issues. New interop third week of January, welcome to fill in doodle and join: * https://doodle.com/poll/mrhqqewzinegnmtq 5. AOB * Stephen: Another interim meeting late January/early February? * Positive response.