Lightweight Authenticated Key Exchange (LAKE) - Interim Meeting

Tuesday, June 1st, 2021 -- 12:00 - 14:00 UTC

Chairs:

Mališa Vučinić
Stephen Farrell

Present

Mališa Vučinić, Inria (MV)
Stephen Farrell, TCD (SF)
Carsten Bormann, TZI (CB)
Marco Tiloca, RISE (MT)
John Preuß Mattsson, Ericsson (JM)
Rikard Höglund, RISE (RH)
Francesca Palombini (FP)
Ira McDonald, High North Inc (IM)
Göran Selander, Ericsson (GS)
Dominique Barthel, Orange (DB)

Useful Links:

Agenda:

Administrivia and Agenda Bash -- chairs, 5 mins
Interop Report -- Marco Tiloca, 5 mins
EDHOC Open Issues -- Göran Selander & John Mattsson, NN mins
AOB

Actions Points

MV: (Regarding to what draft text on e.g. key derivation to have in I-D.ietf-core-oscore-edhoc or the EDHOC draft.) Check the EDHOC draft and propose a version that follows the LAKE charter. Continue discussions on the Github. Re-open issue number 75. Note: the latest editor's copy for draft-ietf-core-oscore-edhoc is available at the Github branch: https://github.com/core-wg/oscore-edhoc/tree/id-conversion . See especially Sections 3 and 4.3 for the (extended) content taken from the EDHOC document. Other subsections in Section 4 include anticipated changes related to Connection Identifiers, and how to handle them when EDHOC is used to key OSCORE.
CB: Bring up ordering/non-ordering of CWTs with authors of the relevant draft.
MV: Ping the mailing list, pointing to PR 117 and saying that comments are welcome. Also mention PR 122.
GS: Make replacement considering bstr_identifier to bstr/int (PR 122). Consensus to do this. But give a 2 week window.

Minutes:

Administrivia and Agenda Bash (chairs, 5 mins)
- note well
- agenda bashing
Interop Report (Marco Tiloca, 5 mins)
- Short report from round 5 of EDHOC testing.
- Three implementations tested (none brand new)
- Implementations from Marco, Christian Amsüss/Timothy Claeys and Lidia Pocero
- Around 10 people attended
- Results available in Google Docs.
- Testing pairs
  - Marco - Christian, Christian - Lidia
