Re: [Iotops] WGLC on draft-ietf-iotops-security-protocol-comparison-06

[Marco Tiloca <[e-mail]>]

Hi all,

I have reviewed this document and I think it's largely ready.

Please find below some suggestions for rephrasing, clarifications, and 
minor fixes.

Best,
/Marco

=============

[Section 1]

* "... and long waiting times between frames can be sent (or resent in 
the case of transmission errors)."

    I think you mean

    "... and long waiting times can be experienced between the frames 
that are sent (or resent in the case of transmission errors)."


[Section 2]

* "... when used in the combined mode with OSCORE according to ... "

   Consistent with the formulation in Appendix A, this should be

   "... when used over OSCORE with the EDHOC + OSCORE combined request ... "


[Section 3]

* "The algorithm used/offered are P-256 [SP-800-186] or Curve25519 
[RFC7748], ECDSA [FIPS-186-5] with P-256 and SHA-256 or Ed25519 
[RFC8032], AES-CCM_8, and SHA-256 [FIPS-180-4]."

    Proposed rephrasing:

    "The algorithm used/offered are: P-256 [SP-800-186] or Curve25519 
[RFC7748]; ECDSA [FIPS-186-5] with P-256 and SHA-256, or EdDSA with 
Ed25519 [RFC8032]; AES-CCM_8; and SHA-256 [FIPS-180-4]."

* "DoS protection with DTLS HelloRetryRequest or the CoAP Echo Option is 
not considered."

    Proposed rephrasing:

    "DoS protection with DTLS HelloVerifyRequest [RFC6347], or 
HelloRetryRequest [RFC9147], or the CoAP Echo Option [RFC9175] is not 
considered."

* "The choices of algorithms are based on the profiles in [RFC7925], 
[I-D.ietf-uta-tls13-iot-profile], and [I-D.ietf-core-oscore-edhoc]."

   draft-ietf-core-oscore-edhoc does not play a particular role in this 
respect. I think that a better reference about this point is simply 
Section 3.9 of RFC 9528. Proposed rephrasing:

   "The choices of algorithms are based on the profiles in [RFC7925] and 
[I-D.ietf-uta-tls13-iot-profile], and on the used EDHOC application 
profiles, see Section 3.9 of [RFC9528]."


[Section 3.1]

* "If 8 bytes identifiers are used instead of 1 byte, the RPK numbers 
for flight #2 and #3 increases with 7 bytes and the PSK numbers for 
flight #1 increases with 7 bytes."

   I think you mean:

   "If 8 bytes identifiers are used instead of 1 byte, the RPK numbers 
for flight #2 and #3 increase of 7 bytes and the PSK numbers for flight 
#1 increase of 7 bytes."

* "... and the mandatory to implement algorithms CCM_8, P-256, and ECDSA 
[I-D.ietf-uta-tls13-iot-profile] [I-D.ietf-core-oscore-edhoc]."

   Instead of draft-ietf-core-oscore-edhoc, the right reference to use 
for EDHOC is Section 8 or RFC 9528, where the mandatory-to-implement 
algorithms are defined.

* "... with 8 bytes tags which is the mandatory to implement in 
[I-D.ietf-uta-tls13-iot-profile] and [I-D.ietf-core-oscore-edhoc]."

    Like for the previous comment and with some editorial rephrasing, 
this should be

    "... with 8 bytes tags, consistent with the algorithms that are 
mandatory to implement as per [I-D.ietf-uta-tls13-iot-profile] and 
Section 8 of [RFC9528]."

* "If 16 bytes tag are used, the numbers in the #2 and #3 columns 
increases with 8 and the numbers in the Total column increases with 16."

   I think you mean

   "If 16 bytes tag are used, the numbers in the #2 and #3 columns 
increase of 8 bytes and the numbers in the Total column increase of 16 
bytes."


[Section 3.6.2]

* "Signatures increase the size of flight #2 and #3 with (64 - 8 + 1) 
bytes while x5t increases the size with 13-14 bytes."

   Actually, the increase due to signatures is (64 - 8 + 2) for 
message_3 with kid. Also, it's worth spelling out that the increase due 
to x5t is in comparison with kid.

   Proposed rephrasing:

   "For flight #2 and #3, signatures increase the message size of 57-58 
bytes, while x5t increases the size with 13-14 bytes compared to kid."


[Section 4.1]

* "... , and [I-D.ietf-core-oscore-edhoc]."

    Like in other comments above, this should be

    "... ,  and Section 8 of [RFC9528]."

* In Figures 5, 6, and 7, the overhead for a Group OSCORE pairwise 
request is 1 byte more than for the corresponding OSCORE request (i.e., 
the OSCORE request using a sequence number of the same size, or a Sender 
ID of the same size).

   This is correct, when considering a zero-length ID Context. In that 
case, the OSCORE Option for the Group OSCORE request has the 'h' flag 
bit set to 1, and consistently includes the 1-byte field 's' with value 
0 and the zero-length field 'kid_context'.

   I think it's better to explicitly write the assumption of having a 
zero-length ID Context = ''. It would also be consistent with the later, 
more detailed Section 4.7 where that assumption is indeed made explicit.


[Section 4.6]

* For each of the three messages, the text says:

   "Ciphertext (including encrypted code):"

   Based on Section 5.3 of RFC 8613, this should be

   "Ciphertext (including a 1-byte encrypted code and a 1-byte payload 
marker):"

   The overhead bytes are still correctly indicated: in these messages, 
the 1-byte payload marker within the ciphertext is the actual 
contributor to the OSCORE overhead, while the 1-byte payload marker 
before the CoAP payload of the protected message is not.


[Section 4.7]

