Depending on what the server does, there may also be downgrade implications, if the server uses some unauthenticated prior state to influence parameter selection.
On Fri, Sep 16, 2022 at 11:53 AM 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 >> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
