Re: [TLS] [EXTERNAL] Re: [Technical Errata Reported] RFC8446 (7250)

[Andrei Popov <[e-mail]>]

Hi Alan,


  *   Windows 11 is doing this today with TLS-based EAP methods.  It's a disaster.
I own TLS in Windows; please share the details with me, on a separate thread, so we can figure out what’s broken. It’s probably a bug in the SSPI caller (EAP in this case).

Generally though, I don’t think RFCs should be updated for an obvious implementation bug. Disconnecting on ticket receipt is just plain not reasonable. An unreasonable implementer won’t heed an RFC update😊

Cheers,

Andrei

From: TLS <[e-mail]> On Behalf Of Eric Rescorla
Sent: Monday, November 14, 2022 11:48 AM
To: Alan DeKok <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; RFC Errata System <[e-mail]>
Subject: [EXTERNAL] Re: [TLS] [Technical Errata Reported] RFC8446 (7250)



On Mon, Nov 14, 2022 at 11:28 AM Alan DeKok <[e-mail]<mailto:[e-mail]>> wrote:
On Nov 14, 2022, at 1:09 PM, Eric Rescorla <[e-mail]<mailto:[e-mail]>> 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.<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F4.6.1.%2F&data=05%7C01%7CAndrei.Popov%40microsoft.com%7Cf449a9b7a1cf494c438108dac6795640%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638040522545624870%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bcUADsU0lRk3bHxr1ZE54TEta6iasRM2s0F1NGFU6FQ%3D&reserved=0>:

  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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftlswg%2Ftls13-spec%2Fissues%2F1280&data=05%7C01%7CAndrei.Popov%40microsoft.com%7Cf449a9b7a1cf494c438108dac6795640%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638040522545624870%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=YwCmwR%2Fy1mgA8RKIpjQthLNIriQ%2Bky9qJZoAXP9gC8A%3D&reserved=0> to address it for 8446-bis.

-Ekr