Skip to main content

Minutes interim-2020-lake-04: Fri 16:00
minutes-interim-2020-lake-04-202012181600-00

Meeting Minutes Lightweight Authenticated Key Exchange (lake) WG
Date and time 2020-12-18 15:00
Title Minutes interim-2020-lake-04: Fri 16:00
State Active
Other versions plain text
Last updated 2020-12-23

minutes-interim-2020-lake-04-202012181600-00
# 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.