Subject: Re: [Emu] Session tickets in TLS 1.3

From: John Mattsson <[email-masked]>
Date: Fri, 5 Feb 2021 19:25:23 +0000

Not sure that OpenSSL current default behavior is interesting for the draft. 

None of the Tickets in the draft are invalid.

The tickets in Figure 2 are different messages. 

Sending a ticket with Finished after asking for client auth seems like a implementaion bug.

As far as I understand, a server can send as many tickets it want in the same flight.

That said, sending several ticket in the full authentication does not help latency anymore. I will delete the second ticket from the draft.

John

---

From: Alan DeKok <[email-masked]>
Date: Fri, 5 Feb 2021 14:53:22 -0500

> Not sure that OpenSSL current default behavior is interesting for the draft. 

  I'm not sure what that means.

  Do we want to ignore the dominant TLS library?  And make the draft *incompatible* with it?

  Or is OpenSSL *wrong*?  i.e. does it implement the TLS spec incorrectly?

> The tickets in Figure 2 are different messages. 

  I do understand that.  But the diagram shows them in the same EAP-Request.  And from what I understand, they shouldn't be in the same EAP-Request.

> Sending a ticket with Finished after asking for client auth seems like a implementaion bug.

  Please reference RFC 8446 and explain why this is wrong.

> That said, sending several ticket in the full authentication does not help latency anymore. I will delete the second ticket from the draft.

  So... does the two-ticket case match how TLS works?  Or does the one-ticket case match how TLS works?  Which version of the figure is correct?  Why?

  I suggest that the diagrams have to be correct, and accurate.  Please explain *why* the diagrams have the content they do.

  Alan DeKok.