Re: [TLS] DTLS 1.3

[Nikos Mavrogiannopoulos <[e-mail]>]

----- Original Message -----
> On Mon, Jul 04, 2016 at 03:54:19PM -0400, Nikos Mavrogiannopoulos wrote:
> > ----- Original Message -----
> > > Hi all,
> > > 
> > > I have made an attempt to integrate DTLS 1.3 into the TLS 1.3 document
> > > and you can find the result at
> > > https://github.com/tlswg/tls13-spec/pull/512
> > > 
> > > I have worked on a prototype implementation of DTLS 1.3 and if someone
> > > else has something working by the time of the Hackathon in Berlin please
> > > let me know.
> > 
> > May I recommend a more radical approach for DTLS? My experience with
> > servers
> > handling DTLS traffic from various clients is that the clients change IPs
> > (while
> > roaming) and incoming ports (due to firewall state timeout), making
> > impossible
> > for the server to map the encrypted incoming packets from unknown IP/port
> > combinations
> > to any particular handler (i.e., handling process/thread or logical
> > handler). That
> > is because an independently received DTLS record packet has no session
> > identifying
> > information.
> 
> I think in DTLS 1.2, that was meant to be handled at lower layer (of course,
> often there isn't such layer even when needed).

I'm not sure that is discussed at DTLS 1.2 protocol at all. It is mostly ignored
as a problem. In the most unreliable layers (including UDP), this cannot be handled
at the lower layer without introducing another layer.

> > For that I'd like to propose the DTLS record format to include at least a
> > 3-byte identifier which will allow servers to recognize streams coming from
> > unknown
> > sources. That would be similar to the SPI field in the ESP packets. That
> > is,
> > a format similar to:
> One can't change the headers in ClientHello/ServerHello and expect to remain
> backwards compatible.

Why would these headers need to change? The ClientHello will be sent under
DTLS 1.0 and if the server see that the client supports the version with the
new format, it will reply using the new fields. The protocol's design can
cope with such changes.

> And how would that identifier be assigned? 0 in ClientHello, then copy
> whatever the server sends?

If the procedure above is followed the client will copy whatever it
sees from the server's hello packet.

regards,
Nikos