Re: [TLS] Comments on EndOfEarlyData

On Tue, May 16, 2017 at 2:59 PM, Eric Rescorla <ekr@rtfm.com> wrote:

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

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

>
>
> 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
>>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>