Marco's review

[emanjon]

https://mailarchive.ietf.org/arch/msg/iotops/mb6WMP10tp_I6C80RY4hE20Ae0c/

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 Add Group Oscore (two party) to document #2 and Move repository to LWIG #3 increases with 7 bytes and the PSK numbers for
  flight DTLS 1.3 Client_Hello contains legacy_cookie (1 byte) #1 increases with 7 bytes."

  I think you mean:

  "If 8 bytes identifiers are used instead of 1 byte, the RPK numbers
  for flight Add Group Oscore (two party) to document #2 and Move repository to LWIG #3 increase of 7 bytes and the PSK numbers for flight
  DTLS 1.3 Client_Hello contains legacy_cookie (1 byte) #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 Add Group Oscore (two party) to document #2 and Move repository to LWIG #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 Add Group Oscore (two party) to document #2 and Move repository to LWIG #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 Add Group Oscore (two party) to document #2 and Move repository to LWIG #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 Add Group Oscore (two party) to document #2 and Move repository to LWIG #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)