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)? > 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 >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
