Hello Thomas, I still need to think more about your PR about the Med’s point, which is related to my DISCUSS. As I am taking a day off this Friday, this will be for Monday.
Else, I like your PR[1] as it addresses many of my comments. Still suggest to either remove “AP” from figures or be clear in the text. Regards -éric From: Thomas Fossati <thomas.foss...@linaro.org> Date: Thursday, 3 July 2025 at 19:54 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, this PR [1] should address your COMMENTS, in line with my replies below. cheers, t [1] https://github.com/tlswg/dtls-rrc/pull/98 On Thu, 3 Jul 2025 at 17:49, Thomas Fossati <thomas.foss...@linaro.org> wrote: > > Hi Éric, thanks a lot for your review and comments. > > Please see the replies below and let us know what you think. > > cheers! > > On Thu, Jul 03, 2025 at 05:11:45AM +0100, Éric Vyncke via Datatracker wrote: > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > ## DISCUSS (blocking) > > > > ### Section 6.2 > > > > In the case of NAT rebinding, how can a responder behind a NAT detect > > that its external address/port has changed as seen by the initiator: > > it still receives the other peers packet sent to its unchanged > > address/port ? What am I missing ? > > > > This could probably be addressed by some more text before `The action > > to be taken depends on whether or not the path through which the > > message was received is still the preferred one`. > > This looks very similar to Med's comment "Impossibility to adhere with a > MUST". > > Can you please have a look at the discussion (sub)thread at [1] and the > proposed fix [2]? > > If we are lucky we may have already solved this :-) > > [1] https://mailarchive.ietf.org/arch/msg/tls/JyslZqlHwQFdCo0mmBiQvo_6wmI/ > [2] https://github.com/tlswg/dtls-rrc/pull/97/commits/03935ba17 > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > ## COMMENTS (non-blocking) > > > > ### FATT process ? > > > > Out of curiosity, I still wonder what `FATT process` and `FATT review` mean > > in > > the shepherd write-up. > > FATT is TLS's formal analysis triage panel. See [3]. > > [3] https://github.com/tlswg/tls-fatt/tree/main > > > ### Use of "path" > > > > Probably too late to change, but the choice of "path" rather than "anchor" > > or > > "socket" (or something else) is poor... the actual path (the set of network > > links and devices) keeps changing in an IP network. > > Yes, in hindsight I can see that this wasn't an ideal choice. It seems > a bit too late now to go back and do a terminology revamp. Hopefully, > this won't create too much confusion. > > > ### Section 1 > > > > A small graphical (packet exchange) would be useful even if the text is > > clear. > > Perhaps we could add a forward link to the "Example" section. > > > ### Section 3 > > > > What is the expected server behavior when the client sends the rcc extension > > without offering the connection_id extension ? Is the whole handshake > > stopped > > or is the option ignored ? Please be specific. > > The server will not echo the rrc extension. > > > ### Section 4 > > > > Probably due to my lack of familiarity with the used syntax, but it seems > > that > > the enum part is not really part of the figure 1 legend of `Return > > Routability > > Check Message`. It seems more like an addition to TLS Content Type registry. > > Suggest to split this figure in two figures with 2 distinct legends. > > I like the fact that all the relevant TLS presentation language is > packed together. Rather than splitting the figures, I'd slightly extend > the legend to read "Return Routability Check Message and Content Type". > > > ### Section 5 > > > > s/has faster routing/has faster forwarding/ ? > > In the editor's copy we currently have "faster fowarding path". Would > that work for you? > > > ### Section 5.1.1 > > > > Related to `the original packet still reaches the intended destination`, > > does > > this mean that an attacker can prevent rebinding to a new address/port by > > sending the packet from the 'old' address/port ? > > Not really. We assume that an attacker does not posses the session key > material necessary to forge a valid path_response that would convince > the peer to rebind. > > > ### Section 5.2.1 > > > > What is "AP" in figures 5 and 6? > > Access Point. > > > ### Section 10.2 > > > > As this section ends with a recommendation, should it clearly be in > > the protocol specification part rather than in operational > > considerations ? > > Another approach might be to provide more context for the > recommendation. For example: > "Therefore, when using RRC in DTLS 1.2 *and middlebox interference is a > concern*, it is recommended that CID is enabled in both directions." > > t
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
