Subject: Re: [Lake] EDHOC Review

From: Göran Selander <[email-masked]>
Date: Tue, 14 Dec 2021 13:52:20 +0000

Hi Kathleen,

Thanks for the review. It is recorded as github issue #196 and the updates have already been integrated in the master branch:
https://github.com/lake-wg/edhoc/commit/a4b182a
except for the last comment:

> IANA Registries
>
> I see for the registries created that Expert review [RFC8126] is required. 
> What documentation is required? Is it also Specification required or is 
> here other guidance for the experts when considering updates? 
> I see this is discussed in 9.14, but perhaps adding specification recommended 
> in each of the places a registry is created would be helpful.

We discussed documentation at the Oct 5 interim  and the conclusion was that expert review would be sufficient as a general scheme for these registers (see also github issue #167 [0] which was therefore closed). But your comment made us take another look at the registers. In particular for the EDHOC method type registry it does really make sense to require a specification. Therefore we reopened the issue and will revisit the topic on the interim meeting tomorrow.

[0] https://github.com/lake-wg/edhoc/issues/167

Thanks!
Göran
________________________________________
From: Lake <[email-masked]> on behalf of Kathleen Moriarty <[email-masked]>
Sent: Friday, November 5, 2021 8:36 PM
To: [email-masked]
Subject: [Lake] EDHOC Review

Greetings!

I had offered to contribute a review at the last interim and am very glad to see this document come to this part of the process after the large efforts that went into its development and demonstrating it's value for use with constrained devices.

Here are a few nits to consider:

Section 1.1 Nit

OLD:

EDHOC does

   currently not support pre-shared key (PSK) authentication as

   authentication with static Diffie-Hellman public keys by reference

   produces equally small message sizes but with much simpler key

   distribution and identity protection.

NEW:

EDHOC does not

   currently support pre-shared key (PSK) authentication as

   authentication with static Diffie-Hellman public keys by reference

   produces equally small message sizes but with much simpler key

   distribution and identity protection.

Section 1.2:

The intent of the following sentence is to convey that these libraries are already in use for OSCORE, but the wording of the following sentence could be a bit more clear:

OLD:

By reusing existing libraries, the additional code size can be kept very

   low.

PROPOSED:

In using libraries already in the code base for OSCORE, the additional code size can be kept very

   low.

Section 3.8

S/enrolment/enrollment/

Section 4.3

S/kan/can/

In the following sentence: in most encryption algorithms the same key kan be

IANA Registries

I see for the registries created that Expert review [RFC8126] is required. What documentation is required? Is it also Specification required or is there other guidance for the experts when considering updates? I see this is discussed in 9.14, but perhaps adding specification recommended in each of the places a registry is created would be helpful.

Thank you for your work on this document and protocol!

--

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 14 Dec 2021 11:33:34 -0500

Thank you, Goran!  Congratulations, it's great to see the work at this
point.

Best regards,
Kathleen

On Tue, Dec 14, 2021 at 8:52 AM Göran Selander <[email-masked]>
wrote:

> Hi Kathleen,
>
> Thanks for the review. It is recorded as github issue #196 and the updates
> have already been integrated in the master branch:
> We discussed documentation at the Oct 5 interim  and the conclusion was
> that expert review would be sufficient as a general scheme for these
> registers (see also github issue #167 [0] which was therefore closed). But
> your comment made us take another look at the registers. In particular for
> the EDHOC method type registry it does really make sense to require a
> specification. Therefore we reopened the issue and will revisit the topic
> on the interim meeting tomorrow.
>
> I had offered to contribute a review at the last interim and am very glad
> to see this document come to this part of the process after the large
> efforts that went into its development and demonstrating it's value for use
> with constrained devices.
>
> The intent of the following sentence is to convey that these libraries are
> already in use for OSCORE, but the wording of the following sentence could
> be a bit more clear:
>
> OLD:
>
> there other guidance for the experts when considering updates? I see this
> is discussed in 9.14, but perhaps adding specification recommended in each
> of the places a registry is created would be helpful.
>
>

-- 

Best regards,
Kathleen