Re: [TLS] DTLS 1.3

Hannes Tschofenig <hannes.tschofenig@gmx.net> Mon, 04 July 2016 21:09 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B400D12D53A for <tls@ietfa.amsl.com>; Mon, 4 Jul 2016 14:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.521
X-Spam-Level:
X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yimZGYHsFLbE for <tls@ietfa.amsl.com>; Mon, 4 Jul 2016 14:09:39 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B62112B036 for <tls@ietf.org>; Mon, 4 Jul 2016 14:09:34 -0700 (PDT)
Received: from [192.168.10.132] ([80.92.121.176]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MIu7d-1bIGNT1Tlx-002XkB; Mon, 04 Jul 2016 23:09:26 +0200
To: Nikos Mavrogiannopoulos <nmav@redhat.com>, tls <tls@ietf.org>
References: <577A38A2.2090209@gmx.net> <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <577AD087.9000603@gmx.net>
Date: Mon, 04 Jul 2016 23:09:27 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="hL5HLB9Wp2Ekm6pwqweulOwoHEWhRHK6K"
X-Provags-ID: V03:K0:UJjOq9G1IzFwZk+5JqJ/2/jft68Jz9EwRjzCOPBpYmm3gpXsRzN pGfcMMBXzsFjsKkvs2oRks0hCnvYnzdppNQrRS9VJTM+uA4FvoA1kx7rVVLGmoSa34KNcdl vH4vspjFf8sZLsmmiL7y+7KS+JY7IYb0ACUvOIM+jw1Fg32Dv+wMV4OsifweuIXcwTr3bly 89bN+LX4CcYOneIXXw1hg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:j8LuHA5n54U=:JeggfDvOE+r0EX4OaIH9k7 7wFmliCEpk1s84FpA1dzcz/Q3Vqe2CGU06cOG8u1LKv+JgGlas0qpyjv46i/QapaACKk0qqe/ LQ7vS2f5H2L+hpQLPWSt5ffiKZM+RmxL1p4peXTkaxhsisbuFJ18HE4dcOkQPaAgV9IKUPUJ2 WlDBTVAhtNxlJMnCyt2HIIBiccAeyvxM/03C4oUJ1h+SkIyYX9/t09XAr8kclAi1qDaX7SmVx fa4aQ6JNKoLTKq5tCpwR0NrvmAOkpfcG2/VzVOQT6hJVua1IVG28KSQwY4SXt6YL6yWEfHOsj WPXlRTRK3xwuZ29SAjrJC9iwTykNz2goqPzZzamQCLspGfZKl9ry1319VMKnCVQu3WiZGzzhY 9fEiesdDGbyOto6OvLyavCfd5EZ2wU7IL53asebMyt7chVQsFS7Or/2mvUxhd6Ch1s6HiR44m UiSQstpmyV4kpZY/XCDQxstWdJ8oLVV54r81KoE2sM1tWFc2IWPVCC0C7TP0C1sOh+4qizVhg iTPwQKHKH7KDIv4UtWkojHeYkus/PFALkEkbyvDM6106w64FKDoIhis5yf/W3G3IIEl46Ys+f NK4DArlSiJcfdzI7FojAY1YTaaJktNMwnBLWi61MeCU1zdjWYnf0MJUmrG/WIQDc6FvWA+wQ/ 3QyTm8Hiel5HYmjkfoKon59jrfN4sSQDpEs78hOY+joma+SBNzlSmW1QfFqC/MDD8kpXGaWgX Hf4e8C8Gr3Q7cwmaF+pOg0V2H/Gz9zfbb5Xn9PATUqeEVgXQR7kBPhKfD/I=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/_GVKO57kGqG2F9egmz8o4pT0mcw>
Subject: Re: [TLS] DTLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Jul 2016 21:09:42 -0000

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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>