This question should go to the TLS mailing list, not to architecture-discuss. I have CCed that list.
On Fri, Dec 9, 2022 at 3:02 AM Kristijan Sedlak <xpeperm...@gmail.com> wrote: > Hello, everyone. > > I'm scratching my head on RFC 9146 and wonder about the correct > implementation strategy. Connection IDs in DTLS 1.3 are not mandatory and > thus leave related challenges to the implementor. > > As I understand DTLS 1.3 allows endpoints to choose whether to support > ConnectionId extension or not. If the sender includes ConnectionId > extension in the ClientHello, the receiver knows that CIDs are supported > and it can include its CID in the ServerHello, but if the receiver does not > support the extension it will not include it in the ServerHello and the > sender will get that info. > > What should we do if an endpoint features depend on CIDs but the targeting > peer does not support the CID extension? Let's say that the sender will > reuse the socket (ip:port) and serve multiple standalone "connections" > through it (N ClientHello messages will start N connections over the same > socket and the peer needs to use CIDs to distinguish between them) and thus > require the remote endpoint to support CIDs? Should an endpoint (sender or > receiver) that requires CIDs reply with unsupported extension alert? If you need connection ids and the peer doesn't support them, you should probably terminate the connection with a "handshake_failure" alert. Alternately, you could only allow one connection at a time. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
