Skip to main content

Minutes IETF110: lake
minutes-110-lake-01

Meeting Minutes Lightweight Authenticated Key Exchange (lake) WG
Date and time 2021-03-09 12:00
Title Minutes IETF110: lake
State Active
Other versions markdown
Last updated 2021-03-11

minutes-110-lake-01

Lightweight Authenticated Key Exchange (LAKE) - IETF 110

Tuesday, March 9th, 2021 -- 12:00-14:00 UTC

Chairs:

  • Mališa Vučinić
  • Stephen Farrell

Attendees:

Agenda:

Notetaker

  • Timothy Claeys
  • Christian Amsüss

Jabber Scribe

  • Robin Wilton

Action Points

  • John Mattsson to summarize the arguments on MTI suite selection on the mailing list.
  • Chairs to schedule an interim for mid-end April.

Minutes

(meeting starts at 12:02 UTC)

  • Administrivia and Agenda Bash (Mališa)
    • Note Well
    • Agenda Bashing: no changes.
    • Milestone Update:
      • Mališa: current milestone set to September 2020, new agreement on a date to ship EDHOC. There are around 30 issues open + formal analysis work that remains. Are two more IETF meetings enough to finish the document? + 6 months to complete formal analysis
      • Göran: perhaps all issues fixed by the end of this summer. State of the protocol has not changed much recently. For today, proposing a change but minor. Not completely stable, but only small changes.
      • John: Mališa's half year for formal verification sounds good. Deadline around March next year? +1 on GS' "issues done in summer". Small things pop up from interops / implementations. Small clarifications needed in the text.
      • Mališa: Proceed doing things in parallel. Milestone to March 2022 as a rough estimate for shipping to IESG. Gives us 6 months for issues and 6 months for formal analysis work, with some overlap possible.
      • John: no changes recently that would affect Karthik's formal verification.
      • Mališa: Ideally we would like to freeze the protocol when the formal verification starts.
      • John: recent changes would not have an effect on the formal verification (verification doesn't care about encoding details, ...)
      • Mališa: no other opinions, update milestone to March 2022
      • Ben: okay sounds good
  • Hackathon Report (Marco Tiloca)
    • Report from interop #3:
      Interop during hackathon throughout whole week: (see slides). More structured notes now, see link in slides.
    • Report:
      • Marco - Lidia (using a constrained setup): successful
      • Marco - Christian (based on appendix B.1): successful
      • More spontaneous tests in the coming weeks
    • Next steps:
      • Further interop, please fill in doodle and join in spectator mode as well.
  • Update on Formal Verification (Timothy Claeys)
    • EDHOC-C:
      • (see slides)
      • Not in interops on its own, but tested against interop'd Python implementation
    • Formally verifying the implementation:
      • (see slides)
    • Mališa: In the previous interim we also discussed analysis of the protocol itself, going on in parallel.
    • Stephen: On verifying implementation, is there a pointer of other instances of doing this work?
    • Timothy: There's a paper on the HACL implementation doing the same work.
    • Emmanuel Baccelli via Jabber: more info on Hacspec and the RIOT-fp project etc see https://future-proof-iot.github.io/RIOT-fp/events. I think Karthik is currently working on a new paper on hacpsec with RUST, as a successor to the previous iteration (https://hal.inria.fr/hal-01967342/document). Best would be to ping Karthik though.
  • Changes in EDHOC-05 (Göran Selander)
    • Göran: Hope to resolve error messages
    • -04 to -05 diff:
      • Göran: small changes to the draft based on the comments of the implementers
      • Göran: more elaborate examples on error messages.
    • Error Messages:
      • Göran: already discussed at IETF 109. What diagnostic messages need to be standardized? Compared with other protocols, e.g. TLS 1.3 (error alerts), mapped to EDHOC error classes (see slides). Various steps of the EDHOC protocol map the EDHOC error classes/codes. Input of IOTOPS (specific encoding, not too much detail, create a registry, ...). Based on "actionable next steps".
      • Göran: Only actionable step follows the error code 'cipher suite not supported'. For other error codes the actionable next step is not directly clear (application specific?). Some EDHOC errors can be handled by the transport protocol. Do not add complexity if it does not add value.
      • Göran: Proposal (see slides).
      • Mališa: If I understand correctly: go for unspecified class, and actionable next step classes.
      • Göran: correct summary
      • Ben: remark on jabber: no error code for success.
      • Göran: Yes, but no actionable part when success
      • Ben: It's useful to have a single data-structure element in the application that would hold an error if there was an error, or the success code if there was no error. Not intended for the wire, just to have a value for local use.
      • Göran: how would you use it then?
      • Ben: within implementation and log messages.
      • Göran: makes sense, can be added.
      • Göran: system is flexible enough to change (we could add to other 6 errors that were specified on the slides)
  • EDHOC open issues (selected):
    • Göran: Dependence between some of the issues.
    • Applicability Statement:
      • Göran: applicability statement holds parameters that specific applications have agreed upon. Further clarifications needed. EDHOC engine needs this information for correct execution of the protocol. We want to give examples.
      • Göran: There are no fields that identify a message, message type inferred based on the expected processing.
      • Göran: What is missing is how to get from the applicability statement to the expected message fields.
      • Göran: There should be no need to restrict connection identifiers, even if endpoint can be initiator or responder. There should be no need to parse the full message.
      • Result: Add ? null for message_1. This simplifies and makes more robust.
      • Message 4 in case Initiator doesn't receive confirmation from the Responder. Request to support (encrypted) aux data in message 4. Any objections? [no voices]
    • Message deduplication and idempotency:
      • we can make it simple, rely on the transport layer. However not all CoAP implementations support deduplication.
      • Solution: EDHOC behaves as an idempotent resource. Messages may be cached or recreated.
      • Stephen: Conflict between idempotent + AD4 ? You don't know if application data in message is idempotent ?
      • Göran: requirement on AD4?
      • Stephen: I'm unsure about the uses of AD4 ?
      • John: AD4 is not different from the other ADs in the other messages. Specifying idempotency will take a while, we will need Christians input.
      • Stephen: Look at HTTPS, supposedly idempotent but not in practice, my concern here it will be same.
      • John: unsure about the terminology. Whatever we write in the document needs to be correct:
      • Christian: on application side there might be the need for the EDHOC part to really cache the AD passed from the application?
      • Stephen: not sure if this solves the issue
      • Christian: let it be handled by the [transport/protocol]
      • Göran: we need to specify this carefully. Other comments ?
      • John: AD means aux data, not application data
      • Göran: Changed the name, but it is clear that it is used by security protocols that run in parallel with EDHOC.
      • Mališa: We have no control about AD so we cannot enforce idempotency
      • Göran: probably not sufficient if we just state what we want to use it for
      • Robin: Since you don't know its real usage, it is important to specify how it should behave instead of second guessing the implementations.
      • Mališa: how to procceed with the issue?
      • Göran: have a team that will tackle it
    • Misc. message processing
      • Göran: If not receiving key confirmation what to do? Application dependant. Is the current recommendation clear enough?
      • Marco: looks good overall.
    • Test vectors as JSON:
      • Timothy: I've provided an example in the GitHub issue tracker. Need to be clear about the naming of the keys in the JSON map.
      • Timothy: I can help with the copying of the test vectors to the JSON format.
    • Test vector additions:
      • Göran: Anyone interested to help? Need some help for the top two bullets.
      • Marco: We can use the output from the tests between Lidia and Marco for cipher suite 2.
      • Göran: Maybe Stefan can help with the CBOR certificates.
      • Mališa: Status of CBOR certificates draft?
      • John: In -08 or so now; lots of discussion in COSE. No WG adoption yet because charter change required, but many requests from non-authors to adopt, and whole interims on it, and now it's in WG adoption. It's behind EDHOC in maturity but starting to be stable.
      • Ben as AD for LAKE and COSE: COSE is in rechartering with 2 rounds of IESG review and public last call; currently in first for new charter. Don't know of any obstacles.
      • Mališa: Gather that it's not adopted but has good prospects. Unless objections, go for having vectors in that format.
      • Göran: two implementers requesting certs (Stefan wants CBOR and PvdS wanted DER).
        (TIME CHECK: 13:14 UTC)
    • Connection identifier encoding:
      • Göran: CBOR byte string compresses CBOR encoding. Little complex but reduces overhead.
      • Göran: Ideas from Christian: 1) use it also for longer CBOR bstr 2) decouple EDHOC types from representation of OSCORE IDs
      • Christian: It's primarily about coding density for the non-OSCORE case -- OSCORE needs a mapping anyway.
      • John: Think better, no fast answer.
    • Revisiting MTI (mandatory to implement) cipher suite
      • Göran: SHOULD for 0 (EdDSA) "and" 2 (ECDSA) for unconstrained, "or" for constrained. Mališa said that prior concerns (with performance) of ECDSA are probably not valid.
      • Mališa: People's preferences seem not based on technical arguments. Go for concrete performance and security -- three points. ECDSA good on performance points. Need concrete input on how attacks on ECDSA would affect constrained devices with their hardware accelerators.
      • Göran: There is a clear preference for EdDSA in some settings, don't know what based on. There was security and performance argument.
      • Mališa: Heard preference, but no technical argumentation. Avoid "religious" preferences.
      • Stephen: More about tools than religion. We need to have a discussion on the list about the issue (decided during the previous interim meeting, but not done).
      • John: some companies wanting ECDSA expressed this offline and not on the list. Tricky to compare. Curve25519 can also be used for threshold crypto.
      • Mališa: can you summarize these arguments and send them to the mailing list.
      • John: Sure.
      • Michael: paraphrasing slide EDDSA has negative impact on performance (because it has no hardware support?).
      • Mališa: clarifying: since most devices have hardware for ECDSA, the performance argument does not hold. Security-wise mostly speculative.
      • Michael: Some ECDSA hardware accelerates EDDSA, but not always the case?
      • Mališa: correct, there is a draft lead by Rene Struik on how to do this, but not widely available in hardware implementations.
    • Other open issues:
      • Opportunitisc use (issue #88):
        • Christian: only one side authenticates? Needs some more thinking.
        • John: similar comments offline (RPK by value)
        • Christian: there are two cases (RPK by value), other case (device stays anonymous, only use ephemeral key, no authentication key)
        • Mališa: Seems like this is extending the scope. We agreed upon tackling mutual authentication during requirements phase.
        • Stephen: I agree, would it be wiser to finish what we are doing or extend the scope now?
        • Stephen: if we bring this up again we might have a big discussion.
        • John: Maybe some extension work later, sending RPKs by value might require COSE work.
        • Goran: Looking at the cases Christian provided: RPK by value is similar to issue #82. Other case is more speculative. I would like the keep case RPK by value.
      • Deterministic CBOR encoding (issue #71)
        • John: are there cases in the protocol where CBOR encoding is not deterministic? Specifying this explicitly would not change the protocol but it would be a clarification. Encoding an integer on 1 byte, 2 bytes, CBOR does not specify this.
        • Michael: using more bytes then needed is a sender stupidity ... Specify that integers always use the smallest encoding, or keys in CBOR map should not be strings, etc... Always use what's on the wire and not what you have reconstructed (for signing/verifying).
      • Identifying a cerificate with KID (issue #32)
        • John: COSE doesn't forbid it, but you'd have to do it manually. Recent discussion in COSE: Would be good, but no precise guidance on how to do it. Follow-up thus: If you have a certificate by KID, you would then also have RPKs with a subject name... KID is just an agreed-on name
        • Mališa: Discussed previously in LAKE. That would make certificates another type of RPK? Michael, details?
        • Michael: If the other end can't validate a certificate, it's just a container for a RPK. Need more context. Why send a whole certificate if you can't use it?
        • John: Use case is to save bytes or to not have to extend COSE Key ID subject name to comply with SIGMA. Agree with Michael that there is overlap. Not saying it should be done, just should be discussed here.
  • Next Steps (chairs)
    • Next interop in April
    • Timothy to update on formal verification of EDHOC-C
    • Formal analysis: Mališa to sync up with Karthik
    • Interims in next period?
      • Göran: Yes.
      • Mališa: Mid-April and Mid-May?
      • Marco: Second half of April, after interop session.
        → Chairs to schedule interims.
  • AOB
    • GS: Thanks for input from implementers; comments from non-implementors would be appreciated too.