Hi, On 13 Jun 2025, at 14:34, Thomas Fossati wrote: > Hi Colin, thanks very much for your thorough review. > > On Thu, Jun 12, 2025 at 05:34:57AM +0100, Colin Perkins via Datatracker wrote: >> [...] >> >> Section 6 describes the basic and enhanced path validation procedures, >> and states that “The decision on what strategy to choose depends mainly >> on the threat model, but may also be influenced by other >> considerations. Examples of impacting factors include: the need to >> minimise implementation complexity, privacy concerns, and the need to >> reduce the time it takes to switch path. The choice may be offered as a >> configuration option to the user of the TLS implementation”. I agree >> that those factors influence the decision on what to implement, but I >> was surprised that the draft did not give clearer guidance on whether >> the basic or enhanced check was recommended. > > At present, we do not have sufficient operational experience to make a > recommendation. Okay, sure. I’d expect a new implementer to have less experience, so they might benefit from even preliminary guidance, but I’ll leave the decision to the working group. >> Section 6.3 states that the return_routability_check messages MAY be >> sent multiple times to account for packet loss. This is appropriate, >> but I would expect to see some guidance on how often and how frequently >> these packets should be resent. For example, should the initiator send >> the message when the timer expires, or after one RTT, or more often? >> Appropriate timing is likely to be application dependent, since some >> applications are more sensitive to path change latency than others, but >> some guidance (perhaps once per RTT, up to the anti-amplification >> limit?) might be appropriate. > > Great suggestion. > > https://github.com/tlswg/dtls-rrc/pull/94/commits/cfd08fac2fc4f44104f4f Look good, thanks! >> Section 6.3 states that “Each path_challenge message MUST contain >> random data”. I presume the intent is that each path_challenge message >> contains a new cookie with random contents, rather than a single random >> cookie being generated once and resent in each retransmission, but it >> would be helpful to clarify. > > Both should work fine. Okay. >> Section 6.4 states “The initiator MUST NOT enforce this behaviour”, but >> I didn’t understand how the initiator could enforce the behaviour, >> since it seems that the responder that makes the decision. Suggest to >> either remove or clarify the intent. > > Good catch! What happened is that very early in the history of the > document, we had that statement to mean that the initiator should keep > quiet if the responder was doing funky stuff (i.e., sending on another > path than the one from where it received the challenge.) To clarify it, > we added the line below: "The initiator MUST silently discard [...]" but > then forgot to remove that one :-( > > https://github.com/tlswg/dtls-rrc/pull/94/commits/d074a77565eb33d8885c8 Thanks. >> Section 6.4 states that “The initiator MUST silently discard any >> invalid path_response or path_drop it receives” – this is appropriate, >> but I wonder what would happen if another NAT rebinding occurred while >> the check was ongoing, such that the path_response arrived from neither >> the original address nor the new address but rather from a third >> address? Would this be counted as invalid, would it move the path to >> the third address, or would it trigger another check? > > The current algorithm is not designed to handle nested rebindings. > If this occurs (hopefully rarely), the path_response message is dropped, > and path validation eventually times out. The address is not updated, > and a new path validation will be triggered when new data is received. I’d also expect this to be an uncommon occurrence, so there’s likely to need to optimise the behaviour further. It might be helpful to include the above explanation though, just to be clear that the protocol doesn’t fail in that case? >> In Section 6.5, clarify whether the “active path” refers to the old >> path or the new path. > > It's the old. > > https://github.com/tlswg/dtls-rrc/pull/94/commits/43ff37957017e123ee154 > > > You can take a look at the rfcdiff of the cumulative changes here: > https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-tls-dtls-rrc&url_2=https://tlswg.github.io/dtls-rrc/tsvart/draft-ietf-tls-dtls-rrc.txt > > cheers, thanks again! Thanks! Cheers, Colin -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
