[TLS] Re: DTLS 1.3 bis

Hi Usama, 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. AFAIK wolf

[TLS] Re: DTLS 1.3 bis

+1 for RFC9147bis +1 for Russ suggestion of doing formal analysis John From: Achim Kraus Date: Wednesday, 13 November 2024 at 12:58 To: Muhammad Usama Sardar Cc: Joseph Salowey , IETF TLS Subject: [TLS] Re: DTLS 1.3 bis Hi Usama, > Is David Benjamin the /first/ and /only/ person in the world

[TLS] Re: DTLS 1.3 bis

On Wed, Nov 13, 2024, 3:30 AM Muhammad Usama Sardar < muhammad_usama.sar...@tu-dresden.de> wrote: > 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, wh

[TLS] Re: [EXTERNAL] Re: DTLS 1.3 bis

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,

[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

[TLS] Re: [EXTERNAL] Re: DTLS 1.3 bis

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

[TLS] Re: DTLS 1.3 bis

3GPP uses a lot of DTLS. QUIC might be a future solution for most of them, but quantum-resistant DTLS 1.3 is a must in the meantime. >Of course CoAP specifies DTLS... QUIC cannot be used for instead of DTLS in constrained devices. It is a much more complex protocol. John From: Robert Moskowitz

[TLS] Re: DTLS 1.3 bis

The ICAO Communication Panel has specified DTLS for air-to-ground security.  That won't change without a major lift effort, lots of years, and for many of them QUIC is too new and unproven. :) Actually there are good reasons for use of CoAP over-the-air.  Of course CoAP specifies DTLS... FU

[TLS] Re: [EXTERNAL] Re: DTLS 1.3 bis

On Wed, 13 Nov 2024, 19:39 David Benjamin, wrote: > 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 eve

[TLS] Re: [EXTERNAL] Re: DTLS 1.3 bis

WebRTC uses DTLS and is the driver for DTLS in BoringSSL. Post-quantum DTLS necessitates DTLS1.3. On Wed, Nov 13, 2024 at 3:00 PM Ben Smyth wrote: > On Wed, 13 Nov 2024, 19:39 David Benjamin, wrote: > >> FWIW, I did not read Watson's comment in any negative way and agree with >> him. (And every

[TLS] Re: [EXTERNAL] Re: DTLS 1.3 bis

Ben Smyth writes: >Datagram TLS over UDP (Userdata Datagram Protocol) is losing to Quic[k UDP >Internet Connections] You mean "Google is putting massive amounts of pressure on people to try and make sure that DTLS loses to QUIC" (or as one dev put it, "QUIC doesn't deliver but no-one will say so

[TLS] Re: [EXTERNAL] Re: DTLS 1.3 bis

Christian Huitema writes: >That chimes with David Benjamin's analysis about the "whole mess of >transport-related concerns that just don't apply to TLS". The expertise for >that is in the transport area, not in the TLS WG. LDAP was once described as "a bunch of networking types trying to reinven

[TLS] Re: [EXTERNAL] Re: DTLS 1.3 bis

On 11/13/2024 6:06 PM, Peter Gutmann wrote: Ben Smyth writes: Datagram TLS over UDP (Userdata Datagram Protocol) is losing to Quic[k UDP Internet Connections] QUIC is not an acronym, see RFC 9000. You mean "Google is putting massive amounts of pressure on people to try and make sure that DT

[TLS] Re: DTLS 1.3 bis

+1 Arnaud Taddei Global Security Strategist | Enterprise Security Group mobile: +41 79 506 1129 Geneva, Switzerland arnaud.tad...@broadcom.com | broadcom.com > On 13 Nov 2024, at 21:34, John Mattsson > wrote: > > 3GPP uses a lot of DTLS. QUIC might be a fu

[TLS] Re: DTLS 1.3 bis

Well put Bob Arnaud Taddei Global Security Strategist | Enterprise Security Group mobile: +41 79 506 1129 Geneva, Switzerland arnaud.tad...@broadcom.com | broadcom.com > On 13 Nov 2024, at 21:26, Robert Moskowitz wrote: > > The ICAO Communication Panel has

[TLS] Re: [EXTERNAL] Re: DTLS 1.3 bis

Hello Peter, > Just thinking out loud here but could the transport folks define some sort of > reliable-UDP transport mechanism that you could then run whatever you like > over? The benefit using DTLS/UDP instead of TLS/TCP is in my experience, that the application decides for each "application

[TLS] Re: [EXTERNAL] Re: DTLS 1.3 bis

>You mean "Google is putting massive amounts of pressure on people to try and >make sure that DTLS loses to QUIC" (or as one dev put it, "QUIC doesn't >deliver but no-one will say so in public because of Google's ire", another one >mentioned "huge amounts of vitriol from Google when we tried to pus