Closed Bug 1555207 Opened 2 years ago Closed 2 years ago

HelloRetryRequestCallback return code for rejecting 0-RTT


(NSS :: Libraries, enhancement, P1)



(Not tracked)



(Reporter: mt, Assigned: mt)


(Whiteboard: [tls13])


(1 file)

The application token that we put into session tickets (see SSL_SendSessionTicket and SSL_HelloRetryRequestCallback) can be used to pack application state that is carried over to resumed connections. For instance, this might be used to carry QUIC transport parameters and HTTP/3 settings. This is useful for carrying configuration over and determining what the client might have received in that previous session, especially if the server might allow the use of early data.

When validating a token, it might happen that a token is valid, but the server is unable to respect the remembered configuration for early data. For instance, a QUIC server might have previously allowed clients to create 100 streams at the outset, but changes in configuration (or load) might have reduced that. If the server accepts early data, it would be forced to accept more streams than it currently wishes to allow.

So it makes sense to have a way to reject early data based on the value of the application-provided token. Calling SSL_OptionSet() to disable 0-RTT completely has the effect of disabling 0-RTT for future sessions unless the value is restored before sending session tickets. However, NSS might send session tickets right at the end of the handshake and there might not be an easy place in application code to tweak the setting back before that happens.

This change will add a new return code to SSLHelloRetryRequestCallback. That code will signal to NSS to proceed normally, but to reject 0-RTT.

Adds an option to reject 0-RTT, but nothing else. See bug for more

Priority: -- → P1
Whiteboard: [tls13]
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.45
You need to log in before you can comment on or make changes to this bug.