Re: [TLS] Re: when is it ok to resume a cached SSL/TLS session

[Martin Rex <[e-mail]>]

[e-mail] wrote:
> 
> So, lets get down to text:-
> 
> So, who is for the proposed wording change? If its what 
> EVERYONE understands anyways, adding one clarification term 
> (MUST) to the text quoted by Eric that governs this case 
> ..is evidently going to have zero nay votes (I'll be 
> abstaining). However, two class C students (me and the 
> browser maker cited by Martin) will have been quite properly 
> instructed.

You have to include me in the count of the class C students
that appreciate somewhat clearer guidelines in the spec.

I think that the TLS spec could elaborate a little more on
non-obvious session caching issues. 

There is, for example the not very obvious session "duplication"
that you mentioned, i.e. several servers and several browsers
put an established SSL session (right after the SSL handshake
has successfully completed) into their session cache and will
duplicate the session for parallel connections to the same server
(per default many browsers open up to 4 parallel connections
to the same target).  The SSL sessions on those parallel network
connection will normally use the exact same SSL session ID.

> 
> Right now, TLS WG is apparently asserting, in effect, that: 
> When attempting to resume a session, a client SHOULD NOT 
> send a no_renegotiate alert if a server proceeds to a full 
> handshake (I.e. populates ServerHello with a non-zero value 
> that is different to that in the ClientHello). Furthermore, 
> the client SHOULD NOT send a user_canceled alert during such 
> a full handshake should the endpoints proceed.

I'm a little confused.  A rejected session-resumption differs from a
renegotiation.  A no_renegotiate alert is not applicable to this situation.
Further protected communication is still possible after a denied
renegotiation, but it is a fatal error if the server can not or
does not want to resume a previous session proposed by the client
on a new connection.

> 
> Arguably, the WG is asserting the stronger form for both 
> these conditions: MUST.
> 
> I’ll offer a compromise here, note. IESG could say: if the 
> client seeking session resumption receives a request to 
> proceed with a full handshake , it MUST proceed with the 
> handshake or it MUST immediately send either a 
> no_renegotiation or a user_canceled alert.

Requiring a server to be able to resume a session is a bad idea.
The reasons why a server has deleted a previous SSL session from
his cache are manyfold.  I recently added a maintenance API to
our SSL abstraction layer to flush the SSL session cache
mid-flight, e.g. when the server certificate is updated/replaced
or the list of trusted CAs is changed.  Active sessions remain
as they are, but resumption from cache is no longer possible
and all new connections will have to go through a full SSL
handshake and operate with the new parameters (server cert,
trusted CA list).



There are various issues that determine how long an SSL session
will be considered valid by either side (client and server) and
at what point it will be flushed from the cache.  The spec says
that a session should be valid at most two hours.
The SSL session cache management on the server side may flush
them much earlier, in particular when the server is under
heavy load.

HTTP(S)/1.1 keep-alive session also do not live forever.
It is to be expected that the server closes them after some
idle time, 30 to 60 seconds is not unusual.  Clients also
commonly close keep-alive sessions after some idle time.


Client-side SSL session caching has not been universally implemented.
While probably all Web-Browsers have&use it, Apache's mod_proxy
seems to entirely lack it.  Slicing of Mime-headers so that
every line is written as a seperate SSL record is another performance
problem created by mod_proxy.



-Martin

_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls