On Wed, Jan 4, 2023 at 12:02 PM Kristijan Sedlak <xpeperm...@gmail.com> wrote:
> Thank you both. > > I agree that a signaling server would be needed for a serious p2p network > and I believe libraries such as libp2p include that plus all sorts of other > mechanics. > > Since every RFC represents a beast itself, I try not to think much about > all the machinery that usually comes in a box, but rather about a simpler > product considering only the (TLS) specs that are really needed. A small > change to the spec would allow for building a simpler p2p product with a > small and simple code base. > But this P2P product will not be viable absent some kind of NAT traversal. > In any case, I believe that protocols and related use cases, if possible, > should not depend on some external logic. Another argument is that objects > should always be deterministic since every IF sentence represents an > additional hurdle. > > Let me know if my arguments convince you. > This does not actually convince me. Rather, I think TLS should be designed to fit within the environment in which it will be deployed and not duplicate that environment's functionality and in that environment it seems to me that the roles are deterministic. If you can point me to a real world environment where this kind of tie breaker is needed, I might feel differently. -Ekr > K > > On 4 Jan 2023, at 19:06, Eric Rescorla <e...@rtfm.com> wrote: > > > > On Wed, Jan 4, 2023 at 8:34 AM Kristijan Sedlak <xpeperm...@gmail.com> > wrote: > >> Yes, I'm referring to P2P networks. >> >> Hum … let me try to explain. Imagine a group of computers discovering >> each other through Kademilia or similar. Each endpoint is required to >> connect to N remote nodes so it can then in theory access all parts of the >> network. Each endpoint uses a single socket address, communicates over UDP, >> and can accept connections or can initiate them. >> > > In my experience this is not actually how these systems work. The reason > is that those devices are > usually end-user devices and are often behind NATs, so they need to use > some protocol like > ICE to do NAT traversal. Those protocols are able to establish who is who > as part of the process. > This is how WebRTC works, for instance. > > -Ekr > > > >> A socket can serve multiple virtualized clients thus DTLS CIDs are used. >> Endpoints go live and then disappear - so you don't really know who's a >> client and who's a server. In case a connection has already been >> established by some initiator then you don't need to initiate a new >> connection when "the algorithm" requires connection establishment. >> >> I hope the above makes sense. >> > > > >> K >> >> On 4 Jan 2023, at 17:10, Eric Rescorla <e...@rtfm.com> wrote: >> >> >> >> 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
