Hi Nikos, when it comes to optimizing the record layer then it basically boils down to the question about how middleboxes react to this type of change.
In the IoT context the story is a bit easier since there greenfield deployments with new radio technologies where these types of middleboxes are not yet there. For those environments more radical changes, as you and Thomas mentioned, are probably useful. Ciao Hannes On 07/04/2016 09:54 PM, 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. > > 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: > > struct { > ContentType type; > ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */ > uint24 id; > uint16 length; > opaque fragment[TLSPlaintext.length]; > } TLSPlaintext; > > where id is sent by the server to the client either via an extension, or > by simply assuming that the client will copy and keep the ID seen at the > server packets (it doesn't really matter that this ID is unprotected as > it doesn't contribute nor affect the security in any way). > > regards, > Nikos > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
