Re: [TLS] Profile ID in CTLSServerPlaintext

I don't follow LwM2M, but DTLS-SRTP already handles this case.  See: https://www.rfc-editor.org/rfc/rfc5763#section-5 If you're aware of cases where this design does not correctly handle the situation, please surface them... -Ekr RFC 5763

Re: [TLS] Profile ID in CTLSServerPlaintext

> OK. Well, I believe that CID *can* handle this. Do you think otherwise? As I wrote in the second mail: "Sorry, too fast and unprecise." Reading the other messages in this thread, I assume, that it mainly refers to handshakes at the same time. But I missed in my first e-mail to be clear at

Re: [TLS] Profile ID in CTLSServerPlaintext

On Fri, Jan 6, 2023 at 11:43 PM Achim Kraus wrote: > > > 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

Re: [TLS] Profile ID in CTLSServerPlaintext

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

Re: [TLS] Profile ID in CTLSServerPlaintext

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

Re: [TLS] Profile ID in CTLSServerPlaintext

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

Re: [TLS] Profile ID in CTLSServerPlaintext

On Fri, Jan 6, 2023 at 9:59 AM Kristijan Sedlak wrote: > > On 6 Jan 2023, at 18:39, Eric Rescorla wrote: > > > > On Fri, Jan 6, 2023 at 9:28 AM Kristijan Sedlak > wrote: > >> > If I understand correctly, the issue here is a difference between DTLS >> and >> > "Datagram cTLS". In DTLS, the

Re: [TLS] Profile ID in CTLSServerPlaintext

> On 6 Jan 2023, at 18:39, Eric Rescorla wrote: > > > > On Fri, Jan 6, 2023 at 9:28 AM Kristijan Sedlak > 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

Re: [TLS] Profile ID in CTLSServerPlaintext

On Fri, Jan 6, 2023 at 9:28 AM Kristijan Sedlak 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 > >

Re: [TLS] Profile ID in CTLSServerPlaintext

> 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 >

Re: [TLS] Profile ID in CTLSServerPlaintext

On Fri, Jan 6, 2023, at 01:46, Ben Schwartz wrote: > 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

Re: [TLS] Profile ID in CTLSServerPlaintext

On Thu, Jan 5, 2023 at 9:37 AM Eric Rescorla wrote: ... > On Wed, 4 Jan 2023 at 17:10, Eric Rescorla wrote: >> > When would this actually happen? >> >> Assuming this could happen, then the RFC should surely mention the >> possibility, and perhaps be reworked to avoid raising an error. >> > >

Re: [TLS] Profile ID in CTLSServerPlaintext

On Thu, Jan 5, 2023 at 6:31 AM Ben Smyth wrote: > On Wed, Jan 4, 2023 at 7:50 AM Kristijan Sedlak > wrote: > > ...how will an endpoint correctly distinguish between multiple, > CID-ext-based CTLSClientPlaintext requests and CTLSServerPlaintext > responses when the same socket is used for client

Re: [TLS] Profile ID in CTLSServerPlaintext

On Wed, Jan 4, 2023 at 7:50 AM Kristijan Sedlak wrote: > ...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. On Wed, 4 Jan 2023 at 15:29, Ben

Re: [TLS] Profile ID in CTLSServerPlaintext

On Wed, Jan 4, 2023 at 12:02 PM Kristijan Sedlak 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

Re: [TLS] Profile ID in CTLSServerPlaintext

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

Re: [TLS] Profile ID in CTLSServerPlaintext

On Wed, Jan 4, 2023 at 8:34 AM Kristijan Sedlak 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

Re: [TLS] Profile ID in CTLSServerPlaintext

These types of distributed systems generally have unique node IDs that would allow tie-breaking, assigning the server and client role consistently for each pair. Would that be sufficient, or is there a need for either end to be able to initiate the connection? On Wed, Jan 4, 2023 at 11:34 AM

Re: [TLS] Profile ID in CTLSServerPlaintext

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

Re: [TLS] Profile ID in CTLSServerPlaintext

On Wed, Jan 4, 2023 at 6:30 AM Ben Schwartz wrote: > On Wed, Jan 4, 2023 at 7:50 AM Kristijan Sedlak > 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

Re: [TLS] Profile ID in CTLSServerPlaintext

Correct! Such a scenario is common for decentralized networks where everyone could be a client or a server (at the same time) and you don't really care who started the communication first. I'm in the middle of developing such a solution for DTLS 1.3 with the support for CIDs (RFC 9146) where

Re: [TLS] Profile ID in CTLSServerPlaintext

On Wed, Jan 4, 2023 at 7:50 AM Kristijan Sedlak 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

[TLS] Profile ID in CTLSServerPlaintext

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