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

Dave Garrett <> Thu, 24 December 2015 21:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CCE9D1A21A1 for <>; Thu, 24 Dec 2015 13:26:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PPAjJ6hLoSzH for <>; Thu, 24 Dec 2015 13:26:45 -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 E77831A212A for <>; Thu, 24 Dec 2015 13:26:44 -0800 (PST)
Received: by with SMTP id b35so4163071qge.2 for <>; Thu, 24 Dec 2015 13:26:44 -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=mmi3Homqqkc/8fuAWdzVaKB6UhhY73tHEsitSecAXTI=; b=k5f+UCKjJBKWKS0yhIqBhca8M8HlIwkdI1MwUY1JHXXK+CthclzW3eSXee5Bp1K2Jw 19f/EnJSSb/en8Ee7eXY1wN3Fea45AVHWlaWLWB9QPrVAOvNc1ojS1HzZUQhOc4qOqJP 1v9LpzshheH9gltVBBs/sTIX/T/SlLWjERwXWndMJD2wiDYl2YypJAv9/muQU0E9SCu5 iG7J3DSxA7nl+6fP6KIUHsDkiorXtGEKC+6pYWd9GUrakj9D1IhzmFajyE51FU6OAM93 sqfWw+joABg/7IqfMF7P3ELSUV6hX9sf92HDZjp9w+F1Exu7+mlKbgYXUMbM05FL+eOq DSrA==
X-Received: by with SMTP id r186mr54313646qhc.56.1450992404196; Thu, 24 Dec 2015 13:26:44 -0800 (PST)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id m13sm7069996qki.8.2015. (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 24 Dec 2015 13:26:43 -0800 (PST)
From: Dave Garrett <>
Date: Thu, 24 Dec 2015 16:26:41 -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-1"
Content-Transfer-Encoding: 7bit
Message-Id: <>
Archived-At: <>
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 21:26:47 -0000

On Thursday, December 24, 2015 03:40:26 pm Christian Huitema wrote:
> On Monday, December 21, 2015 6:30 PM, Martin Thomson wrote:
> > On 22 December 2015 at 13:25, Christian Huitema <>
> > wrote:
> > >> Unless I'm confused (which is possible given the time of night),
> > >> the intention, as you say, is to separate out the 0-RTT handshake
> > >> messages i.e., (cert, cert verify, finished) from the 1-RTT computations.
> > >
> > > OK. That does not simplify implementations using running hashes...
> > 
> > It does if you consider the possibility of having to drop the 0-RTT data.
> That's right. In fact, it may be a good idea to add to the spec a description of a "Failed 0-RTT handshake." If I understand correctly, the following will happen:
> * Server will receive the client hello, ignore the Early Data Indication extension, and proceed as in 1-RTT.
> * Server will indicate that by not adding an Early Data Indication to the server hello.
> * Server will receive a series of 0-RTT messages that it cannot decipher, and just drop the messages.
> * Client will receive server hello, and proceed as per 1-RTT. Client API will signal that 0-RTT data was lost, application may decide to retransmit.
> * Server may send client authentication requests. Client will have to repeat the authentication messages, even if it already sent them as 0-RTT.
> In that scenario, the handshake hash cannot include the 0-RTT messages, since the server does not in fact receive them, and they do not contribute to the state of the connection. 
> We can of course debate whether the 0-RTT messages should also not be included in the hash if the 0-RTT exchange was successful, the messages were received, and they contributed to the state of the connection. If they are not included, then the "Finished" HMAC does not offer a protection against tampering. This may open the possibility of some kind of substitution or replay attack.
> The failed 0-RTT handshake scenario also has interesting consequences on the Record layer. We have a legitimate scenario in which received records cannot be decrypted. This should not trigger alarms. And the numbering scheme should be robust against these missing records.

Do we have anything that protects against an intermediary stripping 0RTT messages from a handshake to force a fallback?

Could we just make the handshake hash use the encrypted messages, regardless of if it can decrypt them? (maybe for all messages?)