RFR: 8328608: Multiple NewSessionTicket support for TLS

[Anthony Scarpino]

On Fri, 21 Jun 2024 17:17:57 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

> > > Just for knowledge: If the client has multiple PSK Identity previously shared by server and client initiate a PSK resumption of type(psk_dhe_ke) and it receive a HelloRetryRequest from Server, then should client send the same PSK Identity in current ClientHello same as in previous ClientHello(after changing ticket_age and binder value) or it has option to choose any one of remaining unused PSK Identity or let send all unused PSK identities available in 'pre_shared_key' extension?
> > 
> > 
> > Looking at the code, it should be the same PSK. I did not change anything in this area, so I would expect the same behavior as before. In the existing code, given the first CH would take the PSK out of the cache, there would be no new PSK for the second CH to change to.
> 
> May be i am not clear fully. You mean after HRR, the next CH will go for a Full Handshake as the existing PSK identity removed from cache before next CH and after HRR reply? As per RFC. the CH after HRR can use the previous PSK Identity presented in initial resumption CH but after changing ticket_age and binder value. Also would not it nice to send all applicable PSK identity available in client side in initial resumption CH and take real advantage of having multiple PSK identity and let server choose one out of it. Sorry the question may not be practical as i am asking something theoretical point of view and i am not friendly with TLS code yet.

The second CH will still contain the first CH's PSK and do the modifications according to the spec.  I was just pointing out that the PSK was removed from the cache, so using another PSK isn't an option today.

Theoretically it seems possible.  The spec does allow multiple identities be sent.  I hadn't considered sending multiple PSKs.  The spec implies this maybe more for situations with 0-RTT and Early Data.  I could see where a client with many identities it can resume and wants the server to pick one.  Without a public API managing ticket/identities handling, I don't see this as an option for us. Any PSK's used in the CH would need to be removed from the cache, running the risk of causing the problem with an empty cache.  I would guess this maybe used in multi-server situations rather than the simple situation where all the NSTs come from the same server.  Interesting thought.  Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19465#issuecomment-2183374993