Please consider adding a section in the RFC itself where valid and invalid use cases, or at least "must be supported" cases, are clearly documented. Otherwise, each (D)TLS implementation might be slightly different. For example, a paragraph in the RFC could say that an implementation must implement cases 1 and 2 (by Eric) but not case 3, and could further explain other valid and invalid cases. It's obvious to me now that though it's theoretically possible to do something doesn't always mean it should be supported by an implementation. Thx.
-Kristijan > On 7 Jan 2023, at 09:13, Achim Kraus <achimkr...@gmx.net> wrote: > > Sorry, too fast and unprecise. > > Corrections: > > At retry it's unlikely, that both peers start the handshake at the same > time. > > > > 2. A single server serving multiple clients, where the clients > share an > > > address. > > > > Not sure, if "address" is just the ip-address or the ip-address and > > service port. For the first it works in DTLS 1.2 CID, if the clients > > have different service ports. For the second it may depend on the > > implementation. My implementations of DTLS 1.2 CID don't support that. > > That refers to a handshake at the same time. For handshakes at different > times or later traffic that's supported. > > best regards > Achim > > Am 07.01.23 um 08:43 schrieb Achim Kraus: >> Not sure, if some DTLS 1.2 history helps. Hope, it doesn't mix up more. >> >> DTLS role exchange was an topic in DTLS 1.2. >> It was in discussion in LwM2M. >> >> > 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. >> >> In DTLS 1.2 that causes race conditions and the easiest way out was >> to abandon the handshake and retry it with a random timeout. At retry >> it's unlikely, that both peers start the handshake. >> >> > 2. A single server serving multiple clients, where the clients share an >> > address. >> >> Not sure, if "address" is just the ip-address or the ip-address and >> service port. For the first it works in DTLS 1.2 CID, if the clients >> have different service ports. For the second it may depend on the >> implementation. My implementations of DTLS 1.2 CID don't support that. >> >> > 3. A single endpoint acting as both client and server on the same >> address. >> >> See the DTLS 1.2 role exchange discussion in LwM2M. >> Even if a "central server" is used, there are corner cases, when >> such a "DTLS 1.2 role exchange" seems to be the only escape. A >> NAT will frequently block that, but sometimes it may succeed. >> (I don't use this approach, but others may do.) >> >> best regards >> Achim >> >> >> Am 06.01.23 um 23:17 schrieb Eric Rescorla: >>> >>> >>> On Fri, Jan 6, 2023 at 9:59 AM Kristijan Sedlak <xpeperm...@gmail.com >>> <mailto:xpeperm...@gmail.com>> wrote: >>> >>> >>>> On 6 Jan 2023, at 18:39, Eric Rescorla <e...@rtfm.com >>>> <mailto: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. >>> >>> >>> There are three things going on here, not two. >>> >>> 1. A single server serving multiple clients, where the clients have >>> different addresses. >>> 2. A single server serving multiple clients, where the clients share an >>> address. >>> 3. A single endpoint acting as both client and server on the same >>> address. >>> >>> DTLS allows (1) by default (2) with CID, and not (3). >>> >>> -Ekr >>> >>> >>>> -Ekr >>>> >>>> >>>> -Kristijan >>> >>> >>> _______________________________________________ >>> 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
