Hello Thomas, The suggested changes would be enough to clear my DISCUSS (even if I do not agree completely with Achim and you ;-) ).
Regards, -éric From: Thomas Fossati <thomas.foss...@linaro.org> Date: Monday, 7 July 2025 at 09:40 To: Eric Vyncke (evyncke) <evyn...@cisco.com> Cc: The IESG <i...@ietf.org>, draft-ietf-tls-dtls-...@ietf.org <draft-ietf-tls-dtls-...@ietf.org>, tls-cha...@ietf.org <tls-cha...@ietf.org>, tls@ietf.org <tls@ietf.org>, s...@sn3rd.com <s...@sn3rd.com> Subject: Re: Éric Vyncke's Discuss on draft-ietf-tls-dtls-rrc-18: (with DISCUSS and COMMENT) Hi Éric, On Mon, 7 Jul 2025 at 07:45, Eric Vyncke (evyncke) <evyn...@cisco.com> wrote: > > Hello Thomas, > > I am afraid that the PR 97 does not completely address my concern. In short, > if there is a NAT rebinding (NAT44, NAT64, or even NPTv6), then the responder > will receive the challenge on the previous address/port even if the initiator > saw a new public/global/outside address/port. > > May I suggest in bullet 3 of section 6.2: > > s/which the message was received is still the preferred one/which the message > was received is still the preferred one or is unchanged/ > s/If the path through which the message was received is preferred/If the path > through which the message was received is preferred or has not changed/ I think I agree with Achim that amending with "or has not changed" is probably unnecessary to help drive the implementation towards making the right decision. > add somewhere in this section an explanation why the initiator may see a > change of address/port while the responder does not see any change Makes sense. Adding something along these lines would improve clarity. I have some initial text here [1] -- see diff [2]. cheers! [1] https://github.com/tlswg/dtls-rrc/pull/99 [2] https://author-tools.ietf.org/api/iddiff?url_1=https://tlswg.github.io/dtls-rrc/draft-ietf-tls-dtls-rrc.txt&url_2=https://tlswg.github.io/dtls-rrc/eric-discuss/draft-ietf-tls-dtls-rrc.txt
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
