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

Eric Rescorla wrote:
> 
> <home_pw@msn.com> writes:
> >
> > Eric Rescorla wrote:
> >> TLS session IDs do not come with any guarantee that the server will
> >> actually honor a resumption request. The server may implement any
> >> session cache policy it chooses. Therefore the client *must* be
> >> prepared for the server to refuse resumption.
> >>
> >
> > So the only thing we are disagreeing on is the definition of "must be
> > prepared".
> >
> > You say choked, I say graceful fail.
> 
> No, I don't agree with this analysis. The server being unwilling
> to resume a session is normal behavior. The TLS state machine
> explicitly handles such cases. Implementations which choke
> rather than doing a full handshake are broken.

I fully agree with Eric that a client MUST deal gracefully with
a server that does not resume a proposes SSL session (ID) for
whatever reason.

The particular problem in the scenario that I listed might be
that the client, by retrieving a cached session from its cache
thought he had several parameter (including the protocol version)
already established and treated the response from the server
(who didn't resume as proposed) probably more like a renegotiation
rather than a new handshake, and therefore might have considered
the unavailablility of the previous higher protocol version
a rollback attack.

The client-side SSL session cache can not be implemented "transparently"
in the TLS implementation, it needs significant extra information
from the application in order to know whether and which cached
SSL session might be resumed.

Think about a client-side proxy (CONNECT), where the layer above
TLS must perform the CONNECT handshake with the proxy, and where
the network target IP and TCP-Port will be the same for all non-local
addresses.  There, the decision whether and which SSL session cache
entry might be tried for resumption will have to be derived from
the hostname:port from the URL (which is also used for
server endpoint identification).  In our customer's scenario,
no proxy is involved, so the different endpoint is visible on
both, the socket and the URL.

-Martin

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls