[TLS] Re: DTLS 1.3 bis

[Achim Kraus]

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 wolfssl has implemented it.
I don't know, how they handled this issues.

> So, I think we should be thankful to him for his careful analysis
> rather than giving statements like the above devaluing his work.

very true.

br
Achim



___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: DTLS 1.3 bis

[John Mattsson]

+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
> 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 wolfssl has implemented it.
I don't know, how they handled this issues.

 > So, I think we should be thankful to him for his careful analysis
 > rather than giving statements like the above devaluing his work.

very true.

br
Achim



___
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

[TLS] Re: DTLS 1.3 bis

[Watson Ladd]

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, 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.
>

I'm not devaluing his work, merely expressing surprise that no one else
seems to have run into all these issues. It's true some of them require
some careful thinking to find, but it's not true that we needed formal
analysis to see that some of this text just doesn't work.

My email was a reply to the idea that FATT should take a look. Maybe but
let's not pretend it's a panecea, particularly with text to model questions.

>
> Regards,
>
> Usama
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Andrei Popov]

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 
Sent: Wednesday, November 13, 2024 3:30 AM
To: Watson Ladd ; Russ Housley 
Cc: Joseph Salowey ; IETF TLS 
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] Re: DTLS 1.3 bis

[Muhammad Usama Sardar]

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] Re: [EXTERNAL] Re: DTLS 1.3 bis

[David Benjamin]

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  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 
> *Sent:* Wednesday, November 13, 2024 3:30 AM
> *To:* Watson Ladd ; Russ Housley <
> hous...@vigilsec.com>
> *Cc:* Joseph Salowey ; IETF TLS 
> *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

[TLS] Re: DTLS 1.3 bis

[John Mattsson]

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 
Date: Wednesday, 13 November 2024 at 21:27
To: Watson Ladd , Russ Housley 
Cc: Joseph Salowey , IETF TLS 
Subject: [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...

FUN!

Fix DTLS.
On 11/12/24 17:52, Watson Ladd wrote:
I think anyone implementing would have discovered them.  The other question 
which I'll try not to ask too frequently is at what point do we just point 
users at QUIC?


On Tue, Nov 12, 2024 at 12:43 PM Russ Housley 
mailto:hous...@vigilsec.com>> wrote:
>
> I agree that a bis is needed for DTLS 1.3, but I think that some of the 
> things that David Benjiman talked about would have been discovered, 
> especially the keyUpdate-related things, if there had been formal analysis of 
> DTLS 1.3.  Please have the FATT take a look.
>
> Russ
>
>
> On Nov 12, 2024, at 3:29 PM, Joseph Salowey 
> mailto:jsalo...@gmail.com>> wrote:
>
> At IETF 121, we discussed revised DTLS 1.3, aka a draft-ietf-tls-rfc9147bis. 
> The chairs are proposing starting this I-D as a WG item with the existing RFC 
> as a base. If you object to this please let the list know by 25 November 2024.
>
>
> Thanks,
>
> Deirdre, Joe, and Sean
>
>
> ___
> 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






___

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

[TLS] Re: DTLS 1.3 bis

[Robert Moskowitz]

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...


FUN!

Fix DTLS.

On 11/12/24 17:52, Watson Ladd wrote:
I think anyone implementing would have discovered them.  The other 
question which I'll try not to ask too frequently is at what point do 
we just point users at QUIC?



On Tue, Nov 12, 2024 at 12:43 PM Russ Housley  
wrote:

>
> I agree that a bis is needed for DTLS 1.3, but I think that some of 
the things that David Benjiman talked about would have been 
discovered, especially the keyUpdate-related things, if there had been 
formal analysis of DTLS 1.3.  Please have the FATT take a look.

>
> Russ
>
>
> On Nov 12, 2024, at 3:29 PM, Joseph Salowey  wrote:
>
> At IETF 121, we discussed revised DTLS 1.3, aka a 
draft-ietf-tls-rfc9147bis. The chairs are proposing starting this I-D 
as a WG item with the existing RFC as a base. If you object to this 
please let the list know by 25 November 2024.

>
>
> Thanks,
>
> Deirdre, Joe, and Sean
>
>
> ___
> 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




___
TLS mailing list --tls@ietf.org
To unsubscribe send an email totls-le...@ietf.org
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Ben Smyth]

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 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.
>

DTLS seems less interesting than TLS because:

Datagram TLS over UDP (Userdata Datagram Protocol) is losing to Quic[k UDP
Internet Connections] which obsoletes TCP, in favour of UDP-multiplexing
(TLS over TCP/2),

do we need DTLS or has TLS/Quic won?
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[David Adrian]

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 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.
>>
>
> DTLS seems less interesting than TLS because:
>
> Datagram TLS over UDP (Userdata Datagram Protocol) is losing to Quic[k UDP
> Internet Connections] which obsoletes TCP, in favour of UDP-multiplexing
> (TLS over TCP/2),
>
> do we need DTLS or has TLS/Quic won?
>
>
> ___
> 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

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

[Peter Gutmann]

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 in public because of Google's ire", another one
mentioned "huge amounts of vitriol from Google when we tried to push back on
QUIC").

Peter.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Peter Gutmann]

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 reinvent
1960s database technology", is this a case of a bunch of crypto types trying
to reinvent TCP, except that it's made even more difficult because of all the
crypto considerations?

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?  Or, given that we've got WireGuard and OpenVPN already solving the
problem for a lot of cases, is what's left big enough for anyone to care?  Is
there much use for it left outside of SIP and online gaming (the latter
presumably just because it's there rather than any specific need for DTLS)?

Peter.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Christian Huitema]

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 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 push back on
QUIC").