- Next steps are waiting for version 8 of the draft (with possibly new test vectors released then. Then plan for the next interop event.
- MV: Is Lidia's work merged into the official Contiki-NG? MT: As far as I know it is not merged.
EDHOC Open Issues (Göran Selander & John Mattsson)
- Showing an overview of changes between version 06 and 07.
  - Test vectors have not yet been updated.
  - Changed the transcript hash definition TH_2 and TH_3
  - Removed one item from the cipher suite
  - New context parameter in EDHOC-Exporter, and IANA registry.
  - Moved derivation procedure for OSCORE to other draft (draft-ietf-core-oscore-edhoc).
    - MV: We are now loosing the link between OSCORE and EDHOC. Is this good from a strategic point of view for the working group?
    - JM: I suggested some part could be moved to this core document instead.
    - MV: So the other draft covers how to transport OSCORE in EDHOC, and its scope became extended? I think the derivation of OSCORE master secret/salt should be kept within LAKE.
    - SF: What is the progression of that draft? I-D.ietf-core-oscore-edhoc
    - MT: We expect it to grow with further material. Like material on EDHOC CID<->OSCORE KID translation.
    - GS: This section 7.2.1 could be in either draft. So the key derivation can remain here.
    - JM: I agree, but keep CoAP-specific things discussed in the draft in CoRE.
    - MV: I take an action on me to check the draft and propose a version that follows the LAKE charter. We continue discussions on the Github. Re-open issue number 75.
    Note: The latest editor's copy for draft-ietf-core-oscore-edhoc is available at the Github branch: https://github.com/core-wg/oscore-edhoc/tree/id-conversion . See especially Sections 3 and 4.3 for the (extended) content taken from the EDHOC document. Other subsections in Section 4 include anticipated changes related to Connection Identifiers, and how to handle them when EDHOC is used to key OSCORE.
  - Change in normative language for sending errors
  - Made error-codes non-negative
  - Details on success error code
  - Appendix about compact EC point representation
  - Change "protocol instance"->"session"
  - Rename "Auxiliary Data"->"External Authorization Data". Intended for a specific purpose for instance auth Tokens.
  - Added EAD_4 to message_4
  - Further security considerations like about DoS, fake message, TEEs
- Going over specific open issues
  - See https://github.com/lake-wg/edhoc/issues
  - Four "classes": RPK by value, correlation/message format/size, conn and key identifiers, inner MAC
  - What to transport and with what COSE header for CRED_x when using non-PKI (RPK by value)?
    - 4 solution candidates presented (plain COSE_key, CWT, self signed C509/COSE_Sign-CWT, C509 without signature).
    - CB: There is a useful draft for "naked" CWT claims sets you may want to take a look at. (https://datatracker.ietf.org/doc/draft-ietf-rats-uccs/)
    - JM: This was presented during the COSE WG interim. Some people suggested using CWTs.
    - MV: What about message overhead?
    - JM: CWT claims list and C509 without signature should be same size.
    - MV: Could we propose own structure in COSE for this use case?
    - JM: I think you want flexibility from CWT. Would be good to have further size calculations. I suggest making a COSE header that can carry a full CWT or claims list. To CB, does the CWT include a deterministic CBOR encoding or do you need to add on top? CB: You need to include that.
    - GS: Can we define in the header that it is to be deterministic? (It needs to be deterministic due to inclusion in the AAD).
    - CB: Using CWT and deterministic should do this. We may want to get rid of non-ordered CWTs in general (this is legacy inherited from JSON).
    - GS: CB can you take this up with authors? Can you also define the header?
    - CB: Yes for the first, for the second I can at least review it.
    - JM: To summarize the idea is to define a COSE header parameter for CWT, or claims list only CWT (or 2 different header params).
    - GS: And deterministic encoding should be part of definition.
  - Correlation parameter in EDHOC messages that allow omitting connection identifiers (depending on the correlation value)
    - Recent suggestion is to take out the correlation parameter from EDHOC and move to a "shim layer"." See https://github.com/lake-wg/edhoc/pull/117
    - MV: I went through the PR and it does simplify the specification. I think it is a good change. But want to make sure we don't lose some security properties or introduce vulnerability by removing the connection identifiers (CID) from cryptographic protection. Can this be security relevant?
    - JM: I think not, it is more about simplifying the protocol. Removing them shouldn't be a problem. Already today some correlation methods mean not using any CIDs. C_I and C_R (CIDs for initiator/responder) are in fact integrity protected.
    - GS: Shall we set a date? MV: 2 weeks? GS: Sounds good. MV: Let's ping the mailing list
  - Message sizes
    - Current proposed changes if applied will add 1 byte to the message minimum size. Worked on recap of target messages sizes. See spreadsheet with sizes in https://github.com/lake-wg/edhoc/issues/103
    - What is the tradeoff between encoding complexity and adding bytes?
    - MV: For 6TiSCH we consider 5 nodes in linear topology. 45 bytes has a lot of assumptions on network settings (see spreadsheet). Not meeting 45 byte in message would mean fragmentation, would not prevent protocol from running. For smaller networks with 4 nodes it would fit. No strong opinion if we should overoptimize for this use case.
    - SF: Those limits are one reason compressed TLS "lost the argument"? So we should factor that in. MV: Yes if we now change this from hard to soft limit it can raise questions.
    - JM: Optimizations using concatenation and some things in the ciphertext can reduce overhead.
    - GS: Adding single bytes still leaves us lower than the compressed TLS values. But may raise questions still.
    - JM: Should we do concatenation to save 1 more byte?
    - MV: We should park this issue until the spec is frozen, then we can see what needs to be done to meet the hard limit. Makes sense? JM: Yes. GS: Can we take this during an interim? We want decision by September. SF: When we reach last call, discuss if there are more bytes to squeeze out. GS: Or if it will be fine to add bytes. Sounds good.
  - Compact identifiers
    - Currently byte strings are transformed to integers in some situations (for CID and KID ID_CRED). Representing CBOR bstr as CBOR int can save bytes. Feedback has been giving that it is an overoptimization, and complicated. Suggestion to instead define these values as bstr or int (no transformation bstr->int). See https://github.com/lake-wg/edhoc/pull/122
    - Mapping issue still exists to OSCORE Sender IDs. This material is now in draft-ietf-core-oscore-edhoc.
    - CB: Replacing bstr_identifier with bstr/int doesn't change this. More relevant is the transformation, saying int increases potential values. Protocols using EDHOC can put constraints on the int or bstr values allowed. This flexibility seems useful.
    - GS: Are we in favor of making this replacement? (No objections) We can give time and allow for comments. So there is consensus to do this. MV can mention this in the mail to the mailing list also.
  - Simplify MAC calculation
    - Inner MACs currently using COSE_Encrypt0 can be replaced with EDHOC-KDF invocation. This makes things simpler and helps when using coming COSE AEADs without MAC. See https://github.com/lake-wg/edhoc/pull/123
    - JM: EDHOC has quite small MACs, allowing bigger is good. Considering comparison with TLS for instance.
    - MV: Should consider security implications, sounds good as a simplification. How would it increase security?
    - JM: By increased MAC length. (Which is signed but not sent). Makes it more aligned with TLS.
  - Cipher suites
    - 3 questions. 1. Does it make sense to have 4 different CCM-based cipher suites? 2. Define a suite with ChaCha20-Poly1305? 3. Is the CNSA suite fine with a 2 byte value (instead of 1)?
    - GS: Proposal is to change CSNA to 2 byte value, and define a suite with ChaCha20-Poly1305 (with SHA-256, X25519, EdDSA).
    - MV: I agree on the 2 byte value. About ChaCha20 I got a question from RIOT OS developers, we should add this. Why not add ChaCha20 suit with NIST curves? (I suggest adding both for EdDSA and NIST curves) I think it's worth having the 4 different CCM-based suites (let's keep as is and look for input).
    - IM: (In chat) I agree that all four cipher suites should be kept for now. If any are removed, that should be a result of IETF Last Call and security reviews (but not LAKE WG Last Call).
AOB
- Nothing brought up
- IETF 111 coming end of July, no session scheduled yet.
- The next meeting during IETF 111. No objections.