* - processing of invalid session ID, if it is repeated in the 2nd attempt, can be omitted using a smaller cache on the server side Invalid session ID should not lead to handshake failure; it results in a full handshake and an updated session ID/ticket.
* - a server having more than one valid certificate for the domain name, can switch between them in various attempts. Sure, but arguably TLS has reasonable methods for driving certificate selection, in terms of signature/hash suites. * A cleartext correlator between different requests like this would also be a privacy concern and seems to run counter to the work in RFC 8446, appendix C.4. Correct. I'm trying to see what the use-case would be, regardless of the proposed design. From: Dmitry Belyavsky <beld...@gmail.com> Sent: Friday, September 16, 2022 12:01 PM To: David Benjamin <david...@chromium.org> Cc: Andrei Popov <andrei.po...@microsoft.com>; TLS Mailing List <tls@ietf.org> Subject: Re: [TLS] [EXTERNAL] Opt-in schema for client identification >From the top of my head I can imagine 2 sort of real-life scenarios: - processing of invalid session ID, if it is repeated in the 2nd attempt, can be omitted using a smaller cache on the server side - a server having more than one valid certificate for the domain name, can switch between them in various attempts. I agree with Andrei that other parameters are chosen either according to client or to the server preferences. On Fri, Sep 16, 2022 at 8:53 PM David Benjamin <david...@chromium.org<mailto:david...@chromium.org>> wrote: I too am not seeing the use case here. Could you elaborate? Since browsers were mentioned as an example, when Chrome makes several connections in a row (e.g. to measure impacts of a removal more accurately), we generally do not expect the server to change its selection algorithm across the two connections. A cleartext correlator between different requests like this would also be a privacy concern and seems to run counter to the work in RFC 8446, appendix C.4. On Fri, Sep 16, 2022 at 10:09 AM Andrei Popov <Andrei.Popov=40microsoft....@dmarc.ietf.org<mailto:40microsoft....@dmarc.ietf.org>> wrote: * Server can distinguish the client and alter some parameters in response to make the new connection successful. A TLS server would typically choose either server-preferred parameters (cipher suite, EC curve, etc.) among those advertised by the client, or honor the client's preferences. Can you give some examples of what a TLS server would alter, to make the new connection successful, assuming the 2nd ClientHello has the same list of options as the 1st one? Basically, what types of interop failures is this cookie intended to resolve? * Modern real-life applications (e.g. browsers) may perform several handshakes in a row until the connection to the server is finally rejected. Some TLS clients will vary their offered TLS parameters between these connection attempts. Cheers, Andrei From: TLS <tls-boun...@ietf.org<mailto:tls-boun...@ietf.org>> On Behalf Of Dmitry Belyavsky Sent: Friday, September 16, 2022 4:32 AM To: TLS Mailing List <tls@ietf.org<mailto:tls@ietf.org>> Subject: [EXTERNAL] [TLS] Opt-in schema for client identification Dear colleagues, I'd like to suggest an opt-in cookie-style schema allowing the server to identify the client in case when a client performs several unsuccessful connection attempts. Modern real-life applications (e.g. browsers) may perform several handshakes in a row until the connection to the server is finally rejected. It may make sense to provide different handshake parameters on the server side on the consequent attempts. To distinguish the same client from several different clients, it may be useful to add a cookie-style extension in ClientHello. The server responds with an encrypted extension containing a random value in a ServerHello. If the connection fails, a client may send a value received from the server in the next connection attempt. Server can distinguish the client and alter some parameters in response to make the new connection successful. The schema differs from the current session/tickets mechanism because the current mechanism implies session resumption only for successfully completed handshakes. As the schema is opt-in, it doesn't provide any extra surveillance opportunities. I understand that the proposed schema may badly work with CDNs. If there is an interest to my proposal, I could draft it and present on the upcoming IETF meeting. -- SY, Dmitry Belyavsky _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C01%7CAndrei.Popov%40microsoft.com%7C38aed490bde840d9809d08da98165079%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637989518872154364%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=W7wN3D%2F1eKzp2An8BR4laCg9a%2Bmi8UnsonV04c3rL3k%3D&reserved=0> -- SY, Dmitry Belyavsky
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
