Re: [TLS] Comments on EndOfEarlyData

Richard Barnes <> Tue, 16 May 2017 17:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC4A71293F3 for <>; Tue, 16 May 2017 10:48:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id omrdzUyg3YqR for <>; Tue, 16 May 2017 10:48:29 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B495912944C for <>; Tue, 16 May 2017 10:43:34 -0700 (PDT)
Received: by with SMTP id w50so81330075wrc.0 for <>; Tue, 16 May 2017 10:43:34 -0700 (PDT)
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; bh=xm/lnQOuqLkXzG+/WtR0Hr+YFtvpzTyoqD701kS4qkY=; b=ri8leqZFXGNv88ljZHhcHo9fsY5u8/R1YXu7Sz9JvwF8pLNObAZmd9PFJ2BlkV5Kol amma4w3+ZcrXRZx+RCcdrtMC7NWnNztfXp65szPt1gm63lZ9UIGWwEKMlGQDQepbK71/ 0iPSSJVooUvhY2tGBFSYr6HzSNappwEGD5he433Sd8FSv/PCNnxQ/BlPBynbGvQOhw1F Zoyw2y0nMOtV31X9KN0vi5jXjEzCgLyp4BsLm/70yl0LQIPr14E2xMSC3aV89BEK/vI3 23+CvmsDYzgom9/d+LqQmEJwHKi9lC/mlX68d2PWQv8AjYW7nXs5azXpCgmVC/c9b5g8 334g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xm/lnQOuqLkXzG+/WtR0Hr+YFtvpzTyoqD701kS4qkY=; b=lpluAuMY0F9NJe0/xl98mzDc35Q2VtFjz3r0Q8b2y5JW6BY0kJjeGDe94XKYhNSQby QwSOCIpaAs6RSYpmekPaPEvXZCnJ1tCqHqCthy1cMx1eeGOuvP2eEsLAlc/GXiXfftg+ kVByEtWCs01trarreix++uXtjN39VtlYI/Ho+GvyU8AWMUfJRrLavj3P28hUeDaHB0J+ /8dXTIcD94707Ro7CfT5/NbYiTvPqZFGgYAnrfEQb9DvwpGfNUMEpxOR3BCp++brpkzi lKf4RJGeVqoXi+L+hBPMlEDyJWU7P4YCZ+H4n0J2FtzevrUpGujLvhLQf/TU0tXli63w l9yA==
X-Gm-Message-State: AODbwcBTuybXGjWLO3XAVj6cUnU7pIbB7pyGlc1QYyCD191X+WpbFRbx TifKIWfK6NGwEPCdlKY+mp5qPMjOUNRk
X-Received: by with SMTP id q7mr8327185wrb.180.1494956613068; Tue, 16 May 2017 10:43:33 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 16 May 2017 10:43:32 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Richard Barnes <>
Date: Tue, 16 May 2017 13:43:32 -0400
Message-ID: <>
To: Britta Hale <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="f403045f4ec4e0a2f9054fa7b55b"
Archived-At: <>
Subject: Re: [TLS] Comments on EndOfEarlyData
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 May 2017 17:48:32 -0000

On Mon, May 15, 2017 at 11:16 AM, Britta Hale <>

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

As has been pointed out elsewhere, other key changes are signaled with a
handshake message (KeyUpdate), so using a handshake message seems more
natural from a protocol point of view.

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

The Finished MAC already mixes data from two different traffic keys
(client/server) and data aren't encrypted at all (ClientHello /
ServerHello).  If you want to argue that the client and server handshake
keys are related by both being derived from the handshake_traffic_secret,
you could just as well argue that all three keys are related by all being
derived from EarlySecret.


> ---
> Britta
> _______________________________________________
> TLS mailing list