Re: [TLS] DTLS 1.3

Hannes Tschofenig <> Mon, 04 July 2016 19:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E0D4312B036 for <>; Mon, 4 Jul 2016 12:52:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.521
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=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eLQ9A34zPW37 for <>; Mon, 4 Jul 2016 12:52:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6763012D103 for <>; Mon, 4 Jul 2016 12:45:41 -0700 (PDT)
Received: from [] ([]) by (mrgmx001) with ESMTPSA (Nemesis) id 0Lu7a2-1bTOtD3PyI-011REi; Mon, 04 Jul 2016 21:45:38 +0200
To: Ilari Liusvaara <>,
References: <> <>
From: Hannes Tschofenig <>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Mon, 04 Jul 2016 21:45:38 +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: <>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="mawu5nNkdNFNh07IM9jsap6c5v9GUXj7t"
X-Provags-ID: V03:K0:bWT03j6ijfIqG/LUYI/tgJ283pbGxLeIrbExghvAT657rc/dB/i p8rznHhRc2ITjpC2I8LdQ+rHzUNq0GdJnGS345C4q+xpVb2UWz8Fg5RwmiOpa3g8ITqBJDu Xp2MjGQUmvzAC5SrWXai/XCISG3DKJ9CTBWbcPGwb71qe0q7AmtO+kUOjl8fBaNYK6va82l S0xARpswULlYqPZXw4e9g==
X-UI-Out-Filterresults: notjunk:1;V01:K0:3c5KNXewKgg=:0fJjlhVpmh+VtlOzsFp5pU ZTV/Oj/HOoDMCcoOinnFfVydE/6WCFR1t+4u69Yj/UwE1xC8VlRpHCuZ2XvI1cdxO93/MpI/h F1rGcQu3auAs/g37lQRtkuccxeUblva7MeuaOFmi34hHGY6R+JKm0VINmaCOYVmQ5NSivgf0r WQRiuxWSRIq+R8xxSVYR2uHqM+uAmyGLc/ABiVX45Bkq/dI4piTTzTAVQpRKKZZ/E7fcrMfNJ ZhtAH4EteEFw27WRMUxYfeuUbzRU/7rJ8Pq8FWJVGb78zXlMbgUS7Sg0PnGqSlToYkn5AgHGj DyNWR1RYri2ObcIMJNQFFYFsbbMP+Ew26BdXKNuPp6I6TuD2FVh9XQxZISz6XK9d/MFdI9/lU RwDdQ0h8O3oOXXpydo/fTdKe9Z8ru2xApYz3waXrUe4zJ2xM1EQAgeouOeWg1B4SBhsdl0yBn Hr5i/NC7q/2E/BxbwfzbdJC54sqPQCjEZJr6V1pwYPw7eiRNZ/OKtqZbZXM43kmcOxzfWHbtk PRPBGbwROm/QhcUOH/jWg8LEdBbwCQx++bfPd3FTrGG7FI/8SyniLUosPxtJYUGy6ZzQEPMV+ 1nZyHAodd6ToufJsxVNVAGS7H/nXQCHh5uybL1xuxdRxzoNhj72gc/gB1fKjPh1P6nhKKobLQ m/jM4HGIo4Nmnek9xOBk1iUDpKwn6CE7bAKzMPppbPvxL3441rAhkmIisvGD0O1REpAymU1lq UTeaJKVy2vnSi1PfcQZJ3vOP5PQGC6TeDVlK92qko/3CTpywfRj2sDpGUf8=
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 19:52:47 -0000

Hi Ilari,

thanks for your super quick response.

On 07/04/2016 04:03 PM, Ilari Liusvaara wrote:
> 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)?

For the record layer TLS 1.3 says that the version field is deprecated
and ignored. I guess the same approach applies to DTLS 1.3. So, it
probably doesn't matter what is really is. In DTLS 1.2 the version value
was 254.253.

For the client_version and server_version in the handshake I thought it
would be fine to just re-use the TLS 1.3 version number.

> - Length and payload is is described as identical to version (which
>   seems pretty odd...)

Copy-and-paste mistake. Fixed.

> - The PR talks about "rehandshake". I believe that concept no longer
>   exists in TLS 1.3.

Updated the text and referred to the KeyUpdate where applicable.

> - KeyUpdate does not work in DTLS. Might just use epochs for similar
>   purpose, and reserve first few epochs for special purposes.

Could you explain in more detail why you think a key update does not
work with DTLS?

> - One could allow epochs to wrap (sequence number arithmetic). Won't
>   cause nonce reuse due to different keys. 

I have no preference regarding this issue.

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

Deleted sentence you mentioned.

> - The full handshake protocol is only run once. After that, there's
>   only rekeying, new tickets and dynamic reauth.

How TLS 1.3/DTLS 1.3 is used in specific environments remains to be seen.

> - 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
>   extension).
> - 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!)

Regarding the issue of where to send the cookie in the ClientHello there
are two options. The first option is to use the cookie extension, and
the second option is to use the DTLS 1.2 style where the cookie is
placed in the ClientHello directly (without using an extension).

My (weak) preference is to use the cookie extension also in the
ClientHello. My main reason was the length mismatch between the DTLS 1.2
cookie extension (which is now in the legacy_cookie filed) and the
cookie extension. The cookie extension has a max length of 2^16-1 bytes
and the legacy_cookie extension only 2^8-1 bytes long. If the design of
the ClientHello uses the legacy_cookie extension then the server has to
take care that the cookie size does not exceed the 2^8-1 bytes.

> - If handshake is rejected using HelloRetryRequest, according to
>   the TLS 1.3 rules, the first ClientHello and HelloRetryRequest
>   ARE included in handshake hashes.

Fixed it but I am not sure that's a good idea unless the cookie carries
that state information. With 255 bytes that's going to be difficult...

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

Are you referring to the version field?

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

That's certainly something to take a closer look at. I haven't
implemented that part yet ....

> - The handshake retransmit scheme doesn't seem to work that
>   well with post-handshake auth, and even less well with
>   session tickets.
Why do you think so? Of course, unreliable transports creates
inconvenience; is it that what you are referring to?


> -Ilari
> _______________________________________________
> TLS mailing list