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 <tls-boun...@ietf.org> on behalf of Eric Rescorla <e...@rtfm.com>
Date: Monday, 1 February 2021 at 15:56
To: Alan DeKok <al...@deployingradius.com>
Cc: EMU WG <emu@ietf.org>, Benjamin Kaduk <ka...@mit.edu>, "t...@ietf.org"
<t...@ietf.org>
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
<al...@deployingradius.com<mailto:al...@deployingradius.com>> 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/emu@ietf.org/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
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
