TLS session resumption (identifier)

[B.R.]

Hello,

Based on the default value of ssl_session_cache
<http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_cache>,
nginx does not store any session parameter, but allows client with the
right Master Key to reuse their ID (and the parameters they got).

Since nginx, does not cache anything and is thus unable to revalidate
anything but the Master Key, isn't it a violation of the RFC not to
validate all the parameters?

What happens in the following scenario?
1°) Client negociates a new TLS session and stores the session ID locally
2°) Server admin changes the configuration of his/her server to completely
alter cipher suites, etc. and reloads the configuration (without restarting
the server, so the Master Key is left untouched)
3°) Client tries to reuse its previously saved session ID with the right
Master Key

I guess the server will most probably reject the session bacu and initiate
a new one with the same Master Key (please confirm)? Is it 'legal'?
I admit that, in a way, the same happens when say, on a high-traffic
server, the cache rotation eliminates old entries which a client then tries
to resume a session with...

Is it allowed to reduce the session ID mechanism to the check of the Master
Key per RFC? Shouldn't you either fully support the mechanism (with a cache
of parameters server-side) or not at all?
---
*B. R.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160303/e3d22c1c/attachment.html>