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

[Marco Tiloca <[e-mail]>]

Hi Francesca,

Thanks, it looks good to me.

Best,
/Marco

On 2025-01-21 11:49, Francesca Palombini wrote:
>
> Hi Marco,
>
> Thank you very much for this review! I agree with your comments below 
> and have incorporated your suggested changes in the new version(just 
> posted, 
> https://datatracker.ietf.org/doc/html/draft-ietf-iotops-security-protocol-comparison-08 
> ).
>
> Detailed answers inline (but nothing controversial).
>
> Thanks,
>
> Francesca
>
> > 
>
> > 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)."
>
> > 
>
> >
>
> FP: right, we still want to keep the causality of "can lead to 
> unacceptable times due to...", so rephrased to:
>
> NEW:
>
> Too large payload sizes can easily lead to unacceptable completion 
> times due to fragmentation into a large number of frames and long 
> waiting times between sending each frame (or resending frames, 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 ... "
>
> >
>
> FP: Indeed, now as suggested.
>
> > 
>
> > [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]."
>
> > 
>
> FP: Thanks, changed as suggested.
>
> > * "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."
>
> FP: right, changed as suggested.
>
> > 
>
> > * "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]."
>
> > 
>
> FP: thanks, changed as suggested.
>
> > 
>
> > [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."
>
> > 
>
> FP: good point, but I think it is probably "increase by"
>
> > * "... 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.
>
> FP: indeed, changed.
>
> > 
>
> > * "... 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]."
>
> FP: Thanks, changed as suggested.
>
> > 
>
> > * "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."
>
> > 
>
> FP: right, I rephrased as above (but used "increased by")
>
> > 
>
> > [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."
>
> > 
>
> FP: as suggested, but kept the 64-8+1 formulation as well
>
> > 
>
> > [Section 4.1]
>
> > 
>
> > * "... , and [I-D.ietf-core-oscore-edhoc]."
>
> > 
>
> >    Like in other comments above, this should be
>
> > 
>
> >    "... ,  and Section 8 of [RFC9528]."
>
> > 
>
> FP: fixed
>
> > * 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.
>
> > 
>
> FP: agreed. Now added:
>
> OLD:
>
> The following overheads apply for all sequence numbers and Sender IDs 
> with the same length.
>
> NEW:
>
> The following overheads apply for all sequence numbers and Sender IDs 
> with the same length, and for an ID Context of zero-length.
>
> > 
>
> > [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.
>
> > 
>
> FP: Ok, I have added "and payload marker", however I have not added 
> "1-byte". I'd like the reader to understand that both the code and the 
> payload marker are encrypted.
>
> > 
>
> > [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.
>
> > 
>
> FP: Right. However I believe this was not meant to be the assumption 
> for the calculations below, but rather an example. I have rephrased:
>
> NEW:
>
> For example, if the length of the ID Context is 1 byte and the length 
> of the Sender ID is 1 byte, this adds 2 bytes to requests.
>
> > * 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
>
> > 
>
> FP: good point!
>
> > * 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
>
> FP: yes, thanks for catching this too.
>
> > 
>
> > * 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.
>
> > 
>
> FP: right, same as above.
>
> > 
>
> > [Nits]
>
> > 
>
> FP: These are all fixed now. Thank you very much!
>
> > 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
>

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