Re: [TLS] DTLS 1.3

Ilari Liusvaara <> Mon, 04 July 2016 14:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6FC7612B055 for <>; Mon, 4 Jul 2016 07:03:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.82
X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B8ZIcxVcUgRe for <>; Mon, 4 Jul 2016 07:03:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3957F12D0D9 for <>; Mon, 4 Jul 2016 07:03:16 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 72A488620 for <>; Mon, 4 Jul 2016 17:03:14 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id hzuVDogSTQpC for <>; Mon, 4 Jul 2016 17:03:14 +0300 (EEST)
Received: from LK-Perkele-V2 ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 1F7CA27B for <>; Mon, 4 Jul 2016 17:03:14 +0300 (EEST)
Date: Mon, 04 Jul 2016 17:03:12 +0300
From: Ilari Liusvaara <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: <>
Subject: Re: [TLS] DTLS 1.3
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Jul 2016 14:03:18 -0000

On Mon, Jul 04, 2016 at 12:21:22PM +0200, Hannes Tschofenig wrote:
> 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
> 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.

Taking a look:

- The version field is described as identical to TLS 1.3 version field.
  What value is there actually? FCFE (wasn't that how "DTLS 1.0" was
  encoded on wire)?
- Length and payload is is described as identical to version (which
  seems pretty odd...)
- The PR talks about "rehandshake". I believe that concept no longer
  exists in TLS 1.3.
- KeyUpdate does not work in DTLS. Might just use epochs for similar
  purpose, and reserve first few epochs for special purposes.
- One could allow epochs to wrap (sequence number arithmetic). Won't
  cause nonce reuse due to different keys. 
- The PMTU section talks about block padding and compression. Neither
  exists anymore (there is padding, but the minimum expansion is
  exactly known, e.g. the 30 bytes for most ciphersuites).
- The full handshake protocol is only run once. After that, there's
  only rekeying, new tickets and dynamic reauth.
- There's special case with cookies: DTLS 1.3 ClientHello getting
  rejected with HelloVerifyRequest. I think the correct reaction
  is for client to send a DTLS 1.3 ClientHello without 0-RTT data,
  containing the cookie sent now in legacy cookie field (NOT the
- According to TLS 1.3 rules, handshakes rejected using
  HelloRetryRequest use the Cookie extension for cookie
  transmitback, not the legacy cookie field (the cookie might not
  even fit into that field!)
- If handshake is rejected using HelloRetryRequest, according to
  the TLS 1.3 rules, the first ClientHello and HelloRetryRequest
  ARE included in handshake hashes.
- Is the DTLS 1.2 written as 0303 on the wire? I seem to remember
  it would be FCFC (but I could be wrong about that)? If it is
  not 0303, then DTLS 1.3 is not going to be 0304...
- In DTLS, AFAIK 0-RTT appdata is not reliable (but the 0-RTT
  handshake messages are). This brings all sorts of "fun" with
  message reordering and loss.
- The handshake retransmit scheme doesn't seem to work that
  well with post-handshake auth, and even less well with
  session tickets.