That resolves my concern. Russ > On Jun 20, 2025, at 4:16 AM, Thomas Fossati <thomas.fossati@xxxxxxxxxx> wrote: > > 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
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
