FWIW, I did not read Watson's comment in any negative way and agree with him. (And everyone else. I think my feelings are "meh, let's just fix it" and "sure, whatever we can get".)
Not to say that every implementor would have noticed every issue (I'm sure I overlooked some issues too), but I think DTLS's biggest challenge has always been the relatively little attention it receives compared to TLS. This is exacerbated by the kinds of things we need attention on. While the security, cryptography, and handshake bits (this WG's forte), more-or-less carry over as-is, it picks up a whole mess of transport-related concerns that just don't apply to TLS. And then there's also a wide range of possible implementations, depending on the simplifying assumptions you make (e.g. refusing to have multiple outgoing post-handshake flights active at once). That, in turn, means that a reader might not have bothered thinking about the more complex case, if they didn't mean to implement it. (On my end, I don't expect we'll implement everything in here either!) While I think this WG's analysis (formal and otherwises) are mostly on security properties, the issues I found are mostly making sure the protocol can make forward progress under packet loss/reordering. But also whether the text sufficiently defines the protocol at all. For example, it's quite common for DTLS implementations to take these simplifying assumptions, but all that actually needs to be written down as allowed behavior, because it means that, when we analyze the protocol, receivers must accommodate a sender that, say, artificially block sending one flight on the ACK of another one. The remedy for all that is, well, more eyes on it, which we get by having the WG take on a bis document. :-) Beyond that, whether we need implementers, formal analysis, or just people reading and reasoning through the draft, I think we just welcome anyone who is interested in doing that work and go forth. All three sources of feedback ultimately involve a human reading the document and trying to understand what it's trying to say anyway, which I think is the biggest gap here. Once we even know what our protocol is, if there are folks available to model that and formally check a forward-progress property (rather than a security property), awesome! If not, we can resort to traditional "think very hard about it" techniques. I don't think we need to preemptively worry about which options we'll have available when we get there. On Wed, Nov 13, 2024 at 12:10 PM Andrei Popov <Andrei.Popov= 40microsoft....@dmarc.ietf.org> wrote: > David’s analysis is excellent; as a likely future implementor of DTLS 1.3 > I’m glad these spec bugs have been discovered. To what extent formal > analysis would be helpful here is not obvious. > > > > I don’t recall: did we have interoperable implementations prior to > shipping the DTLS 1.3 spec? > > > > Cheers, > > > > Andrei > > > > *From:* Muhammad Usama Sardar <muhammad_usama.sar...@tu-dresden.de> > *Sent:* Wednesday, November 13, 2024 3:30 AM > *To:* Watson Ladd <watsonbl...@gmail.com>; Russ Housley < > hous...@vigilsec.com> > *Cc:* Joseph Salowey <jsalo...@gmail.com>; IETF TLS <tls@ietf.org> > *Subject:* [EXTERNAL] [TLS] Re: DTLS 1.3 bis > > > > On 12.11.24 23:52, Watson Ladd wrote: > > I think anyone implementing would have discovered them. > > Is David Benjamin the *first* and *only* person in the world implementing > DTLS 1.3? If not, why were others not able to discover those issues? So, I > think we should be thankful to him for his careful analysis rather than > giving statements like the above devaluing his work. > > From a formal perspective, I find his work insightful. In the formal > analysis, we typically do not model KeyUpdate part. My takeaway was that we > need to include that as well. > > Regards, > > Usama > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
