Re: [Iotops] Iotdir early review of draft-ietf-iotops-security-protocol-comparison-02

[John Mattsson <[e-mail]>]

Thanks Russ,

We agree with all your comments, and we have tried to address them all in -04.

A diff from -02 to -04 can be found here:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-iotops-security-protocol-comparison-02&url2=draft-ietf-iotops-security-protocol-comparison-04&difftype=--html

Major Concerns:

>Global: The document struggles with terminology.  Each of these security
>protocols have their own terms, which make comparison more difficult.
>Figure 1 shows the size of some exchanges with three flights, yet OSCORE
>and Group OSCORE do not really fit this model.  This leads me to the
>conclusion that the document needs to start with a discussion of the
>comparison methodology.

Yes. We agree that this is likely confusing to many readers. The document already had a split between “Authenticated Key Exchange Protocols” in Section 3 and “Protection of Application Data” in Section 4. The same split exists between IKEv2 and ESP as well as DTLS-SRTP and SRTP. We have expanded the document with an explanation of the difference between an AKE and a protocol for protection of application data. We have also explained which protocols belongs to each category and which belong to both.

>Section 5: Yes, this document is purely informational.  Other purely
>informational RFCs have useful security considerations.  I agree that
>there is little to say here, but the Security Considerations of each
>security protocol could be referenced.

Fully Agree. We have significantly expanded the security considerations.

Minor Concerns:

>Section 2: I find the first paragraph hard to put in context.  First, a
>sentence of introduction to this topic would he helpful.  Why are these
>protocols being discussed at all?  I ask because the previous section
>says that "overheads are independent of the underlying transport".
>Second, i this discussion is needed at all, it might help to describe
>the overhead that is associated with the various underlying protocols,
>and then say which security protocols are used with the underlying.

This has been one of the biggest discussion topics regarding the draft in IOTOPS. Some people asked for a complete coverage of total overhead, including all underlying layers. It was decided that this was out of scope of the document but that it was good to give some information. We have now added an introduction to the underlaying layer section.

>Section 2.1: I find the section hard to put in context.  A sentence of
>introduction would he helpful.  Why is this one case explained in detail
>and the others not?

Yes. The reasons are that there was a discussion about the overhead and Marco Tiloca kindly provided the detailed text. A motivation for inclusion is that the interactions with the underlying layers are more intricate than with UPD and TCP. Agree that the section is hard to put into context. It has now been moved to an appendix.

>Section 3: References for the algorithms would be helpful.

We have now added references to the algorithms.

Nits:

>Section 3.1: It says "key/certificate identifiers included"
>(two places). I think that "key identifiers" and "certificate
>identifiers" need a few words of explanation.

We have added a sentence to explain key and certificate identifiers.

Cheers,
John Preuß Mattsson

From: Russ Housley via Datatracker <[e-mail]>
Date: Thursday, 6 July 2023 at 22:53
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Iotdir early review of draft-ietf-iotops-security-protocol-comparison-02
Reviewer: Russ Housley
Review result: Not Ready

I reviewed this document as part of the IoT Directorate's effort to
IoT-related IETF documents being processed by the IESG.  These comments
were written primarily for the benefit of the Internet Area Directors.
Document authors, document editors, and WG chairs should treat these
comments just like any other IETF Last Call comments.

Document: draft-ietf-anima-constrained-join-proxy-05
Reviewer: Russ Housley
Review Date: 2023-07-07
Review Due Date: 2023-07-24


A review from the IoT Directorate was requested on 2023-07-05.


Summary: Not Ready


Major Concerns:

Global: The document struggles with terminology.  Each of these security
protocols have their own terms, which make comparison more difficult.
Figure 1 shows the size of some exchanges with three flights, yet OSCORE
and Group OSCORE do not really fit this model.  This leads me to the
conclusion that the document needs to start with a discussion of the
comparison methodology.

Section 5: Yes, this document is purely informational.  Other purely
informational RFCs have useful security considerations.  I agree that
there is little to say here, but the Security Considerations of each
security protocol could be referenced.


Minor Concerns:

Section 2: I find the first paragraph hard to put in context.  First, a
sentence of introduction to this topic would he helpful.  Why are these
protocols being discussed at all?  I ask because the previous section
says that "overheads are independent of the underlying transport".
Second, i this discussion is needed at all, it might help to describe
the overhead that is associated with the various underlying protocols,
and then say which security protocols are used with the underlying.

Section 2.1: I find the section hard to put in context.  A sentence of
introduction would he helpful.  Why is this one case explained in detail
and the others not?

Section 3: References for the algorithms would be helpful.


Nits:

Section 3.1: It says "key/certificate identifiers included" (two places).
I think that "key identifiers" and "certificate identifiers" need a few
words of explanation.