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

[John Mattsson <[e-mail]>]

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. The NewSessionTicket mechanism is both complex and inefficient for EAP-TLS. Could a new ticket extension be designed that fits EAP-TLS better? Looking quickly it seems like it would be possible. It looks like the current NewSessionTicket mechanism was designed with a requirements to only use symmetric crypto. This would not be important for EAP-TLS.

The below quickly written suggestion use the same PSK derivation as NewSessionTicket, but makes the ticket_nonce a sequence, and use asymmetric HPKE encryption for client privacy.

------------------------------------
ImplicitTicket Extension
------------------------------------

Clients MAY send this extension in ClientHello. It contains the following structure:

struct {
                uint16 ticket_count_request;
} ImplicitTicketRequest;

With the ImplicitTicketRequest, the client requests ticket_count_request implicit tickets.

A server MAY send this extension in EncryptedExtentions. It contains the following structure:

struct {
                uint16 ticket_count;
                opaque hpke_pk<1..2^16-1>;
                uint32 ticket_lifetime;
                opaque ticket<1..2^16-1>;
   Extension extensions<0..2^16-2>;
} ImplicitTicketResponse;

When the "ImplicitTicket" extension is negotiated, it provisions ticket_count number of tickets. The tickets all have the same lifetime and extensions.

When doing resumption based on an implicit ticket, the identity is constructed as follows:

  identity = ENC(hpke_pk, ticket || ticket_seq || ticket_age_add )

  The uint16 ticket_seq is a that sequence that increases for each ticket the client uses. Valid values are 0..ticket_count-1.

  ticket_age_add in the identity replaces the ticket_age_add normally sent in the in the NewSessionTicket message.

  ticket_nonce is set to ticket_seq and the PSK associated with the ticket is computed as defined in RFC 8446.

---------------------------------

Used together, two such extentions would effectively solve all the EAP - TLS 1.3 related issues as they were known a month ago. There has since been discussion if EAP-TLS 1.3 needs keys derived from the client second flight, but I think more analysis before determining if that is the case or not.

Cheers,
John


From: TLS <[e-mail]> on behalf of Eric Rescorla <[e-mail]>
Date: Monday, 1 February 2021 at 15:56
To: Alan DeKok <[e-mail]>
Cc: EMU WG <[e-mail]>, Benjamin Kaduk <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)



On Fri, Jan 29, 2021 at 12:02 PM Alan DeKok <[e-mail]<mailto:[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<https://protect2.fireeye.com/v1/url?k=16c4ad4c-495f9461-16c4edd7-8692dc8284cb-f1f3f2750d360a2a&q=1&e=36033566-ffb1-4757-9586-079c8d5e94a5&u=https%3A%2F%2Fwww.mail-archive.com%2Femu%40ietf.org%2Fmsg03092.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