Re: [TLS] 0-RTT encrypted data limits

Ilari Liusvaara <> Wed, 31 August 2016 18:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AD82012D668 for <>; Wed, 31 Aug 2016 11:26:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b8YSZTqpLvcI for <>; Wed, 31 Aug 2016 11:26:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BC4BA12D661 for <>; Wed, 31 Aug 2016 11:26:10 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 278F911400; Wed, 31 Aug 2016 21:26:09 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id 5bZ6h2WGIQJ9; Wed, 31 Aug 2016 21:26:09 +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 EF1DE21C; Wed, 31 Aug 2016 21:26:08 +0300 (EEST)
Date: Wed, 31 Aug 2016 21:25:58 +0300
From: Ilari Liusvaara <>
To: Hubert Kario <>
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.2-neo (2016-08-21)
Archived-At: <>
Subject: Re: [TLS] 0-RTT encrypted data limits
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, 31 Aug 2016 18:26:13 -0000

On Wed, Aug 31, 2016 at 08:14:33PM +0200, Hubert Kario wrote:
> Current draft has the following text in it:
>     If any of these checks fail, the server MUST NOT respond
>     with the extension and must discard all the remaining first
>     flight data (thus falling back to 1-RTT). If the client attempts
>     a 0-RTT handshake but the server rejects it, it will generally
>     not have the 0-RTT record protection keys and must instead
>     trial decrypt each record with the 1-RTT handshake keys
>     until it finds one that decrypts properly, and then pick up
>     the handshake from that point.
> My understanding of that, in case client does 0-RTT but server rejects it 
> (because the PSK is too old or its time is different enough) is that the 
> server needs to keep on reading arbitrarily large amounts of data it has no 
> idea what to do with. All using slow path (thinking exception handling in 
> particular).

Yes, read the data and attempt to decrypt it with handshake keys (with
GCM and POLY1305, failed decryptions are faster than successful ones,
of course there is exception overhead if those are used).