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

Christian Huitema <> Thu, 24 December 2015 20:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C569F1A1EF3 for <>; Thu, 24 Dec 2015 12:40:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u1Gy-ZALegFT for <>; Thu, 24 Dec 2015 12:40:50 -0800 (PST)
Received: from ( [IPv6:2a01:111:f400:fc10::768]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 431821A1EF5 for <>; Thu, 24 Dec 2015 12:40:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Lee3CfiVQe+c+c246d/72tAPhvSO1jCZB605LviO4KI=; b=PHQHMrFuhOJ4DCbyBucEyEBchaEeZvHtZcdp4p0RfWoy6YZvZOCBdNdiUY565VlauoOY+S448sSSac6iASmfdTAExG0CftntZCrB5yMFqd6c7COKxjmnNOnKPKfi6Yh6JpHRuwf9u8+DhYTMB/OKo5Yz1ds/h4uHcxizo24sSfA=
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.361.13; Thu, 24 Dec 2015 20:40:27 +0000
Received: from ([]) by ([]) with mapi id 15.01.0361.006; Thu, 24 Dec 2015 20:40:27 +0000
From: Christian Huitema <>
To: Martin Thomson <>
Thread-Topic: [TLS] What does it mean to not include 0-RTT message in the handshake hash?
Thread-Index: AdE8WUzTusUbdu5EQyy4pojDDNAspQAA40EAAACQIQAAAGOBgACJ8x0A
Date: Thu, 24 Dec 2015 20:40:26 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2601:600:8900:31e1:bd1a:2cd1:8ab4:db94]
x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0655; 5:i4m8T8LBetRuySsu4xmiC1uMFOMDoEAKuLzS7qYz5LPOGDuoruxWqKWBMzFC7R7SZodicXKdzAucBCSUHvZvurCerhtK5NXCZvPI5EwoLjbbIckX/OEmmYzuGu/zVOohG4L5RF5JoWzVcjRvWtZR0g==; 24:JGlXiqO6eJw/P7DvKR4dSx5S+Xwk/ltT7nKdJbY9Jc9IEoc2dXexgoZs9F7PJOnikRgUdx28hy4Q4G4LDfPtoeTp/4IDRNtsf9FQd4rne6A=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0655;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:DM2PR0301MB0655; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0655;
x-forefront-prvs: 0800C0C167
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(189002)(199003)(24454002)(110136002)(77096005)(5001960100002)(5004730100002)(586003)(92566002)(102836003)(5005710100001)(11100500001)(101416001)(76576001)(2950100001)(6116002)(87936001)(8990500004)(2900100001)(1096002)(1220700001)(5003600100002)(5002640100001)(40100003)(33656002)(19580405001)(10290500002)(19580395003)(122556002)(10400500002)(50986999)(5008740100001)(74316001)(54356999)(93886004)(189998001)(81156007)(97736004)(86362001)(10090500001)(99286002)(76176999)(86612001)(106356001)(105586002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0655;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Dec 2015 20:40:26.8212 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0655
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 20:40:54 -0000

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.

-- Christian Huitema