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

Christian Huitema <huitema@microsoft.com> Tue, 22 December 2015 02:26 UTC

Return-Path: <huitema@microsoft.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085321AD0C9 for <tls@ietfa.amsl.com>; Mon, 21 Dec 2015 18:26:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dPWRv8dNAuX for <tls@ietfa.amsl.com>; Mon, 21 Dec 2015 18:26:03 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88D681AD0B4 for <tls@ietf.org>; Mon, 21 Dec 2015 18:26:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8djJy0XkR/Cz2jXhOSf5pK9TZ5SOlPyb+P7u5Cc0H6Q=; b=a8baHyvssk4aMyI+xRCg9nLrr4vqtWndCwKV/kZYpwOfuNk1XYptxJxsNmW8OOXSW6eq16tERNf2KIz8SnVw9zFbhMnrBZHDuFF+c/Zj+oBF/7fNDf1scoqrknkCv02zXh2cPv6TdqY8F4se2RB9A8Xd2aM3YvbpbuF8ea/pVQg=
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0653.namprd03.prod.outlook.com (10.160.96.15) with Microsoft SMTP Server (TLS) id 15.1.361.13; Tue, 22 Dec 2015 02:25:44 +0000
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0361.006; Tue, 22 Dec 2015 02:25:44 +0000
From: Christian Huitema <huitema@microsoft.com>
To: Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [TLS] What does it mean to not include 0-RTT message in the handshake hash?
Thread-Index: AdE8WUzTusUbdu5EQyy4pojDDNAspQAA40EAAACQIQA=
Date: Tue, 22 Dec 2015 02:25:44 +0000
Message-ID: <DM2PR0301MB065553EAD2849CF405A3D33FA8E50@DM2PR0301MB0655.namprd03.prod.outlook.com>
References: <DM2PR0301MB06555FC15830293E0C4E381AA8E50@DM2PR0301MB0655.namprd03.prod.outlook.com> <CABcZeBO3F067nJ=maZDbH4-jg1kFZwck7qXUOYbttr3VO9Ykrg@mail.gmail.com>
In-Reply-To: <CABcZeBO3F067nJ=maZDbH4-jg1kFZwck7qXUOYbttr3VO9Ykrg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com;
x-originating-ip: [2001:4898:80e8:c::7a9]
x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0653; 5:XKAEDQFP3A5V8OT5/YRT4wDsCICu2rcjM+VzJ5lz32bJxvPnGoFiu3fGTGuaNtEyuHy+KU8kZDmUKSwAOMJe1G6ZiPTEdkGWMBXQ6DeXBoxA3ZA1zG0iSZuAOJnQAMUIrDF/mJ0EWMWcbGHCOqJgfQ==; 24:JCdkA4UP4Fv22YphQV6l8o8bLHZKf0LcFfhQTyDbWFfgVI/QvXivvCsmgr1+usahMBPSPPdwmaLw95mwg1wmrqIg/JIZqkKUzFqnkp7A0BE=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0653;
x-microsoft-antispam-prvs: <DM2PR0301MB06531E3C9F0F12332367216BA8E50@DM2PR0301MB0653.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653;
x-forefront-prvs: 0798146F16
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(5001960100002)(189998001)(10090500001)(74316001)(81156007)(110136002)(1220700001)(1096002)(11100500001)(105586002)(106356001)(101416001)(97736004)(586003)(33656002)(99286002)(102836003)(77096005)(5008740100001)(54356999)(87936001)(86612001)(5004730100002)(76576001)(76176999)(86362001)(40100003)(50986999)(10400500002)(5005710100001)(10290500002)(8990500004)(5003600100002)(5002640100001)(92566002)(2950100001)(2900100001)(122556002)(6116002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com 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-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2015 02:25:44.7899 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ADt1BphKHVc-u3cGTaLnV_G3fdU>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake hash?
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Dec 2015 02:26:06 -0000

> You're referring the editor's copy (WIP-11), right?

Yes.
...
> I was just going over this text today and realized it's kind of confusing
> (and the whole "handshake_hash" abstraction is starting to be less useful
> in light of the PR#316 reframing of the authentication block).

Yes, the "handshake hash" is indeed confusing. Specifying something like "all messages up to <some point>" is simple enough. But there are several such points, used at different stages. Server Hello, Server certificate verify, Server Finished, Client certificate verify, Client finished.. It would be a bit more clear to give each of them its own name.

> 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...

> Trying to figure out the best way to clarify this text. PRs welcome :)

Yes of course...

-- Christian Huitema