Re: [TLS] What does it mean to not include 0-RTT message in the handshake hash?

Dave Garrett <> Thu, 24 December 2015 22:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 749BC1A6FAA for <>; Thu, 24 Dec 2015 14:48:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4la3oUbVIE1r for <>; Thu, 24 Dec 2015 14:48:28 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c04::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31AD41A6FA8 for <>; Thu, 24 Dec 2015 14:48:27 -0800 (PST)
Received: by with SMTP id 6so7082435qgy.3 for <>; Thu, 24 Dec 2015 14:48:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=0ZZHYywcsKzzv0XNuuqJzDs+WSyv4Z2cYdpvr4Xv63A=; b=z9j0/poRGhX5/DfCl4KWbaB8eUeReUzEfGU0ObXfPufegEfRZh/iClR+XtkYStoCF5 ipwDMil4P1FC+luacutXqEFG+ZiW+XVlvtcQ/cs9oyKv2CEz1MeD59LVsfiwiqCtQM+0 u//OoCR1nF0DDtNsdwcvsP9XHBQNJhsTYgF0sFd6Bue7K3fKPgpvC9ZTV/4B6MoRai0S cqRzm2SuGHGbTlVHeQ/f3pNX4+ONpd3bX2UDxVpYWjav9qPRwtnqhq0lvgwtFsL0wpfA JG9QJRXn6l7SS4rEvuiln1Ajt9wzZyQEsZPXEnQJPe9fShG1eqtS4HRKsbcwT3CijRtl tIHQ==
X-Received: by with SMTP id 66mr54868789qhk.18.1450997307073; Thu, 24 Dec 2015 14:48:27 -0800 (PST)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id z65sm20674530qhb.22.2015. (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 24 Dec 2015 14:48:26 -0800 (PST)
From: Dave Garrett <>
To: Eric Rescorla <>
Date: Thu, 24 Dec 2015 17:48:25 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-6"
Content-Transfer-Encoding: 7bit
Message-Id: <>
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake hash?
X-Mailman-Version: 2.1.15
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: Thu, 24 Dec 2015 22:48:29 -0000

On Thursday, December 24, 2015 05:14:17 pm Eric Rescorla wrote:
> On Thu, Dec 24, 2015 at 5:01 PM, Dave Garrett <>
> wrote:
> > On Thursday, December 24, 2015 04:48:58 pm Eric Rescorla wrote:
> > > On Thu, Dec 24, 2015 at 4:26 PM, Dave Garrett <>
> > > wrote:
> > So, the client sends a handshake with 0RTT, an intermediary strips it and
> > replaces it with something that fills the slot, but will get rejected, the
> > server rejects it and falls back to 1RTT, and then the client would have to
> > accept this. This intermediary thus has the power to force any 0RTT attempt
> > to fall back to 1RTT.
> This doesn't sound correct.
> 1. The client sends a ClientHello with an EarlyDataIndication indicating
> configuration=C (and server key g^s) and ClientHello.key_share = x.
> 2. The server processes the ClientHello and determines whether 0-RTT will  be accepted
> or rejected based purely on the ClientHello. I.e., it doesn't need to read any more messages
> before deciding this [0]. If it decides to accept 0-RTT then it expects the next messages to
> be 0-RTT handshake messages encrypted with SS = g^xs. If those messages don't decrypt
> properly, then it needs to fail the entire connection (fatal alert with bad_record_mac).

This last bit stops this, yes. I would prefer the spec say this very explicitly, as right now it doesn't and all I see is a line saying:
"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)."

The current text doesn't explicitly say how to handle 0-RTT data that it thinks it should be able to decrypt but can't. After rereading things a bit I think you're correct in that the correct course of action the spec currently expects is to abort, however implementers frequently err on the side of working partially vs not at all when given any wiggle room. A clear hard "MUST abort" on failed decrypt of 0RTT data would deal with this and avoid any other possible misunderstanding. Either do or do not; no try.

> 3. The attacker *could* modify the ClientHello to replace C with C', which would cause
> the server to fall back to 1-RTT, but then the server's CertificateVerify and Finished would
> both be incorrect, causing the handshake to fail when the client tries to process them.
> If you still think I'm wrong here, it would help me if you provide a ladder diagram indicating
> the attack you are concerned about.
> Thanks,
> -Ekr
> [0] Technically speaking, it should be possible to send ServerHello before
> even reading  the remainder of the first flight.

Also, I found a typo in the early data section. The config ID was referred to by two names. PR filed. ;)