* 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> On Behalf Of Dmitry Belyavsky Sent: Friday, September 16, 2022 4:32 AM To: TLS Mailing List <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 https://www.ietf.org/mailman/listinfo/tls
