Subject: [TLS] Comments on EndOfEarlyData

From: Britta Hale <[email-masked]>
Date: Tue, 16 May 2017 17:30:51 +0200

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 16 May 2017 12:00:53 -0400

Would we also send an alert on key update?

On 16 May 2017 at 11:30, Britta Hale <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 May 2017 11:59:57 -0700

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 <[email-masked]> wrote:

> 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

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

> subsequent session key act almost as a further resumption (i.e. under a

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.

> 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

---

From: Britta Hale <[email-masked]>
Date: Tue, 16 May 2017 23:10:08 +0200

> odd to have EOED indicate a key change within a connection.
Avoiding getting caught on the word "connection", EOED signals the end of key 
use like other alerts, which is the central issue. Notably, EOED does 
not signal key change, unlike a KeyUpdate message or Finished message - even 
the name indicates that it is for "end of data". Its behavior is fundamentally 
like an alert's, indicating only end-of-key use for application data. 

>> Specifically, the 0-RTT handshake is
In that case, they are both then related to the master key of the previous 
session, which may well have ended with a close_notify, i.e. a properly 
finished key use signaled by an alert.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 16 May 2017 17:24:28 -0400

> a handshake message is somewhat cleaner.

I'm inclined to keep EOED as a handshake message.  I also found it cleaner
to handle in my implementation than the alert-based alternative, especially
using the state machines added recently.

--Richard

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 May 2017 14:28:15 -0700

> like an alert's, indicating only end-of-key use for application data.
I'm not sure why you say it doesn't signal a key change: EOED signals the
transition
between data encrypted with the early traffic keys and that encrypted with
the handshake
key.

> Yes, that's true, but I'm not sure I see the relevance of this point.

-Ekr

---

From: Britta Hale <[email-masked]>
Date: Tue, 16 May 2017 23:41:06 +0200

> between data encrypted with the early traffic keys and that encrypted with

EOED signals the end of data encrypted with early traffic keys, yes, and the next 
message is the Finished message encrypted with the handshake traffic key. However, 
the Finished message is not *data*, and use of the application traffic key is signaled
by the Finished message, not EOED. The Finished message, like a KeyUpdate message, are 
handshake messages, and both signal the start of a new key use for application data. 
In comparison, EOED signals the end of key use for application data - which correlates 
to alert behavior.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 May 2017 15:25:07 -0700

> handshake messages, and both signal the start of a new key use for
In comparison, EOED signals the end of key use for application data - which
> correlates

This seems like a point where reasonable people can differ, especially as
ultimately
the motivation for this change was some sense of architectural consistency.

To go back to my earlier question: does this change actually present some
analytic
difficulty, or do you just find it unaesthetic?

-Ekr

---

From: Britta Hale <[email-masked]>
Date: Wed, 17 May 2017 00:57:55 +0200

> difficulty, or do you just find it unaesthetic?
It is a matter of consistency not aesthetics, and that has actual 
implications on analysis. 

Classifying message types is meaningful in terms of truncation attacks.
Under a application traffic secret, a receiver is only guaranteed protection 
from a truncation if it receives an alert (close_notify). According to the 
current draft, a server is only guaranteed protection from such an attack 
for 0-RTT data if it receives a handshake message. Such a difference is sloppy
in terms of analysis.

Furthermore, there is the inconsistency of placement of the EOED message in 
the Finished hash. The lack of synchronization of EOED, i.e. not being fixed 
with respect to the other handshake messages, could complicate analysis in 
terms of matching server/client transcripts.

-- Britta

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 16 May 2017 23:28:32 -0500

> implications on analysis. 

I think there are some unsupported (and unstated!) assumptions about
what framework in which to analyze things going on here.

> for 0-RTT data if it receives a handshake message. Such a difference is sloppy

For truncation attacks, maybe alert makes more sense.  In the area of
advancing the state machine without terminating the connection,
handshake makes more sense.  You are talking as if there is a single
right answer without stating your assumptions; you need to say more
about what you are assume and what analyses hinge on such assumptions if
you want your argument to carry much weight.

> terms of matching server/client transcripts.

The location in the handshake hash is well-specified in the "The
Transcript Hash" section -- it comes after server Finished.
It looks like we need to update the preceding table covering base key
generation to match, though.

-Ben