Correct! Such a scenario is common for decentralized networks where everyone could be a client or a server (at the same time) and you don't really care who started the communication first. I'm in the middle of developing such a solution for DTLS 1.3 with the support for CIDs (RFC 9146) where record distinction is much needed.
I certainly hope this will not be overlooked in cTLS because I'm really excited about its potential. Please reconsider. Thank you, Ben. Kristijan > On 4 Jan 2023, at 15:29, Ben Schwartz <bem...@google.com> wrote: > > On Wed, Jan 4, 2023 at 7:50 AM Kristijan Sedlak <xpeperm...@gmail.com > <mailto:xpeperm...@gmail.com>> wrote: >> Hey, >> >> The record layer of the cTLS skips the "profile_id" in the >> CTLSServerPlaintext. I wonder how will an endpoint correctly distinguish >> between multiple, CID-ext-based CTLSClientPlaintext requests and >> CTLSServerPlaintext responses when the same socket is used for client and >> server communication. > > It sounds like you are thinking about cases where (1) a single 5-tuple can be > used for DTLS in both directions, (2) the parties have not already agreed who > will be the client and who will be the server, and (3) there can be multiple > handshakes in flight simultaneously. In this case, a party who sends a > ClientHello might receive a ServerHello, HRR, or a racing ClientHello in > response. This is not a use case I had thought about. Is this considered a > supported configuration for DTLS (with Connection IDs)? > >> I believe there should be a different content_type for a request and >> response or just a requirement that the response always has `profile_id=0` >> or smth. > > If we decide this use case is in-scope, I would add a content_type to > distinguish the roles. I'm interested to hear if people feel this use case > is in scope. > >> I hope I'm not reacting too fast and thus my writing makes sense. >> >> K >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org <mailto:TLS@ietf.org> >> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
