Re: [TLS] Avoiding Trial Decryption (for 0-RTT)

Ilari Liusvaara <> Sun, 03 April 2016 11:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF2D812D5CA for <>; Sun, 3 Apr 2016 04:43:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RmpSW4CQ67-X for <>; Sun, 3 Apr 2016 04:43:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2194F12D5DB for <>; Sun, 3 Apr 2016 04:43:54 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id F36E84A76; Sun, 3 Apr 2016 14:43:52 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id uAIeb3qFV2p9; Sun, 3 Apr 2016 14:43:52 +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 9B32021C; Sun, 3 Apr 2016 14:43:52 +0300 (EEST)
Date: Sun, 3 Apr 2016 14:43:51 +0300
From: Ilari Liusvaara <>
To: Karthik Bhargavan <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <>
Subject: Re: [TLS] Avoiding Trial Decryption (for 0-RTT)
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: Sun, 03 Apr 2016 11:43:58 -0000

On Sat, Apr 02, 2016 at 07:53:16PM +0200, Karthik Bhargavan wrote:
> TLS 1.3 0-RTT introduces an “optimistic” mode where the client 
> encrypts data that the server can then accept or reject.
> In the case when the server rejects 0-RTT, the server is left in a somewhat
> ugly state where it will receive, in sequence:
> (a) encrypted 0-RTT handshake data (that it needs to throw away)
> (b) encrypted 0-RTT application data (that it needs to throw away)
> (c) encrypted 1-RTT handshake data (that it needs to process)
> Since we have removed content types from the record headers
> of encrypted messages, these 3 flights of messages look the same.
> So, the current draft requires the server to “trial decrypt” each message
> with the 1-RTT Handshake keys, in order to detect where (c) begins, and 
> to discard packets that do not decrypt correctly. 
> The situation can be even worse. Suppose the client sends a ClientHello
> and 0-RTT data, the server responds with a HelloRetryRequest, and
> now the client sends a new ClientHello and new 0-RTT data.
> In this case, we have (a), (b), (a), (b), (c); that is, the server needs
> to skip 4 flights of messages by trial decryption before getting to
> the 1-RTT handshake data.

And with DTLS, one can get even more wonderful cases from all sorts of
datagram reordering. Including things like 1st round encrypted 0-RTT data
being interpretted as 2nd round encrypted 0-RTT data (it won't decrypt).

Oh, and also 0-RTT data being received after handshake has already

Well, in rejection case in (stream) TLS, you get ClientHello with its
different content type in the middle. But that won't help with the last

> Here is a proposal that would avoid trial decryption.
> When the client sends 0-RTT application data, it currently
> ends this flight of messages with an encrypted end_of_early data warning alert.
> How about: if the server rejects trial decryption, the client
> must then send an *unencrypted* end_of_early_data warning alert before
> continuing with 1-RTT handshake data.
> The server could then easily discard all records until it sees this warning alert.

Only works on (stream) TLS, but in DTLS this can presumably be deduced from
epoch numbers.

> The main disadvantage of this approach seems to be that it reveals to the adversary
> the point at which the 0-RTT application data ends (if this is sensitive information.)
> However, note that if the length of 0-RTT data was sensitive, an attacker
> could probably already obtain it by delaying the server flight.

Also, the length could probably be obtained passively from message sizes, unless
the implementation is very careful with padding (with high overhead).