> On 6 Jan 2023, at 18:39, Eric Rescorla <e...@rtfm.com> wrote: > > > > On Fri, Jan 6, 2023 at 9:28 AM Kristijan Sedlak <xpeperm...@gmail.com > <mailto:xpeperm...@gmail.com>> wrote: >> > If I understand correctly, the issue here is a difference between DTLS and >> > "Datagram cTLS". In DTLS, the syntax allows a client to parse handshake >> > messages from the server and discover that the message is actually a >> > ClientHello. I don't know that this is a good idea, or actually >> > implemented anywhere, or even formally "allowed", but it's at least >> > syntactically possible. >> >> Yes. >> >> > In Datagram cTLS (as of -07), this is not possible. The parsing of >> > handshake messages depends on prior knowledge of who is the client and who >> > is the server. This is because CTLSServerPlaintext and CTLSClientPlaintext >> > are different structs, but they use the same ContentType. >> >> OK, "prior knowledge" explains everything :). I assumed all structures >> should be parsed as unique objects. >> >> RFC9146 and RFC9147 somehow confused me and made me think that by using CIDs >> it's allowed to reuse sockets A and B and then handle multiple connections >> through a single path. In that case you would have clients and servers on >> both sides. Inputs from this thread suggest that CIDs are meant for "NAT >> rebinding" purpuse only. > > Hmm, no, I don't think that's quite true. A server can serve multiple clients > on the same 4-tuple using the CID. It's just that it will not generally act > as a client.
For sure, a server can serve multiple clients on the same address :). What I meant is that, isolated to a single path, an endpoint (A or B) should only be a server or a client, not both at the same time. So a single "ip:port" is not supposed to “initiate”/"run" multiple isolated servers and clients at the same time. > -Ekr > >> >> -Kristijan
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
