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