On Fri, 16 Sep 2022, 21:35 Andrei Popov, <andrei.po...@microsoft.com> wrote:
> > - - 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. > > > Fair point. > > - - 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. > TLS doesn't have methods for selecting RSA key length. Too short keys may be rejected by client, and using long key always is too expensive when done for each handshake. > > > - 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> > 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 > <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
