# Lightweight Authenticated Key Exchange (LAKE) Virtual Interim

Thursday, January 28th, 1600-1700 UTC

Chairs: Mališa Vučinić, Stephen Farrell
Meeting link: https://ietf.webex.com/ietf/j.php?MTID=m2c8bc985be07c3d344f5c58db1bd156f
Meeting number: 178 427 7458
Password: zDEPVmnZ533
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-2021-lake-01-lake

Participants:
1. Stephen Farrel (SF)
2. Malisa Vucinic (MV)
3. Carsten Bormann, TZI (CB)
4. Francesca Palombini (FP)
5. Marco Tiloca, RISE (MT)
6. Rikard Höglund
7. John Mattsson (JM)
8. Michael Richardsdon, Sandelman
9. Göran Selander (GS)
10. Timothy Claeys
11. Karthikeyan Bhargavan (KB)
12. Peter Blomqvist
13. Peter Yee

Agenda:
- Administrivia and agenda bash (chairs, 5 mins)
- Report from 2nd EDHOC interop (Francesca Palombini, 5 mins)
- Formal analysis of EDHOC next steps (chairs & Karthik Bhargavan, 10 mins)
- EDHOC open issues (John Mattsson, 35 mins)
- Planning for IETF 110 (chairs, 5 mins)
- AOB

Action Points:
- John Mattsson or Karthik Bhargavan to start a thread on the target security level for different cipher suites
- Rene Struik to (re)start a mail thread discussing the MTI suite topic
- Göran Selander to send an email to IOTOPS on categories of diagnostic messages

(Meeting starts at 17:04)
Minutes:
- Administrivia and agenda bash (chairs, 5 mins)
    - Joining mic queue (type +q), leaving (type -q)

- Report from 2nd EDHOC interop (Francesca Palombini, 5 mins)
    - FP: Jan 22nd, 3 implementations (previously 2)
    - FP: Interop based on draft -02 (currenly at draft -04)
    - FP: Test vectors B.1 (auth method 0, cipher suite 0) + randomly generated ephemeral keys. All tests passed in all directions for all implementations. 
    - FP: Also tested B.2, testing started, but issues during set up and message verifications.
    - FP: Other implementers (Michel Veillette) cipher suite 5. Trace available on Google drive.
    - FP: More implementers are interested in joining upcoming interops
    - GS: Mention 2 more teams/implementers were present
    - FS: There were 13 attendees (with implementations, but not everyone implemented the test vector B.1 and authentication method 0)
    - SF: Can you talk about the setup ? (time zones?)
    - FP: Set up a doodle, interop organization was based on wishes of the implementers.
    - SF: Were most of the developers in the same time zone? Synchronous testing?
    - FP: Yes, except Michel Veillette. The other attendees were spectators.
    - GS: Set up uses ping/CoAP. Time zones were Sweden, Germany, Belgium and Canada.
    - SF: Maybe plan interop 2 meetings ahead to schedule coding for the implementers.

- Formal analysis of EDHOC next steps (chairs & Karthik Bhargavan, 10 mins)
    - MV: Specification needs to be high quality, formal verification with the academic community
    - MV: Tamarin tool verified a previous version of EDHOC (during summer). Several issues were found, now resolved (message 4, explicit key confirmation)
    - MV: Next steps discussed with KB.
    - MV: Ongoing plans to perform analysis with CryptoVerif. Probability bounds as a function of the crypto primitives used in the protocol.
    - MV: Next to the protocol, build a verified implementation. At Inria formally verify the C implementation with Prosecco using F*.
    - SF: Who's implementation is being verified
    - MV: Inria's implementation, lead by Timothy
    - KB: End of the process to have multiple proofs covering different aspects of the protocol. In different models that are complementary -- one symbolic, one computational (CryptoVerif), verify the reference implementation to make sure things are not left out from the models
    - KB: Tamarin analysis (KTH, IT University of Copenhagen & Ericsson).
    - KB: CryptoVerif (computational crypto proof).
    - KB: Verified C implementation using F* (verifying code).
    - KB: Is there a targeted security level, e.g., cipher suite 0 must have 128-bit security?
    - JM: Most TLS cipher suites aims for 128-bit security.
    - JM: Not put on paper. Tentatively, 128-bit for confidentiality and 64-bit for integrity (but sometimes related)
    - KB: Start a thread on the mailing list to reach consensus
    - SF: Common security target for multiple WGs (for constrained devices) when we reach consensus on the mailing list
 
