Document: draft-ietf-tls-dtls-rrc
Title: Return Routability Check for DTLS 1.2 and DTLS 1.3
Reviewer: Russ Housley
Review result: Almost Ready
I am the assigned ART-ART reviewer for this draft. Please treat these
comments just like any other last call comments.
Document: draft-ietf-tls-dtls-rrc-14
Reviewer: Russ Housley
Review Date: 2025-06-03
IETF LC End Date: 2025-06-10
IESG Telechat date: unknown
Summary: Almost Ready
Major Concerns:
Section 4: The text says:
Each message carries a Cookie, an 8-byte field containing arbitrary
data.
In Section 7, the reader learns that is is incomplete. The cookie MUST
be unpredictable.
Section 4: In the last sentence, a MUST statement appears an a
parenthetical. Please reword. I suggest:
Implementations MUST be able to parse and understand the three RRC
message types defined in this document. In addition, implementations
MUST be able to parse and gracefully ignore messages with an unknown
msg_type.
Section 5: This seems like an odd placement of this information in the
document. I propose that this information be put in Section 3. Also,
I think there should be a MUST statement that the client MUST NOT offer
the RRC extension without also offering the CIS extension.
Section 9: The security consideration need to discuss the consequences of
a predictable cookie value. This will probably require a reference to
RFC 4086.
Minor Concerns:
Figure 2: This seems fairly complex figure to say:
Off-path and on-path attackers can:
* Inspect un-encrypted portions of datagrams;
* Inject datagrams;
* Reorder datagrams; and
* Modify portions of datagrams that are not integrity protected.
In addition, on-path attackers can:
* Delay datagrams;
* Drop datagrams; and
* Manipulate the packetization layer.
Section 11: It seems like a good time to drop this section.
Appendix A: It seems like a good time to drop this section.
Nits:
Section 1: Please spell out CID on the first use in the document body.
Section 1: s/It then goes on describing the steps a DTLS principal must/
/It also describes the steps a DTLS principal must/
Section 6.2: s/attack is more reliable if/attack is more effective if/
Figure 4: The difference between a dash and a dot is unclear.
Figures 4, 5 and 6: The purpose of lines without numbers is unclear.
Section 7: s/taken into account or not/taken into account/
Section 7.2: s/timer T, see Section 7.5, is started./
/timer T is started, see Section 7.5./
Section 7.5: s/more suitable value/more suitable value for T.
Section 9: IDnits gets confused because the Privacy Considerations and
the Security Considerations are in one section. Please avoid this
situation by separating them.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
