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

[Marco Tiloca <[e-mail]>]

Hi John,

On 2023-02-28 12:57, John Mattsson wrote:
>
> 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.
>

==>MT
Based on some recent discussions and avoiding to perturb 
draft-ietf-lake-edhoc at its advanced stage, version -07 of this 
document has defined the new IANA registry that you mention, see 
Sections 8.3 and 8.4.

Section 6 has also been updated accordingly, by revising the definition 
of the target attribute (now called ed-cred-t) and its use in the Web 
Link example of Figure 6.

Thanks,
/Marco
<==

>
> 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. Itshould be.
>
> - As discussed in LAKE you can get 128-bit authenticatation security 
> by combinging two 64 bit tags. Has this been discussedin CORE? Ifthe 
> mechanism gives this propertyfor either peeris 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 
> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcore&data=05%7C01%7Cmarco.tiloca%40ri.se%7Cb66eec26b61d4cd7f8f708db1982fa09%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638131822569540872%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2Bv2mnGOUTtKuwfeKkOknKwhEAC5n2RRzWCcquNeWdKc%3D&reserved=0>
>
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core

-- 
Marco Tiloca
Ph.D., Senior Researcher

Phone: [phone]

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se