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

Eric Rescorla <> Thu, 24 December 2015 22:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 88D5E1A6F57 for <>; Thu, 24 Dec 2015 14:14:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.677
X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jV6_8EeVLKAz for <>; Thu, 24 Dec 2015 14:14:57 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 16C261A6F51 for <>; Thu, 24 Dec 2015 14:14:57 -0800 (PST)
Received: by with SMTP id x67so45226400ykd.2 for <>; Thu, 24 Dec 2015 14:14:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hsvwySKQsN1S1tlcHA+tdSvEcY4xCB8nWloo9BcYsFU=; b=GiKDlbAPYo9wmrosrUDloiccCTtbkU7u4QlwzwyKGS+TD+4r94Jprq3zsikJaJv+/U niCXO/s1Zg1rUNkHFB3XlyQEMfdIgnif2Agb60QlcfYi0xpaLoHvKnsJLJLxT/tk5L7Z QuPm0Lm+0+l+wah2zIJz+0LGX/gWSBNZwJkoBkm6kYsBvwFk3DhFflSnsbNCyq0mG29I vKSve0KH7dr+CaHULqRivVnkVrTmmcpEbULbY3KN5ZhdAC3+QMeDRUfYgrdPjbd+I8ZC 0ZNcKEnwK5R/osbBSwpQMeY8ZFswIu0Aq8bFY/TeINTy83I0U0CJhOuEbrjDKkWZ4g39 oukg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hsvwySKQsN1S1tlcHA+tdSvEcY4xCB8nWloo9BcYsFU=; b=jVEu/PpPXZedUnPPi1YfJcezj1tgov/ViD+C8aDNWYiM0dlH+SUBdvc5ffmuS1NLLg eEtbnXfvyk/ZOwhGSvgb6ge3xSS5NMMl1l3zGP41CKY4pjxQzn6wwf1XSqBZvxq7GcZs Xwe4MztIsjqGIxv7Lyoyp8WaLsbGWgItNrKUh/QiesO+gIzdqGUNnq79m+xgdGXs7OXf nwhg4iLQ5zdR4aHlsIDc94RxBOPL/1dB3cu059PUbKvNuRFV2XpROb3ybvoQ3j3UhSwj cuRv9bZF7OW/ndKIxaL565wGwo0uqkgXSB91HRQm7QMP3PfePImsG2hOdJzTVAn6uXEN 9URg==
X-Gm-Message-State: ALoCoQme2Jr1xLyvoicRIEuZKjpiO9Nr4hgA7cJLnJEMtVn9ZvL3JRYI6q3lK+8tFaqLEleiUiu9DLb9x9cN1loXctYPi1FOVA==
X-Received: by with SMTP id c4mr34291405ywd.192.1450995296409; Thu, 24 Dec 2015 14:14:56 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 24 Dec 2015 14:14:17 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Eric Rescorla <>
Date: Thu, 24 Dec 2015 17:14:17 -0500
Message-ID: <>
To: Dave Garrett <>
Content-Type: multipart/alternative; boundary=001a114caa9e36cf020527ac2be6
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:14:58 -0000

On Thu, Dec 24, 2015 at 5:01 PM, Dave Garrett <>

> On Thursday, December 24, 2015 04:48:58 pm Eric Rescorla wrote:
> > On Thu, Dec 24, 2015 at 4:26 PM, Dave Garrett <>
> > wrote:
> > > Do we have anything that protects against an intermediary stripping
> 0RTT
> > > messages from a handshake to force a fallback?
> >
> > Yes:
> > 1. The EarlyDataIndication tells the server that some 0-RTT messages are
> > coming.
> > 2. The Finished in the 0-RTT flight covers the entire handshake flight,
> > thus preventing
> > tampering with those messages.
> > 3. The server's Finished covers the ClientHello, thus preventing
> tampering
> > with that.
> #1 & #3 are easily dealt with by injecting bogus 0-RTT messages that get
> rejected, at which point a 0RTT could be prevented and we won't get to #2.
> 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
(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

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.


[0] Technically speaking, it should be possible to send ServerHello before
even reading
the remainder of the first flight.