Lightweight Authenticated Key Exchange (LAKE) - Interim Meeting

Thursday, April 22nd, 2021 -- 14:00 - 15:00 UTC

Chairs:

• Mališa Vučinić
• Stephen Farrell

Useful Links:

• Charter
• Mailing list
• Jabber room
• Minutes
• Webex
• Recording

Present:

• Mališa Vučinić (MV)
• Stephen Farrell (SF)
• Marco Tiloca (MT)
• Timothy Claeys (TC)
• Armando Miguel Garcia
• Carsten Bormann (CB)
• Göran Selander (GS)
• John Preuss Mattsson (JM)
• Jonathan Hammell
• Peter van der Stok (PS)
• Stefan Hristozov (SH)
• Rikard Höglund
• Michael Richardson (MR)

Agenda:

• Administrivia and Agenda Bash
  -- chairs, 5 mins
• Interop Report
  -- TBD, 5 mins
• uEDHOC Performance Evaluation
  -- Stefan Hristozov, 10 mins
• EDHOC Open Issues
  -- TBD, 40 mins
• AOB

(Meeting starts 16:04 CEST)

Minutes:

• Administrivia and Agenda Bash (chairs, 5 mins)

  • note well
  • agenda bashing

• Interop Report (Marco Tiloca, 5 mins)

  • Five implementations (new implementation from Peter van der Stok)
  • Results can be found in the google drive (spreadsheet)
  • Test pairs
    • Marco - Peter
      • All authentication methods
      • Ciphersuite 2 & 3 (first time ever)
    • Marco - Stefan
      • Some reachability issues
    • Timothy - Christian
    • Marco - Christian
    • More testing (Marco, Timothy, Christian) coming up
    • MV: C-based implementation, can you elaborate ?
    • PS: Based on libcoap, issues with mbedtls for ciphersuite 0 & 1, ran on Pi4 and desktop
    • MV: Christian's implementation build on Timothy's py-edhoc?
    • MT: Yes

• uEDHOC Performance Evaluation on Constrained devices (Stefan Hristozov, 10 mins)

  • Two EDHOC implementations (for microcontrollers and Linux) + implementation for microcontrollers with TEE
  • TEE implementation:
  • Seperate sensitive code (secure world) from non-sensitive (non-secure world)
  • Overview performance tests:
    • Evaluated cipher suite 0
    • Native CBOR certificates
    • Crypto uses tinycrypt and c25519
    • Four different microcontrollers, TEE platform Cortex-M33
  • Message sizes analyzed for 4 of 16 different scenarios (overall really short messages)
  • Results for devices without TEE --
    • Flash usage split in crypto and protocol logic
    • RAM requirements, generalLY responder and initiator have similar requirements
      • Roughly 4k (Certs)
      • Roughly 2.5k (RPKs)
    • Computing time, on weaker devices such as Cortex-M0 (when there are signatures and certs), can take a fair amount of time: 39 seconds
  • Results for devices with TEE --
    • Overhead flash roughly 2K
    • Increased RAM usage with TEE (due to the fact that there are 2 seperate stacks with 2 virtual CPUs --> cannot reuse buffers)
    • In general no problem for state-of-the-art microcontrollers
    • No additional overhead in computing when using TEE

  • Implementations without TEE are open source:

    • permissive licenses
    • WIP integration with Zephyr OS (WIP)

  • MV: really useful to have an exhaustive performance study.

  • MV: Surprised by the 39s results on the Cortex-M0, you didn't use any OS, so the CPU was monopolized by the calculations ?
  • SH: Reasons for slow time: no acceleration, only 16Mhz CPU
  • JM: Dominating factor is crypto?
  • SH: Yes, scale of the X-asxis is logarithmic, scales from 1.3ms (for protocol logic) to more than 30s (for the crypto)
  • MV: Timothy do you have any results on EDHOC-C
  • TC: Only on flash size (roughly the same)
  • MR: Reason TEE is not open source?
  • SH: I cannot maintain both repositories, takes a lot of time + a political decision --> TEE version might be commercialized, bot no external reason why it cannot be open source

(Time: 16:31 CEST)

• Main Changes -05 -> -06 (Göran Selander)

  • Main changes:
    • optional byte: to detect message 1 (depends on applicability statement)
  • updates on error codes
  • Change on recommendation for CoAp
  • unchangesd test vectors
  • applicability statement
  • deterministic CBOR
  • Always determinstic CBOR (e.g. credential encoding)
  • Message deduplication
  • Appendix on CDDL and change log
  • Removed section on documents listing EDHOC
    • Circular and not really needed
  • Section on TEEs
  • Clarifications (reviews PS & MT)
  • Update references

• EDHOC Open Issues (John Mattsson & Göran Selander, 40 mins)

  • No major issues -> mostly optimization
  • Issue: EDHOC and availibility -- If processing fails in any way -> discontinue and send error message. This is subject to a DoS attack (attacker sends a single byte and processing will fail). Soften this requirement?
  • MV: An attacker can forge an error message and discontinue the handshake?
  • JM: Yes, but an attacker can even send a single byte to discontinue the handshake
  • JM: Maybe a MAC to error message, maybe not worth the complexity
  • MV: what would we gain?
  • JM: TLS first no error message with cryptographically protected, now some are
  • SF: IPSec you can have unexpected messages (difference with TLS)
  • SF: Will applications multiplex protected and unprotected traffic over the same port/URI ?
  • JM: Maybe someone else can answer this question better
  • JM: Small connection identifiers so easy to spoof (make a message be processed as message 3)
  • CB: The use cases exist (multiplexing over same port/URI), normally sort/demultiplex traffic before start interpreting as EDHOC

• Scope of the applicability statement

  • List of things you need to agree on. Changed in draft to a policy framework (cipher suite and credentials were allowed?)
  • Applicability statement has been tuned down again (no longer policy statement)
  • CB: All TLS libraries allow you disable certain ciphers and I expect EDHOC to allow the same
  • PS: How do they agree on the applicability statement?
  • CB: Same issue in TLS (switching off older TLS version breaks sometimes the protocol)
  • PS: not clear if C_1 is used
  • GS: Should there be an extensive list of parameters to agree on?
  • GS: from the applicability statement (e.g. on this URI), C_1 is used or not used, should be clear from the context
  • MV: do we want the complexity of the CORR value ?

• Forbidding multiple calls to EDHOC exporter

  • No guidance on how to use the exporter?
  • Prefix labels or context parameter (IANA registry)
  • MV: personal opinion is that a seperate context parameter makes more sense

• Next steps

  • GS: Small design team/hackaton to solve the issues we keep running into.
  • GS: Both hackaton and design questions planned for mid-May
  • MV: Next interim early June/end May so the design team and hackaton can report
  • JM: Pull request for 2 issues (issues related to intermediate hashes and encoding connection identifiers)
  • JM: Need to discuss the level of optimization (now optimization to 45 bytes).
  • MV: Optimization level based on 6TiSCH, coordinate offline
  • GS: Marco send out doodle for Interim?
  • MT: Yes

• AOB

  • None

(Meeting ends)