Re: [TLS] Comments on EndOfEarlyData

Eric Rescorla <ekr@rtfm.com> Tue, 16 May 2017 19:05 UTC

Return-Path: <ekr@rtfm.com>
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 AD3DD129526 for <tls@ietfa.amsl.com>; Tue, 16 May 2017 12:05:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 U0AHGgJCICwX for <tls@ietfa.amsl.com>; Tue, 16 May 2017 12:05:21 -0700 (PDT)
Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 319E712EC82 for <tls@ietf.org>; Tue, 16 May 2017 12:00:39 -0700 (PDT)
Received: by mail-yb0-x235.google.com with SMTP id j17so37757576ybj.0 for <tls@ietf.org>; Tue, 16 May 2017 12:00:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EOQzo3oxnQ3ArRc45bddyWvFIID2XgcYwIRKM5+uR2k=; b=IB+ZxtjAZtLoPQ/2JB5I9+H4Ojcl6L8mDm6mRA9HzW3e4RzsRZDogGoTiGE9MTGJWa rYL0tzZz2AJoDY/FThK9Tok5nAeq/PDjvLIWsbrO4wKZIU65y5bAKLiB9ePAY1J9TqRD FgCkwQZ6EiTldrWZCe6xnxWJFGor0kERiz4QYXLcW6YHIIcP+hNOMlLg2+r7iZMbm6++ Vwte4E76pf9uCZxUP3VnL8id1bG23ieA+mwyDpd8JrYW9jz5bDGQMyO1iademAPkB5b3 rWVBAxy0srq51oTO4L/2C1WA7MhehM7ljrSoXMhAzt47EJUdsL55bXgyA5nVZIfvp1ZO JaDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EOQzo3oxnQ3ArRc45bddyWvFIID2XgcYwIRKM5+uR2k=; b=HvpPF+mWL62IyN1N2FdAmf7zKZxA6/879/kJVqhcla1sv7dM77oVCh3IBKYoC3SUq6 6cJ5nYy8LrgEiot3r5DBUgJ6qaxoNS7lH8QiamAlEanzVfa9TxPR3nQG31GwybSHjHxP a8h/d6gDy1F2wngCe4lnQS6M8sdw8HKKdq29VEuP8Oo/pQwY5Z8iwODXLENuRDWY0Cbz Z+CN6rhWfgvQfFkKmquOyzSVJ2MDRx6i3xfROKh4dRqFO6ag+jhZHUl46fpPZgMua2ef +imjkmXmhMZdVcL2EV4djmziOGnreRCJtwlat8zI/J1e0LddyhKQjL7CtErY/ZJpnISy 7Xsw==
X-Gm-Message-State: AODbwcDhM3ujeWk98i4IFekHRIeya2stx393pCWmQ49O3XccRmFtqpum MjiwuGc0VfUi1YLmUDIjMIJOrFtYfQ8o
X-Received: by 10.37.41.130 with SMTP id p124mr11367915ybp.24.1494961238385; Tue, 16 May 2017 12:00:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Tue, 16 May 2017 11:59:57 -0700 (PDT)
In-Reply-To: <66025639-5ceb-021a-61c4-60620c402a6c@ntnu.no>
References: <66025639-5ceb-021a-61c4-60620c402a6c@ntnu.no>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 16 May 2017 11:59:57 -0700
Message-ID: <CABcZeBMu=9KPvmz-sDknXpa4Vjer=md=ZqsFqGd6WNEFdAxSdg@mail.gmail.com>
To: Britta Hale <britta.hale@ntnu.no>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c14d834914546054fa8c9d7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1WSS03hH3_6v-WF5pMutFbqmjvY>
Subject: Re: [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: Tue, 16 May 2017 19:05:23 -0000

First, let me say I'm largely indifferent to this handshake versus alert
point, so if the WG wants to flip it back, I'm generally OK with that.
With that said, we recently implemented -20 and having it be
a handshake message is somewhat cleaner.


On Tue, May 16, 2017 at 8:30 AM, Britta Hale <britta.hale@ntnu.no> wrote:

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


This last sentence seems to reinforce the motivating intuition here,
namely that the alert signals the end of the *connection*, and so it's
odd to have EOED indicate a key change within a 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.
>

Indeed, but that's a session, not a connection


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

I can see how you could look at it this way, but I'm not sure that that's
the natural way to look at it. If you're not doing DH, then these are
very much derived from the same PSK and the same client-side
nonce.


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.


Well, we also mix unencrypted traffic into the Finished, right? Does this
present a practical problem for analysis?

-Ekr

Britta
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>