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

[Eric Rescorla <[e-mail]>]

On Fri, Jan 29, 2021 at 12:02 PM Alan DeKok <[e-mail]>
wrote:

>   This is a new message to summarize history, requirements, etc. for
> EAP-TLS and TLS 1.3.  The focus here is the requirements for EAP-TLS, and
> how the 0x00 commitment message versus CloseNotify meets those.  I'll
> ignore the exporter changes here, as those are less controversial.
>
>   The original proposal in the EAP-TLS draft was to send a zero-length
> application data message in order to signal that no more post-handshake
> messages were needed.  From the -05 version:
>
>    When an EAP server has sent its last handshake message (Finished or a
>    Post-Handshake), it commits to not sending any more handshake
>    messages by appending an empty application data record (i.e. a TLS
>    record with TLSPlaintext.type = application_data and
>    TLSPlaintext.length = 0) to the last handshake record.  After sending
>    an empty application data record, the EAP server may only send an
>    EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert
>    Message.
>
>   However, the OpenSSL APIs (among others) do not allow for sending zero
> octets of application data.  The proposal was then changed to send a 0x00
> octet.
>
>  There was discussion that CloseNotify could achieve the same goals.  But
> CloseNotify requires an additional round trip.  There are strong opinions
> that additional round trips are bad.
>
>   In addition, CloseNotify prevents the TLS layer from sending a TLS Fatal
> Alert:  https://www.mail-archive.com/[e-mail]/msg03092.html


I agree that extra round trips are bad, I'd like to take a step back
here and think about what this message is trying to do. Here's
the relevant text:

   TLS 1.3 [RFC8446] introduces Post-Handshake messages.  These Post-
   Handshake messages use the handshake content type and can be sent
   after the main handshake.  One such Post-Handshake message is
   NewSessionTicket.  The NewSessionTicket can be used for resumption.
   After sending TLS Finished, the EAP-TLS server may send any number of
   Post-Handshake messages in separate EAP-Requests.

The relevant question is when the server knows what post-handshake
messages it will send. There are two points at which the server might
wish to send post-handshake messages:

1. After the server's first flight.
2. After the client's second flight.

Let's take the second case first. If the server is sending (or
potentially sending) post-handshake messages after the client's second
flight (e.g., after reading its certificate), then it can easily send
a close_notify after sending all of them. This will appear in the same
flight as the commitment message would have (because you can't send it
before the post-handshake messages) and avoid the need for an extra
round trip.

The first case, where the commitment message is sent in 0.5-RTT,
is the interesting one. However, the server has no more information
after sending SFIN than it does sending EE, so I believe that the
easiest way to deal with this is with a TLS extension that says
"I do not send any post-handshake messages". This would still
leave the server free to send any relevant alerts in response to
the client's second flight.

-Ekr