- EDHOC open issues (35 mins) (time: 17:28)
    - Slide 2: Changes
        - JM: submitted version 4 yesterday
        - JM: Essentially reversion to -02, defined as binary additive stream cipher
        - JM: Better security than AES-CTR
        - JM: Specified message 4 (no signaling specified)
        - JM: Mandatory cipher suites (constrained either 0 or 2), less constrained (both 0 and 2)
    - Slide 4: Open Issues & Closed Issues
        - JM: Finally no KEM specification
        - JM: Lightweight Forward Secrecy implemented as EDHOC-Rekey-FS()
        - JM: SHAKE and KMAC issue closed
        - JM: Requests for test vectors for CBOR and DER encoded certificates
        - RS: What is the normative text on SHA-512 or SHA-256 usage in EdDSA ?
        - JM: Half of the community want EdDSA, so if you can support both 0 and 2 else one of those.
        - GS: Should vs Shall (EDHOC draft should only contain recommendation abouth the MTI cipher suites)
        - MV: Are you not happy with the current phrasing RS?
        - RS: Support SHA-256, no-go for 0 and 2 (because EdDSA needs SHA-512)
        - GS: 1/2 community want EdDSA other half wants ECDSA
        - RS: There is no working group consensus on the issue around MTI cipher suites...
        - GS: Reopen the mandatory SHA-512 issue on GitHub and on the mailing list (formulate in RS's words).
            - Action Point: RS to start a mail thread discussing the topic.
    - Slide 5: ID encryption in message_2
        - JM: Developers are happy with the current solution (use HKDF expand as a binary stream cipher).
    - Slide 6 & 7: Optional message_4 1(2) and AD_4
        - JM: Raised by formal verification. Very simple (only contains MAC, optional to implement/use)
        - JM: Default: rely on App protocol to do the key confirmation (similar to TLS). In case there is no app on top, uses message 4.
        - No signaling that message 4 will be sent, key confirmation mandatory.
    - Slide 8: Forward and backward secrecy
        - JM: EDHOC-Rekey-FS provides lightweight way to get Forward Secrecy.
    - Slide 9: Error Message Diagnostics
        - JM: Unclear how error message works: how to distinguish between error msg and normal msg. Error messages contain text strings (other messages do not). All error message are fatal, but no authentication.
        - JM: Text strings used for humans (debugging messages in English)
        - JM: Renaming: Error messages --> Diagnostic messages
        - JM: Still open: standardized text strings?
        - CB: How do you act on the diagnostic messages (user vs developer)? Do they come up in the operational context, e.g. certificate has expired? May  it be beneficial to specify categories of diagnostic messages.
        - JM: Categorize based on prefix (e.g., an integer). May use TLS 1.3 as a starting point.
        - CB: Question for IOTOPS, what categories of diagnostic messages. 
            - AP: Göran to send an email to IOTOPS.
    - Slide 10: Distinguish Messages
        - JM: Distinguish between other messages: message 1 vs message 2 vs message 3? 
        - JM: First thought was that it was handled by the underlying transportation protocol.
        - JM: Analyze further.
    - Slide 11: Length values when using the Exporter for OSCORE (#58) (time 17:51)
        - JM: Length of key and salt are fixed (for the EDHOC exporter). Should they be default instead of required. Applications can use different values.
        - JM: Flexibility vs Interoperability.
        - (No objection.)
    - Slide 12: Passing information to the application (#57)
        - JM: Request to be more explicit about what to forward to application in case of error.
    - Slide 13: More ways to identify certificates ('kid’, ‘c5u’, c5t’)
        - JM: Add real certificates (CBOR and DER).
        - JM: Using a KID to identify a certificate has been discussed in COSE WG.
    - Slide 14: Test Vectors
        - JM: Feedback from interops, adding exporter and TH_4 outputs
        - JM: Further updates require newly generated test vectors (such as CBOR/DER certificates and other cipher suites: 2, 3, 4 and 5)
    - Slide 15: Recent Issues 
    - JM: #62: Why is the number of parameters restricted in the COSE key? Not really restricted, but more parameters would require us to enforce an ordering.
    - JM: #61: related to distinguishing between messages. Concrete example provided.
    - SUMMARY:
        - GS: No real changes to the protocol in a long time. As a result of change in -04 there will be changes to the test vectors. Most of the discussion has been happening on GitHub.
- Planning for IETF 110 (chairs, 5 mins)
    - SF: Do the implementers lock in on a specific version of the draft or are they okay with keeping up with the GitHub changes? Need a new version?
    - MT: I will keep up with the changes, targeting -04.
    - GS: Existing implementations support -02. We either test that or -04. No need for a new version of the draft.
    - SF: Major issues to focus on at IETF 110? 
    - (No response.)
    - SF: So, we will continue ticking off issues.
- AOB
    - (No other business.)

End of the meeting.