Adding to the response: As with all TLS extensions, if endpoint A depends on a feature but endpoint B does not support the feature then the exchange has to be terminated.
CIDs are not different from other extensions. It is, however, quite likely that an application will still work without the CID in a given scenario but efficiency might suffer. Ciao Hannes From: TLS <tls-boun...@ietf.org> On Behalf Of Eric Rescorla Sent: Friday, December 9, 2022 3:28 PM To: Kristijan Sedlak <xpeperm...@gmail.com>; <tls@ietf.org> <tls@ietf.org> Cc: architecture-disc...@ietf.org Subject: Re: [TLS] [arch-d] Question regarding Connection ID (CID) in DTLS /QUIC. 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<mailto: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 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
