On Nov 14, 2022, at 1:09 PM, Eric Rescorla <[email protected]> wrote:
> I'd like to have a way to say "if you don't support session tickets, just
> ignore them".
>
> Again this text is not quite right because
I think you're talking at cross purposes to the problem I'm trying to
describe.
> Can you explain how you got into this posture? The only reason a client
> should be sending session tickets is if it received one
> from the server.
The problem isn't that. The problem is long before the client tries to
reconnect. The problem is the client, not the server. The problem is that the
initial connection to the server is never successful. It has nothing to do
with other uses of PSKs. It has nothing to do with clients sending anything to
the server.
The flow is this:
Client connects to server.
Client and server exchange TLS information. They're both happy with
everything.
Server eventually sends a session ticket to the client.
Client goes "OMFG" and hangs up. No more TLS session.
Repeat ad nauseam until server administrator (a) forbids the use of TLS
1.3, or (b) forbids session tickets.
Windows 11 is doing this today with TLS-based EAP methods. It's a disaster.
Hence my text "if the client gets a session ticket, it is NOT a reason to
tear down the TLS session". The errata was filed explicitly against the text
discussing the client, and discussing the clients behavior when it received
session tickets.
Again, from Section 4.6.1.:
The client MAY use this PSK for future handshakes by including the
ticket value in the "pre_shared_key" extension in its ClientHello
and by *implication* the client also does not need to use the session ticket.
It is free to use the session ticket, or to ignore it entirely.
What the client is *not* free to do is to treat the session ticket as a TLS
connection failure. This behavior can best be described as "surprising".
Alan DeKok.
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
