Lightweight Authenticated Key Exchange (LAKE) - Interim Meeting

Tuesday, October 5th, 2021 -- 15:00 - 16:00 UTC

Chairs

• Stephen Farrell
• Mališa Vučinić

Present

1. Stephen Farrell
2. Mališa Vučinić
3. John Mattsson
4. Loic Ferreira
5. Uri Blumenthal
6. Marco Tiloca
7. Francesca Palombini
8. Göran Selander
9. Sean Turner
10. Stefan Hristozov
11. Jonathan Hammell
12. Carsten Bormann
13. Marco Tiloca
14. Rikard Höglund
15. Timothy Claeys
16. Michael Richardson
17. Deb Cooley
18. Peter Blomqvist
19. Kathleen Moriarty

Useful Links

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

Agenda

1. Administrivia and agenda bash (chairs, 5 mins)
2. Interop update (Marco)
3. EDHOC status/issue (Göran, John, ~30 mins?)
4. AOB

Minute taker

• Jonathan Hammell

Action Points

• Chairs to confirm the adoption of draft-selander-lake-traces on the ML
• Volunteers to review draft-ietf-lake-edhoc-12, once published:
  • Marco Tiloca
  • Kathleen Moriarty
  • Stefan Hristozov

Minutes

1. Administrivia and agenda bash (chairs, 5 mins)

No changes to the agenda.

1. Interop update (Marco)

(no slides presented)

• Marco's implementation for Californium is aligned to version -11 and validates against the latest test vectors from draft-selander-lake-traces-01. Call to implementers to reach out to Marco so an interop session can be organized, once there is another implementation ready for testing.

• Timothy: Working on an implementation and will inform Marco when updated to latest draft.

• John: The test vectors in draft-selander-lake-traces-01 were generated with the open-source C++ code at: https://github.com/lake-wg/edhoc/tree/master/test-vectors-11

  • There is a variable in the code to trigger between the draft-selander-lake-traces format and JSON

• EDHOC status/issue (Göran, John, NN mins)

(Slides: https://datatracker.ietf.org/doc/slides-interim-2021-lake-04-sessa-edhoc-slides/)

• Göran presented. Update on main changes since IETF 111 (versions -08 to -11):

  • Key derivation changed (details in slide 3)
  • Cipher suites (SUITE_I) updated. MAC length was added.
  • Message size -related formatting. Changes test vectors. Confirmed on the mailing list. Discussion in COSE to get preference to extend 'kid' to int, but will be confirmed in COSE WG interim next week.
  • CWT-related changes to use CWT as credentials. UCCS renamed CCS.
  • syntax for external authorization data changed.
  • editorial changes to restructure Sections 3.5 and 4, and added new Section 7.

  • numerous misc changes (details on slide 4)

  • Open Github Issues (slide 5). Issue regarding post-quantum not listed on the slide.

  • Issue #174: use of confirmable messages in CoAP. Carsten expressed support. No objections.
  • Issue #167: registration procedures for the new EDHOC registries.
  • Carsten: Instruct the expert to be frugal with small numbers.
  • Stephen: This stuff gets commented on a lot in e.g. IESG review. Do we care much?
  • Göran: Plan to do the same as COSE.
  • Sean: Expert review implies specification required, but does not need to be in a RFC.
  • Stephen: The WG seems (today) to be fine with expert review implying there is some specification somewhere, but not fussed about whether the spec is in an RFC (with the exception of small numbers where the WG want to be frugal.)
  • Issue #161: ID_CRED_X are COSE header maps. New header parameters defined for CWT/CCS for transporting a COSE key. Discussed in the design team. No objections.
  • Issue #162: CWT/CCCS header parameters - tagged, untagged or both. Proposal discussed in the design team meeting. No objections. Design team recommendations regarding re-encoding.
    • Sean: Seems like a pragmatic approach. Do CWT and CCS need several header parameters each similar to x5u, x5t, x5chain, x5bag?
    • Sean: Just a registry setting, so it should just be done.
    • John: Some of the security considerations discussed in COSE may not be applicable in EDHOC.
    • Carsten: Do we need x5u? It has different security considerations.
    • Stephen: The WG seems to agree that something should be done, but in LAKE or someone else?
    • Göran: Anything for EDHOC can be done here, except for chains of CWTs which should be done elsewhere. (No-one objected to this plan.)
    • Carsten: What does it mean regarding a CBOR wrapped in a bstr?
    • Göran: We will discuss that offline.

• Issue #169: content of draft-selander-lake-traces. Skipped, but revisit at the end of the meeting if there is time.

• Issue #81: effects of limited amounts of randomness. Request to use a monotonous counter similar to OSCORE, with a private secret, and instructions for storing state. Is there a reference that can be used?

  • Stephen: Is this randomness used for nonce or secrets?
  • Göran: Used for ephemeral key generation.
  • Stephen: Sounds like a KDF. Probably better handled via a reference if so.
  • John: There is a CFRG draft that discusses randomness.
  • Göran: This CFRG draft is cited, but the draft does not discuss how to combine these issues.
  • Marco: Could look at Echo-Request-Tag document (appendix A) in CORE that was doing something similar. https://datatracker.ietf.org/doc/html/draft-ietf-core-echo-request-tag-14#appendix-A
  • Carsten: Does ECHO have the same security requirements?
  • Göran: We can use these documents for inspiration for how much detail to put in the EDHOC draft.
  • Stephen: Don't use something home-grown. Use a well-studied KDF.
  • Stephen: It may be non-trivial question that requires analysis whether to use residue from past key derivation is next one. Sounds like CBC residue approach to key mgmt used in 1980's banking.

• Issue #73: which parts of the spec are MTI? Request for WG members to provide input to Github issue.

• Issue #47: test vectors. Ask for people to help out.

(Remaining Github issues on slide 14.)

• The editors think the protocol is in good shape for review, testing and analyzing.

• Revisiting Issue #169 (draft-selander-lake-traces).

  • John: Minor technical issues can be discussed offline on Github. Should it be adopted by the WG?
  • Stephen: Do we want to publish this an an RFC? This can be a lot of work. It could be left as a draft.
  • Göran: Intent of the draft is to be a complement to the Github document containing test vectors, provided a few annotated traces. What should be the scope of the document? Currently two traces (Methods 0 and 3).
  • Sean: No problem with publishing. It could also be just put on Github.
  • Stephen: The WG chairs will do a call for adoption. It will be clarified that this is a currated set of examples and not intended to be comprehensive.
  • John: Not much value provided in additional traces.
  • Mališa: To confirm on the mailing list.

• Draft -12 will be posted before IETF 112 cut-off. Call for volunteers to review:

  • Marco Tiloca
  • Kathleen Moriarty
  • Stefan Hristozov

• Mališa: Will work with Karthik to draft a request to the crypto community to perform a formal analysis.

• Stephen: Should we start talking about WG last call?

• Göran: Would like an AD review.

• Stephen: AD review typically happens after the publication request, but we can ask the ADs if they have a chance to look at it.

• Sean: Similar to other WGs, we could move it to WGLC but hold it until the formal analysis is complete.

• Stephen: Let's get the reviews on -12 and then we can kick off the WGLC.

• AOB

Nothing raised.