Hi Russ,
about the cookie, let me mention, that it may be not too obvious, but
though a RRC message belongs to epoch 1 (or later), it is an regular
encrypted and MAC protected message/record. Using the same or
predictable cookie will expose the same as sending the same or
predictable message, but therefore the cipher uses a unique nonce.
If that is still an issue, then this issue would apply also to DTLS
alert records. The two bytes of an alert record may be even easier to
predict. (Maybe I miss the point.)
So, I'm not sure to see the risk here, but maybe someone in the
list can help and hopefully we can then also work on a fix for
alert-records.
To exclude some unintended attack surface in advance, refer to RFC4086
will be good idea.
br
Achim
Am 03.06.25 um 19:08 schrieb Russ Housley via Datatracker:
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.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
