er 16, 2022 12:01 PM
> *To:* David Benjamin
> *Cc:* Andrei Popov ; 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:
>
>
>
&g
t: 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 o
>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
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
wrote:
> I too am not seeing the use case here. Could you elaborate?
>
> Since browse
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 c
* 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
