Re: [Lake] [core] 🔔 Working Group Last Call (WGLC) of draft-ietf-core-oscore-edhoc-06

[John Mattsson <[e-mail]>]

One more comment:

   *  'cred-t', specifying a type of authentication credential supported
      by the server.  This parameter MUST specify a single value, and
      possible values are: "x509", for X.509 certificate [RFC5280];
      "c509", for C509 certificate [I-D.ietf-cose-cbor-encoded-cert];
      "cwt" for CWT [RFC8392]; "ccs" for CWT Claims Set (CCS) [RFC8392].
      This parameter MAY occur multiple times, with each occurrence
      specifying a different authentication credential type.

I think this should be made into an IANA registry under "Ephemeral Diffie-Hellman Over COSE (EDHOC)". The registry could be created by the EDHOC document or draft-ietf-core-oscore-edhoc.

Cheers,
John


From: Lake <[e-mail]> on behalf of John Mattsson <john.mattsson=[e-mail]>
Date: Saturday, 25 February 2023 at 18:22
To: Carsten Bormann <[e-mail]>, Christian Amsüss <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Lake] [core] 🔔 Working Group Last Call (WGLC) of draft-ietf-core-oscore-edhoc-06
Hi,

I have reviewed draft-ietf-core-oscore-edhoc-06. I think it is ready with issues.

- "Profiling EDHOC for CoAP and OSCORE"
  Not sure this is a suitable name. It does not really profile EDHOC.

- OLD "first subsequent OSCORE transaction" (several occurences)
- NEW "first OSCORE transaction"
  it is not subsequent anymore

- "CoAP [RFC7252], CBOR [RFC8949], CBOR sequences [RFC8742], OSCORE
   [RFC8613] and EDHOC [I-D.ietf-lake-edhoc]."
  IETF uses the Oxford comma. (Probably several occurences).

- "may be set to application/cid-edhoc+cbor-seq." (several occurences)
  Any reason this is not a normative MAY, also what is the reason for not have SHOULD or SHALL? I don’t have a strong opinion.

- OLD "not transported precisely in the request payload."
- NEW "not transported in the request payload."
But probably better to just say "as specified in Section 3.2, C_R is transported in the OSCORE Option."

- "using the new OSCORE Security Context established after receiving EDHOC message_2."
I think this should be "after creating EDHOC message_3" The context depends on message_3.

- "Check that the EDHOC + OSCORE request includes the OSCORE option
   and that the request payload is a CBOR sequence composed of two
   CBOR byte strings."
   Should check for the EDHOC option as well

- The document is not clear on if you can send back an EDHOC error over OSCORE or not. It should be.

- As discussed in LAKE you can get 128-bit authenticatation security by combinging two 64 bit tags. Has this been discussed in CORE? If the mechanism gives this property for either peer is should be mentioned.

- Is is clear what happens if the EDHOC + OSCORE Request is retransmitted?

- "where the ID Context has zero-length."
This seems wrong. There is nothing special with the zero-length ID Context.
This should be "where the ID Context is not present"

- 'ead1', 'ead2', 'ead3' and 'ead4'
  This makes no sense to me. Either you support EAD or not. Also knowing that the other party support EAD is useless. You need to know what kind of EAD. I stongly think this should use values from the EDHOC External Authorization Data Registry.

Cheers,
John

From: core <[e-mail]> on behalf of Carsten Bormann <[e-mail]>
Date: Wednesday, 15 February 2023 at 23:39
To: Christian Amsüss <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [core] [Lake] 🔔 Working Group Last Call (WGLC) of draft-ietf-core-oscore-edhoc-06
On 15. Feb 2023, at 23:25, Christian Amsüss <[e-mail]> wrote:
>
> * 3.2 step 3: "The first CBOR byte string is the EDHOC message_3

Ah.

We are using the term “byte string” to describe the generic data model data item with that name (using major type 2 and enclosing a sequence of bytes into a single data item).

We are using the term “encoded CBOR data item” to describe the sequence of bytes that results from encoding a CBOR data item (any CBOR data item of course, not just a byte string).

So where the byte string is h’010203’, the encoded CBOR data item encoding that data item is 43010203 hex.
The latter, of course, can be carried in another byte string h’43010203’, which would then be encoded as 4443010203 hex.
So it is really important not to confuse “CBOR byte string” with “encoded CBOR data item”.

(Of course, this distinction applies to any representation format that can carry its own encodings, as in the JSON text

    “{\”a\”: 1, \”b\”: 2}”

which is obviously not the same as the JSON text

    {“a”: 1, “b”: 2}

In JSON this kind of embedding is rather expensive and thus done less often, while in CBOR embedding encoded data items in byte strings is a rather natural way to carry certain kinds of information.)

Grüße, Carsten

_______________________________________________
core mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/core