Thank you for your comments. Since I hadn't received any feedback, I shifted my focus to other issues and needed some time to revisit this topic.
I've realized that CIDs in DTLS 1.3 are loosely defined, and the more I investigate, the more I understand that this is actually very beneficial, much better than having explicit (redundant) retirement mechanisms (e.g QUIC). With a smart approach and sophisticated cryptography, CIDs as currently defined could be the optimal framework. I still need to conduct more research, but I believe that the specifications as they stand are sufficient. Sometimes, it's difficult to imagine the right solution, but overall, I think I now understand how to move forward. Thank you. Kristijan > On 16 Apr 2024, at 15:54, Tschofenig, Hannes <hannes.tschofe...@siemens.com> > wrote: > > Hi Kristijan, > > searching through the mailing list I found this mail. So, sorry for the late > response. > > The CID design in DTLS 1.3 has not been focused on multi-homing use cases. It > was not a design goal; you have to design on an extension in the style of > what is currently happening with QUIC or what was previously done with MOBIKE. > > Ciao > Hannes > > From: TLS <tls-boun...@ietf.org> On Behalf Of Kristijan Sedlak > Sent: Sunday, December 10, 2023 11:50 AM > To: <tls@ietf.org> <tls@ietf.org> > Subject: [TLS] [rfc9147] Clarification on DTLS 1.3 CID Retirement and Usage > > Dear IETF TLS Working Group, > > I am reaching out to seek clarification on specific aspects of Connection ID > (CID) management in DTLS 1.3, as detailed in RFC 9147. > > The current specification delineates the process for issuing new CIDs via a > NewConnectionId message. However, the methodology for retiring old CIDs seems > subject to various interpretations. > > Is it correct to assume that an endpoint dictates the number of active CIDs > it manages and that CIDs should be utilized in the sequence they are > provided? For example, if the initial negotiated CID is 0 and an endpoint > subsequently issues NewConnectionId with CIDs 1, 2, and 3, my interpretation > is that upon receiving the first datagram from a new path (which is also > applicable for an existing path), the records should ideally be tagged with > the next CID (1, 2, or 3) rather than CID 0. This approach suggests that upon > the reception of a higher CID, lower CIDs should be considered retired and > later removed. > > This understanding implies that CIDs in DTLS 1.3 are not designed for > multipath operations, and it is anticipated that only one path (one CID) > would be active at a given time. Could you please confirm if this > interpretation is in alignment with the intended specifications, or offer > additional insights into the appropriate management of CIDs in DTLS 1.3? > Including such clarification in the RFC would be invaluable in mitigating > potential confusion. > > Thank you. > Kristijan > <image001.gif>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