It is certainly not just Google. If you look at the work in the 
transport area, you will see a lot of activity on TCP and on QUIC, and 
very rarely hear about TLS. 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.


-- Christian Huitema




___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: DTLS 1.3 bis

[Arnaud Taddei]

+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 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 
> Date: Wednesday, 13 November 2024 at 21:27
> To: Watson Ladd , Russ Housley 
> Cc: Joseph Salowey , IETF TLS 
> Subject: [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...
> 
> FUN!
> 
> Fix DTLS.
> 
> On 11/12/24 17:52, Watson Ladd wrote:
> I think anyone implementing would have discovered them.  The other question 
> which I'll try not to ask too frequently is at what point do we just point 
> users at QUIC?
> 
> 
> On Tue, Nov 12, 2024 at 12:43 PM Russ Housley  > wrote:
> >
> > I agree that a bis is needed for DTLS 1.3, but I think that some of the 
> > things that David Benjiman talked about would have been discovered, 
> > especially the keyUpdate-related things, if there had been formal analysis 
> > of DTLS 1.3.  Please have the FATT take a look.
> >
> > Russ
> >
> >
> > On Nov 12, 2024, at 3:29 PM, Joseph Salowey  > > wrote:
> >
> > At IETF 121, we discussed revised DTLS 1.3, aka a 
> > draft-ietf-tls-rfc9147bis. The chairs are proposing starting this I-D as a 
> > WG item with the existing RFC as a base. If you object to this please let 
> > the list know by 25 November 2024.
> >
> >
> > Thanks,
> >
> > Deirdre, Joe, and Sean
> >
> >
> > ___
> > 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 
> > 
> 
> 
> 
> 
> 
> ___
> 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


-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: DTLS 1.3 bis

[Arnaud Taddei]

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 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...
> 
> FUN!
> 
> Fix DTLS.
> 
> On 11/12/24 17:52, Watson Ladd wrote:
>> I think anyone implementing would have discovered them.  The other question 
>> which I'll try not to ask too frequently is at what point do we just point 
>> users at QUIC?
>> 
>> 
>> On Tue, Nov 12, 2024 at 12:43 PM Russ Housley > > wrote:
>> >
>> > I agree that a bis is needed for DTLS 1.3, but I think that some of the 
>> > things that David Benjiman talked about would have been discovered, 
>> > especially the keyUpdate-related things, if there had been formal analysis 
>> > of DTLS 1.3.  Please have the FATT take a look.
>> >
>> > Russ
>> >
>> >
>> > On Nov 12, 2024, at 3:29 PM, Joseph Salowey > > > wrote:
>> >
>> > At IETF 121, we discussed revised DTLS 1.3, aka a 
>> > draft-ietf-tls-rfc9147bis. The chairs are proposing starting this I-D as a 
>> > WG item with the existing RFC as a base. If you object to this please let 
>> > the list know by 25 November 2024.
>> >
>> >
>> > Thanks,
>> >
>> > Deirdre, Joe, and Sean
>> >
>> >
>> > ___
>> > 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 
>> > 
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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


-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Achim Kraus]

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 record", if it's
required to use something as an ACK or not. And when an ACK is used,
if it's preferred to retransmit or drop an message, when the ACK
is missing in time . And, of course, easily have control over the
"time" to wait for ACK. If that makes a sense/difference, depends
on the application and physical transmission layer.

During the (D)TLS handshake there is not that much choice. If the
handshake record don't make it to the other side, then they are either
retransmitted or the handshake is stopped an required to be restarted
again later. Here the "application on top of UDP" decides to
"always ACK and retransmit", because it's required for that approach
(negotiate security parameter).

I guess, to encapsulate the "UDP possibilities" at in a specific API,
will move some of the "control artifacts" outside the protection of
encryption and makes it somehow more vulnerable.

br
Achim

Am 14.11.24 um 05:08 schrieb Peter Gutmann:

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 reinvent
1960s database technology", is this a case of a bunch of crypto types trying
to reinvent TCP, except that it's made even more difficult because of all the
crypto considerations?

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?  Or, given that we've got WireGuard and OpenVPN already solving the
problem for a lot of cases, is what's left big enough for anyone to care?  Is
there much use for it left outside of SIP and online gaming (the latter
presumably just because it's there rather than any specific need for DTLS)?

Peter.
___
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

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

[John Mattsson]

>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 push back on
>QUIC").

I would certainly never say anything just to please Google, but QUIC delivers 
in spades, it is a large part of the whole Internet traffic and has very 
beneficial performance compared to TLS/TCP over non-optimal connections. QUIC 
also has mandatory encryption, which cannot be turned off, which is exactly how 
things should be. I think we should all be very thankful to Google for putting 
so much R&D into QUIC and SPDY and then letting everyone benefit by 
standardizing them (with a lot of changes) in the IETF.

That said, nobody will ever use CoAP over QUIC. QUIC is not the solution to 
everything, but that is not Google’s fault. David Benjamin should be thanked 
for describing all these problems with DTLS 1.3.

Cheers,
John

From: Peter Gutmann 
Date: Thursday, 14 November 2024 at 03:08
To: David Benjamin , resea...@bensmyth.com 

Cc: Andrei Popov , Joseph Salowey 
, IETF TLS 
Subject: [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 in public because of Google's ire", another one
mentioned "huge amounts of vitriol from Google when we tried to push back on
QUIC").

Peter.

___
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