Lightweight Authenticated Key Exchange (LAKE) - IETF 112

Friday, November 12th, 2021 -- 14:30-15:30 UTC

Chairs:

Mališa Vučinić
Stephen Farrell

Useful Links:

Agenda:

Administrivia and Agenda Bash
-- chairs, 5 mins
Update on the call for formal analysis
-- Mališa Vučinić, 5 mins
Status and scope of draft-ietf-lake-traces
-- chairs, 5 mins
EDHOC Status
-- John Mattsson & Göran Selander, 5 mins
EDHOC Issues pending WG decision
-- John Mattsson & Göran Selander, 15 mins
Discussion of Pre-WGLC EDHOC reviews
-- John Mattsson & Göran Selander, up to 20 mins
Next Steps
-- chairs, 5 mins
AOB

Notetaker

Timothy Claeys

Minutes:

(Meeting starts at 3:30)

Administrivia and Agenda Bash (chairs)
- Main items
  - Update on the formal analysis of EDHOC
  - Lake Traces draft
  - Updates on specification
Update on the call for formal analysis (Mališa Vučinić)
- MV: Preparing a call for formal analysis. Syncing with Karthik. Working with authors on a short paper for the crypto community, for those who are not familiar with EDHOC. Currently addressing comments from Karthik. Paper gives a primer on EDHOC and consists of 3 parts:
  - Security goals
  - Design
  - How EDHOC meets the goals and research challenges
- MV: Official invitation for the crypto community to start working on the analysis.
- SF: this is not a consensus document. Maybe allow for comments of the WG?
- MV: I will put this online. It will be published on open archives. We can iterate on it.
- SF: 6 months, how do we know this is the right period.
- MV: this was discussed during the last IETF meeting.
- SF: Hopefully something happens in those six months.
- MV: With the help of Karthik we will reach out to the right teams.
- JM: 6 months is good? as a start?
- SF: Looking forward to the first iteration.
Status and scope of draft-ietf-lake-traces (chairs)
- MV: Brief wrap up of the adoption call: launched on the 18th of October. Feedback from 4 people. Generally, people support adoption. They also support publication as an informational RFC. Sean commented that we really should ensure correctness. One thing that is not clear is the scope of the draft.
- MV: Current Draft covers:
  - Methods 0 to 3
  - Cipher suite 0
- MV: There has been interest for P-256 (suites 2 & 3).
- MV: Which method and cipher suites combinations should we add to the draft?
- TC: All methods combined with cipher suites 0 and 2.
- JM: Lots of test vectors on Github. More explanations in draft. 2 to 3 traces in draft (for correctness, because there is a lot of work to write those out and ensure correctness).
- SF: post test vectors on github and then select from those to build the draft.
- GS: We already have some on github. We also have a new co author for the draft that will add traces for cipher suites 2 and 3.
- MT: Compromise between TC and JM. I see appropriate to have both methods 0 and 3 for both ciphersuites 0 and 2. Just reiterating from https://mailarchive.ietf.org/arch/msg/lake/0N2-CzE-hRQjXNZfUw8edDHZhto/
- MV: Would you like also methods 1 and 2?
- MT: Not necessarily, but I can understand if someone would like to have them too.

(Time check: 2:48 UTC)

EDHOC Status (John Mattsson & Göran Selander)
- JM: Main changes between 08 -> 11
  - already discussed at interim
  - technical changes until 11
  - key derivation changes
  - simplification (negotiation of cipher suites)
  - CWT and CSS
- JM: Changes done after the interim 11 -> 12:
  - No technical changes
- JM: Questions on the status?
  - No questions
EDHOC Issues pending WG decision (John Mattsson & Göran Selander)
- #201
  - JM: Minor cryptographic explanantions:
  - MAC must be at least 8 bytes
  - Compact representation Gx, Gy
  - nonce binding
  - Why EDHOC does not support running hash (because it is not supported on many constrained devices)
- #198
  - JM: Security considerations
- #193
  - JM: New draft in COSE for PQC KEMs.
  - JM: It would not affect current Gx, Gy KEM
- #191
  - JM: The information on the non-repudiation was wrong. This is similar to IKE. In TLS 1.2 the signature is (not sure) encrypted.
- #186
  - JM: Discussion on the internal structure EAD. Unclear how other protocols will use the EAD interface. JM thinks we should specify it is correct CBOR (needs more discussion).
