On Mon, Nov 14, 2022 at 11:28 AM Alan DeKok <[email protected]> wrote:
> 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. > Yes, I had thought you were talking about the server. I got confused because your text said "extension" but NewSessionTicket is not an extension but rather a handshake message. My mistake. > 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. > I agree that this is a defect. 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". > Yes, I agree with that. I would have thought this to be implicit in the spec, but I have filed https://github.com/tlswg/tls13-spec/issues/1280 to address it for 8446-bis. -Ekr
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
