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
Hi Viktor,
Thank you for the info. Regarding the information in the ticket, I was looking
at the recommended ticket structure in RFC 5077 section 4
(https://datatracker.ietf.org/doc/html/rfc5077#section-4). There is the
encrypted_state mentioned, which contains the encrypted information stated
I think this is of general interest, so I’m posting here rather than poking
friends I know.
Browsers are phasing out doing OCSP queries themselves. The common
justification, which makes sense to me, is that there are privacy concerns
about leaking where a user is surfing.
My question is, what
* 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
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
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
>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
* - 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.
* - a server having more than one
On Fri, 16 Sep 2022, 21:35 Andrei Popov, 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 upda