- #178
  - JM: Security consideration of TOFU.
- #142
  - JM: Length of the document. Is 101 pages too much.
- #81
  - JM: Effect of limited randomness. A small PR was added by GS.
  - JM: Optimal padding (also an open issue):
  - Missing privacy consideration (there is a open PR).
  - TLS1.3 and IKEv2 have padding mechanism to mitigate privacy leaks about ID_CRED and EAD.
  - There is a proposal in PR #190. --> padding.
  - SF: What is the best way to close the ones we think should be closed? Send a mail to the list saying that the issues will be closed soon.
- #169
  - JM: Issues about test vectors: already discussed during the EDHOC traces update.
- #188
  - JM: Missing SUITES_R? Have a list of supported responder cipher suites in the test vectors.
  - JM: Should we support test vectors with an error in the cipher suite negotiation?
- #187
  - JM: TOC for the test vectors
  - JM: There are many test vectors but you don't know what is in them unless you read the source code.
- #47
  - JM: Status of the test vectors additions 10/12
  - JM: No real certificates yet (just 1,2,3 encoded)
  - JM: Any questions?
Discussion of Pre-WGLC EDHOC reviews (John Mattsson & Göran Selander)
- JM: Reviews by:
  - Marco Tiloca
  - Stefan Hristozov
  - Kathleen Moriarty
  - Stephen Farrell
- JM: The reviews have been added in there own github issues for ease of discussion. Big changes can be split off in seperate issues.
- Stefan's review
  - EAD
    - JM: Should EDHOC application encode to CBOR?
  - Error Handling
    - JM: It was a strong suggestion by IOTOPS. JM suggest to keep it in but not sure when it should be used.
  - Mandatory to implement cipher suite
    - JM: Semantic changes
  - What about revocation?
    - JM: EDHOC does not provide any guidelines? OSCP can be used. COSE does not support OSCP stapling. Maybe it could be added in COSE.
- Kathleen's review
  - IANA considerations
- Intermittent discussion in chat on MTI:
  - DG: Too many options is dangerous, add some guidelines to the documents for the MTI. Maybe something like: Use X25519 unless pre-existing hardware constraints force you to use ECDSA.
  - JM: something like this was already proposed by SF.
  - DG: Guidance that explains is fine, but guidance that expactly tells you what to do is better for the lazy implementer.
- Stephen's review
  - Connection IDS
    - SF: I am not entirely sure what the additional value could be of connection ID. My concerns is that cid leaks over to other protocols (proxying) --> colissions on cid. Traffic analysis of specific initiator's traffic. If we think that multiplexer for traffic will be widespread, an observer can easily do traffic analysis which is undesirable.
    - JM: Right now the idea is to share the CID in EDHOC and OSCORE.
    - JM: some considerations to spell out: if you use the same cid in different places you can be tracked. Run EDHOC again when you change CID to prevent being tracked.
    - SF: People have often said that they only when to run EDHOC very rarely (during unboxing). CID behavior is not something we can easily change later on. Maybe we could come up with a scheme where we send an identifier in message 1 and then derive a more stable CID from that.
    - JM: we could derive something, for now just go with the considerations on the CID in the document.
  - Terminology on CDDL
  - Do we have to support hash based sigs?
    - JM: support everything COSE supports (which also means that we have RSA which is not desired).
    - SF: in the context of long-lived devices (I didn't understand what was being said)... ?
    - BK: We assume EDHOC is going to support everything COSE support. I don't think we should assume that. There could be algorithms in COSE that makes no sense in EDHOC. This is a different question than does hash-based sigs make sense for EDHOC.
    - JM: It is hard to filter out future algorithms that don't make sense for EDHOC.
    - BK: True we should be carefull on how we formulate the text.
Next Steps (chairs)
* MV: Have an interim in the coming weeks before Christmas.
* SF: Have opinions of those who are not authors if we are ready for WG last call? I think we are getting close.
* MV: Based on the reviews it looks like we could move to last call.
* SF: If you have opinions now is a good time or on the mailing list.
* GS: No strong opinion. Last call would probably trigger more reviews. We know there will some crypto reviews coming up.
* SF: Have a stable draft while the crypto community does thers analysis. Tie down as much issues as possible before the last interim and then do last call.
* Mid december interim?
* no objection
AOB

(Meeting ends at 4:32)