Hi Russ, On Thu, 19 Jun 2025 at 18:54, Russ Housley via Datatracker <noreply@xxxxxxxx> wrote: > Summary: Almost Ready > > Thanks for address the vast bulk of my comments on -14, > > Major Concerns: > > Section 8: The security consideration need to discuss the consequences > of a predictable cookie value. This will probably require a reference > to RFC 4086. A successful attack (i.e., one that lets the attacker convince the challenger to switch path) requires two conditions to be true at the same time: 1. The challenger uses a cookie that was already used in this connection, 2. The challenger does not implement anti-replay. Since anti-replay is a SHOULD in both 1.2 and 1.3, and in Section 4, third paragraph, we now say: Each message carries a Cookie, an 8-byte field containing 64 bits of entropy (e.g., obtained from the CSPRNG used by the TLS implementation, see Appendix C.1 of [RFC8446]). We thought that was enough guidance. That said, we could add something like: If the RRC challenger uses a cookie that has already been used in this connection and does not implement anti-replay protection (see Section 4.5.1 of [RFC9147] and Section 4.1.2.6 of [RFC6347]), an attacker could replay an old path_response message with the reused cookie to trick the challenger into switching to the attacker's chosen path. Therefore, RRC cookies must be obtained afresh using a reliable source of entropy [RFC4086]. The CSPRNG used by the TLS implementation (see Appendix C.1 of [RFC8446]) is a natural choice for this. WDYT? cheers, t -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
