Minutes interim-2021-lake-01: Thu 17:00
minutes-interim-2021-lake-01-202101281700-00

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