[TLS] Comments on EndOfEarlyData
Britta Hale <britta.hale@item.ntnu.no> Mon, 15 May 2017 15:21 UTC
Return-Path: <britta.hale@item.ntnu.no>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD3F129486 for <tls@ietfa.amsl.com>; Mon, 15 May 2017 08:21:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.503
X-Spam-Level:
X-Spam-Status: No, score=-1.503 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 gCiX4LR7suCn for <tls@ietfa.amsl.com>; Mon, 15 May 2017 08:21:05 -0700 (PDT)
Received: from samson.item.ntnu.no (samson.item.ntnu.no [129.241.200.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E13E124281 for <tls@ietf.org>; Mon, 15 May 2017 08:16:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by samson.item.ntnu.no (Postfix) with ESMTP id 72EB648008D for <tls@ietf.org>; Mon, 15 May 2017 17:16:04 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at item.ntnu.no
Received: from samson.item.ntnu.no ([127.0.0.1]) by localhost (samson.item.ntnu.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RK_pi8CjM4Kl for <tls@ietf.org>; Mon, 15 May 2017 17:16:03 +0200 (CEST)
Received: from [129.241.200.211] (dhcp-200-211.item.ntnu.no [129.241.200.211]) by samson.item.ntnu.no (Postfix) with ESMTPSA id E19D7480087 for <tls@ietf.org>; Mon, 15 May 2017 17:16:03 +0200 (CEST)
From: Britta Hale <britta.hale@item.ntnu.no>
To: tls@ietf.org
Message-ID: <83ddc562-aca3-7525-b5d6-714d2b84ae97@item.ntnu.no>
Date: Mon, 15 May 2017 17:16:03 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="1Ug5FEA3AGIdaMMwf8dmWIE4J6dujax7M"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/OzVrSz6dZ5oEEvKvUutgIQJXe7g>
X-Mailman-Approved-At: Tue, 16 May 2017 10:31:45 -0700
Subject: [TLS] Comments on EndOfEarlyData
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 15 May 2017 15:48:22 -0000
On the Sunday 30/05 TLS:DIV workshop there was mention of the EndOfEarlyData message and its status as a handshake message or alert message. The main argument mentioned for making EndOfEarlyData a handshake message is that alert messages usually signal "abortive closure of the connection" (e.g. fatal alerts). Having an EndOfEarlyData alert could be misleading (i.e. possibly implying that a session is ending instead of beginning). However, this intuition is incorrect. Alerts signal the end-of-use of keys, not the prohibition of further communication under other keys. Keys should be deleted and no further data should be sent on the connection. For TLS 1.2 (7.2.1) it is even made explicitly clear that session resumption is possible after a close_notify send/receipt. It seems natural then to make EndOfEarlyData an alert message, signifying end of 0-RTT data. Specifically, the 0-RTT handshake is followed by 0-RTT data and finally an EndOfEarlyData alert to end use of that key, while in parallel the remainder of the handshake and subsequent session key act almost as a further resumption (i.e. under a different key). Making EndOfEarlyData an alert message also allows for clear key boundaries: if EndOfEarlyData is a handshake message, then we are mixing messages protected by the the client_early_traffic_secret and handshake_traffic_secret in the Finished message. --- Britta
- [TLS] Comments on EndOfEarlyData Britta Hale
- Re: [TLS] Comments on EndOfEarlyData Richard Barnes
- Re: [TLS] Comments on EndOfEarlyData Nico Williams
- Re: [TLS] Comments on EndOfEarlyData Eric Rescorla
- Re: [TLS] Comments on EndOfEarlyData Nico Williams