* "Assuming 1 byte ID Context and Sender ID this adds 2 bytes to requests."

   The first part of the sentence contradicts the statement in the next 
paragraph, about assuming the zero-length ID Context = '' as intended.

   This sentence should simply be

   "Assuming the zero-length ID Context and 1-byte Sender ID, this adds 
1 byte to requests."

   This would also be consistent with the summary in Section 4.1, where 
a Group OSCORE request in pairwise mode adds 1 more byte of overhead, 
compared to the corresponding OSCORE request that has the same size of 
Sender ID and Sequence Number.

* The text says:

   OSCORE request (21 bytes, 15 bytes overhead):
   93 09 05 42

   It should say:

   OSCORE request (21 bytes, 15 bytes overhead):
   93 19 05 00 42

* The text says:

   Option Value (flag byte, ID Context length, sequence nr, Sender ID):
   19 00 05 42

   It should say:

   Option Value (flag byte, sequence nr, ID Context length, Sender ID):
   19 05 00 42

* The text says:

   "Ciphertext (including encrypted code):"

   Based on Section 5.3 of RFC 8613, this should be

   "Ciphertext (including a 1-byte encrypted code and a 1-byte payload 
marker):"

   The overhead bytes are still correctly indicated: in these messages, 
the 1-byte payload marker within the ciphertext is the actual 
contributor to the OSCORE overhead, while the 1-byte payload marker 
before the CoAP payload of the protected message is not.


[Nits]

Section 1
- s/but also high latency, and/but also by high latency and
- s/multi-hop where the/multi-hop and the
- s/CoRE (CoAP, OSCORE)/CoRE (CoAP, OSCORE, Group OSCORE)
- s/LPWAN (SCHC)/LPWAN (SCHC) and SCHC
- s/TLS (cTLS)/TLS (DTLS, cTLS)

Section 2
- s/This section give/This section gives
- s/OSCORE and Group OSCORE is part/OSCORE and Group OSCORE are part
- s/compressed with the Static Context/compressed with Static Context
- s/Use of SCHC can/The use of SCHC can
- s/and IP supports fragmentation/and IP support fragmentation

Section 3
- s/The length of key identifiers are 1 byte./The length of key 
identifiers is 1 byte.
- s/The length of connection identifiers are 1 byte./The length of 
connection identifiers is 1 byte.

Section 3.1
- s/Figure 2 compares of message sizes/Figure 2 compares the message sizes
- s/The numbers in Figure 2, Figure 2, and Figure 3/The numbers in 
Figure 1, Figure 2, and Figure 3

Section 3.2.1.1
- s/the overhead is 185/, the overhead is 185

Section 3.2.1.1
- s/the overhead is 454/, the overhead is 454
- s/ed25519 he overhead is/ed25519, the overhead is

Section 3.2.1.2
- s/RPK the overhead is 255/RPK, the overhead is 255
- s/signature the overhead is 255/signature, the overhead is 255
- s/, the overhead is 255 - 7/, the overhead is 255 - 7

Section 3.2.4
- s/can be a RPK/can be an RPK

Section 3.2.4.1
- s/X.509 the following/X.509, the following

Section 3.2.4.2
- s/X.509 the following/X.509, the following

Section 3.2.7
- s/in TLS consists of/in TLS consist of

Section 3.2.6
- s/the DTLS 1.3 flight sizes changes/, the DTLS 1.3 flight sizes change

Section 3.4
- s/on expected size/of expected sizes
- s/In TLS 1.2 the number/In TLS 1.2, the number

Section 3.5
- s/Using secp256r1 instead x25519 add/Using secp256r1 instead of x25519 
adds
- s/Using ecdsa_secp256r1_sha256 instead ed25519 add/Using 
ecdsa_secp256r1_sha256 instead of ed25519 adds

Section 3.6
- s/static Diffie-Hellman are identified/static Diffie-Hellman keys are 
identified

Section 3.7
- s/overhead of fragmentation/overhead due to fragmentation

Section 3.6.2
- s/Figure 4: Typical message sizes in bytes/Figure 4: Typical EDHOC 
message sizes in bytes

Section 4
- s/TLS 1.2 and TLS 1.3/TLS 1.2, and TLS 1.3

Section 4.1
- s/Figure 6, and {fig-overhead3}/Figure 6, and Figure 7
- s/all numbers increases with 8./all numbers increase of 8.

Section 4.2.1
- s/The nonce follow the/The nonce follows the

Section 4.2.3
- s/calculations in this section uses/calculations in this section use

Section 4.8
- s/As can be seen/As it can be seen
- s/requests with 20%/requests by 20%
- s/terminated in CoAP proxies/terminated at CoAP proxies

Section 5
- s/for respective protocol/for the respective protocol

Appendix A
- s/Assuming a that/Assuming that
- s/that CoAP Content-Format is/that the Content-Format CoAP option is
- s/the CoAP URI/that the CoAP URI
- s/URI-Path/Uri-Path  (2 instances)


On 2024-04-17 19:48, Alexey Melnikov wrote:
> Dear IOTOPS participants,
>
> This message is starting 2 weeks WGLC on 
> draft-ietf-iotops-security-protocol-comparison-06 ("Comparison of CoAP 
> Security Protocols") that will end on May 2nd 2024. If you've read the 
> document and think that it is ready (or not ready) for publication as 
> an RFC, please send a message in reply to this email or directly to 
> IOTOPS chairs ([e-mail]) If you have detailed comments, 
> these would also be very helpful at this point.
>
> As a reminder, we will park this document after WGLC until the time 
> when its depencies are stable/complete.
>
> Thank you,
> Alexey, for IOTOPS chairs
>

-- 
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