Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

On Thu, Feb 4, 2021 at 12:57 AM John Mattsson <[e-mail]>
wrote:

> Hi,
>
>
>
> I think the idea of a new TLS extension to make TLS 1.3 and EAP-TLS
> interact better is a very promising idea. This would probably take some
> time to get specified and implemented so it is probably a future
> optimization/simplification rather that something EAP-TLS 1.3 should wait
> for.
>
>
>
> An extension that "I do not send any post-handshake messages" would work
> and remove the need for a commitment message.
>
>
>
> ------------------------------------
>
> NoPostHandShake Extension
>
> ------------------------------------
>
>
>
> Clients MAY send this extension in ClientHello. It contains no data.
>
>
>
> Servers MAY send this extension in EncryptedExtentions. It contains no
> data.
>
>
>
> When the "NoPostHandShake" extension is negotiated, the server MUST NOT
> send any post handshake messages.
>
>
>
> -------------------------------------
>
>
>
> However, this would also stop the client from doing resumption which is
> also very important. EAP-TLS fragments TLS into a large number of
> round-trips, and database lookup to authorize clients is often slow, so
> resumption is essential to get good performance.
>
>
>
> The current Post-Handshake NewSessionTicket is not well-suited for EAP-TLS
> as is introduces the demand for the commitment message as well as
> introducing an extra round-trip.
>

I don't really understand what EAP needs here, but it seems to me that the
commitment message (or the close_notify) is serving two purposes:

1. Saying that the handshake completed successfully
2. Saying that there will be no more messages

I understand from the discussion that knowing that there will be no more
messages is useful. Do you think that the client knowing that the handshake
completed is unnecessary?

-Ekr