Re: [TLS] DTLS 1.3

Hannes Tschofenig <> Wed, 06 July 2016 12:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C6F5712D76E for <>; Wed, 6 Jul 2016 05:34:16 -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=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GVe1MG1yX8rB for <>; Wed, 6 Jul 2016 05:34:14 -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 6A5E512B05A for <>; Wed, 6 Jul 2016 05:34:14 -0700 (PDT)
Received: from [] ([]) by (mrgmx103) with ESMTPSA (Nemesis) id 0LuwiT-1bTbkZ09yr-0106KR; Wed, 06 Jul 2016 14:34:10 +0200
To: Ilari Liusvaara <>, Eric Rescorla <>
References: <> <> <> <> <> <>
From: Hannes Tschofenig <>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Wed, 06 Jul 2016 14:34:07 +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="RSsJmXhDD192kOctqW8n4sv65Xpb6XWtR"
X-Provags-ID: V03:K0:u6UQld6iZZNKyOYbWT83xULXwZdlQgDamiGMIcIpMiy1KpqHjGF 6W4qaVnBuWLzGVUmRJrFQmb6KGG8W0Dby6kVCQ0dxtszS8Mqp/trwoZoeoc0HPT7LnsL2DJ 0VDl+VLLAI1gpfcMZFMe9Em7CaLDi1QIXY3nqui2NkMGCK7AptpDWzCFzR8kh9PDuNbHAJN yZmiJc+j0zEHWuq3gxKpQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:kePC0JGfv8M=:2Y9buOhdFVUAqy8Ye2YuYZ 3aTH1yEpVRG9M5ryqZDITNn6YMwP70yBzfLqG9friqSpAji4e1jKSFMT5A5EmWx59BXD6xkFq e4tCCtVqOnHMdapJ29IFEmtJS2/CkCqddCjO5zajoMdYVpv7Ku2zELozUrkDTpOXjLNIRqCLO s7CGEV4JhZaDjh8s6Yher4HulnFa9h55+/cBIDKNFH2BuY54wuaGz6nD4Sl+6WoUtpaHexWZc 98lHgIuGdP6OLyFgTLfbqQu5JcGoCH6vDRoO1rC8PTz9tNPpgvtxF9BZCZ9V4nDGkrfhh0L0I L65En9VRJrr6oULDsuhuz+DR1+GSLt69HM6Wzmh4K6+G14FjanKxPUM+3aTfijhQiFUIfWGGM 5jmvVHJI4byN550w30r9H/BZmluo5WMyAAKCseVlFTc0F5L7H2eHSej8fvZGorkdHVIs53xZR kAe0gKnqI/6Z7XA/VUF5sBZJIvuQXdtyGk01mZshZwEcUqj8k6j5nhgno54rjcDbp1121xnLd TYrxXmFcXHFzvW5n7imvq1CckgTW2ZTFLUyYTMI0BWcb5A7FsbtrAkIdZU+VDY4Dg2i/4Cql0 /u+Vvn67f7e+247x9mUsnjzU2ZrSUWDFkr1zE+BMhunPbGOTY1iwb0B0LHOMIlcenGRTbpoTl YWC6WPRM2r9b1AZFZBzG22p7mbJlCUG7MgY7rt6gJZK5n8YzHuWYelFWZ8YG6YiXNprORp0Om P+8lwuXcZBxofhVpUSb4UHZWD8cMJxlkgxhbHnLjlKGQWFp1eLjceNna10M=
Archived-At: <>
Cc: "" <>
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: Wed, 06 Jul 2016 12:34:17 -0000

Hi Ilari, Hi Ekr,

a few remarks inline:


>>>> - 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?
>>> DTLS assumes handshake messages are reliable, and that reliability is
>>> implemented via handshake messages ACKing one another.
>>> - Session tickets have no ACK at all.
>> DTLS 1.3 should add an ACK, IMO.
> Yeah, not going to work without. And I presume something might be
> needed for dynamic reauth too...

I was wondering about one design decision regarding the ack.

If we don't use the epoch instead of the KeyUpdate then there is only
one other message that does not have an ack, namely the NewSessionTicket
message. (I might be worthwhile to think about why the server can send
it at any time and why it isn't sent as part of the regular handshake
instead. This would make the issue with acks potentially go away.)

The post-handshake authentication with the CertificateRequest comes with
an ack (even though it may be delayed), namely Certificate,
CertificateVerify, and Finished (and in case of a decline with a
certificate and a finished). Would it be worthwhile to ack them as well
due to the potential delay caused by user interaction?

Let us say that we provide an ack for the NewSessionTicket message then
it is sufficient to specify a very simple ack, namely one that is
defined as: struct {} Ack;

If we also ack the post-handshake authentication then it is necessary to
include some identifier in the Ack message to indicate which message is

What are your thoughts about this?

>>> - CertificateRequest can have very slow ACK.
>>> - KeyUpdate has no real ACK (and isn't idempotent either).
>> Yes, I think we should remove KeyUpdate for DTLS 1.3 and just use epoch
>> instead.

I believe that using epoch for updating the cryptographic keys is pretty
much like a key update. Essentially, we are talking about taking the
epoch value from the incoming packet and then figuring out what security
context is applicable. Correct?

An alternative design would be to require the receiver of a KeyUpdate to
return a KeyUpdate as well. This would then constitute a flight.
Wouldn't this be better?
> How many special epochs we need?
> 0 => Unencrypted messages
> 1 => 0-RTT control messages (just one finished[1]!)
> 2 => 0-RTT data messages
> 3 => primary handshake
> 4 => application data
> 5-N => rekey connection

I guess you want to introduce these different epoch values and associate
them with different phases during the handshake since the TLS 1.3 key
derivation is more sophisticated than the TLS 1.2 version.

Is this correct?