>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> 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> 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> *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 >> > -- SY, Dmitry Belyavsky
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
