Re: [TLS] DTLS 1.3

Ilari Liusvaara <> Wed, 06 July 2016 14:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F4EC12D140 for <>; Wed, 6 Jul 2016 07:47:14 -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 q-Hs28w13vMC for <>; Wed, 6 Jul 2016 07:47:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4280F12D0D3 for <>; Wed, 6 Jul 2016 07:47:12 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3198D7E77 for <>; Wed, 6 Jul 2016 17:47:11 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id 9eZuSnYv-Fil for <>; Wed, 6 Jul 2016 17:47:10 +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 D05D0C4 for <>; Wed, 6 Jul 2016 17:47:10 +0300 (EEST)
Date: Wed, 06 Jul 2016 17:47:08 +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: Wed, 06 Jul 2016 14:47:14 -0000

On Wed, Jul 06, 2016 at 02:34:07PM +0200, Hannes Tschofenig wrote:
> 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.)

Being part of regular handshake is problematic, since those are assumed
to be tickets, and as such one needs the dynamic PSK key. But the dynamic
PSK key includes the entiere handshake up to Client Finished. And this
can't really be changed (or things start going badly wrong).

So the minimum time to send some tickets is 4th flight, whereas normal
handshake is only 3 flights.

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

Certificate requests have context identifiers...

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

I don't think this works, because KeyUpdate is not idempotent (causes
problems if reply is lost) and worse yet, because of potential desyncs
with the main data flow (IP packet reordering!).

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

Each listed one essentially corresponds to one key connection can use:

- Unencrypted (CH/SH/HRR)
- 0-RTT handshake key (Finished)
- 0-RTT data key (0-RTT appdata)
- Handshake key (Encrypted Extensions to Client Finished)
- Application key from initial traffic_secret_0.
- Application key from traffic_secret_N  (N>0).