On Wed, Jan 4, 2023 at 6:30 AM Ben Schwartz <bemasc= 40google....@dmarc.ietf.org> wrote:
> On Wed, Jan 4, 2023 at 7:50 AM Kristijan Sedlak <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)? > When would this actually happen? In my experience the only situation in which there is ambiguity about who will be the client and the server are p2p-style applications and those need ICE for NAT traversal, so you already have a way of determining who is who. -Ekr > > >> 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 >> https://www.ietf.org/mailman/listinfo/tls >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
