Re: [TLS] DTLS 1.3

Nikos Mavrogiannopoulos <nmav@redhat.com> Mon, 04 July 2016 19:54 UTC

Return-Path: <nmavrogi@redhat.com>
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 E648912B054 for <tls@ietfa.amsl.com>; Mon, 4 Jul 2016 12:54:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.842
X-Spam-Level:
X-Spam-Status: No, score=-6.842 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, 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 GOXLQzuiK7Q8 for <tls@ietfa.amsl.com>; Mon, 4 Jul 2016 12:54:20 -0700 (PDT)
Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28D9D12B036 for <tls@ietf.org>; Mon, 4 Jul 2016 12:54:20 -0700 (PDT)
Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u64JsJwM026365 for <tls@ietf.org>; Mon, 4 Jul 2016 15:54:19 -0400
Date: Mon, 04 Jul 2016 15:54:19 -0400
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: tls <tls@ietf.org>
Message-ID: <17444145.2646138.1467662059329.JavaMail.zimbra@redhat.com>
In-Reply-To: <577A38A2.2090209@gmx.net>
References: <577A38A2.2090209@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.10.51.93]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF45 (Linux)/8.0.6_GA_5922)
Thread-Topic: DTLS 1.3
Thread-Index: qXFm9j8wvxAxmyrQ4sJeMSuFMa9pIg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/41r27ftRl9-f4MgZYx7RYECD3Oo>
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 19:54:22 -0000

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