Re: [TLS] [EXTERNAL] Opt-in schema for client identification

On Fri, 16 Sep 2022, 21:35 Andrei Popov, <Andrei.Popov@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 <beldmit@gmail.com>
> *Sent:* Friday, September 16, 2022 12:01 PM
> *To:* David Benjamin <davidben@chromium.org>
> *Cc:* Andrei Popov <Andrei.Popov@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 <davidben@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.com@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-bounces@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
>