Got it, thank you. I got a feeling that CIDs could be somehow different since the extension represents a sort of "core" functionality.
Kristijan > On 9 Dec 2022, at 15:56, Hannes Tschofenig <hannes.tschofe...@arm.com> wrote: > > 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
