Subject: [Emu] Session tickets in TLS 1.3

From: John Mattsson <[email-masked]>
Date: Fri, 5 Feb 2021 15:42:42 +0000

Some quick comments below:

Alan DeKok wrote:

>So it's possible for a malicious client to get the ticket, and close the connection without >sending a client cert.  Then, if the EAP server doesn't destroy the ticket, the client can >reconnect.

The resumption_master_secret includes the client finished so the client in your handshake with client authentication should not be able to reconnect, if it can it is an OpenSSL bug. Alternatively the server did not ask for client authentication and it is ok that the client reconnects.

>The packet flows in Figure 2 of draft-14 shows only one exchange of session tickets, not 2.

Looks to me that the Figure 2 of draft-14 provisions two tickets...?

                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                                               (TLS NewSessionTicket,
                                                TLS NewSessionTicket,
                                 <--------          TLS close_notify)

Cheers,
John

---

From: Alan DeKok <[email-masked]>
Date: Fri, 5 Feb 2021 10:51:18 -0500

> The resumption_master_secret includes the client finished so the client in your handshake with client authentication should not be able to reconnect, if it can it is an OpenSSL bug. Alternatively t…

  At a high level, if there are two session tickets, then the draft should explain *why* one of them is invalid.

>                                 <--------          TLS close_notify)

  My reading of the TLS specs && OpenSSL indicates that there are not only two tickets, but the tickets are in different messages.

  i.e. the first ticket is in the same packet when the server sends "TLS Finished".

  After the server receives the client certs, it goes "whoops", and issues a *new* session ticket in the next packet.

  So no packet should have *two* session tickets.

  Alan DeKok.