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

<home_pw@msn.com> writes:

>>> The server doesn't recognize that session and replies with
>>> a Server Hello containing his highest protocol version, plus
>>> plus server certificate message plus client cert request plus
>>> server hello done.  The popular Web Browser closes the network
>>> connection without sending any kind of SSL alert and shows
>>> "Page cannot be displayed" to the user.
>>>
>>>
>>> I firmly believe that this is a conceptual flaw on the client
>>> side, making a flawed assumption about when a cached SSL session
>>> can be expected to be resumable.
>>
>> ISTM that there are two issues here:
>>
>> 1. Whether the client should have offered asession ID.
>> 2. Whether it should have choked when the server refused.
>>
>> Without taking a position on the first, which I think is tricky,
>> the client should definitely not have choked. Servers can always
>> refuse to accept a resumption.
>>
>> -Ekr
>
> I reasoned differently, because this is an https context -
> there is thus a URL resolver involved. The validity of a secure URL is
> not the same as the validity of an SSL-named layer 4 TCP port (or
> SSL-named PPP tunnel connection,....)
>
> At the SSL layer, the client sought a session resumption from a named
> layer 4 port. Session resumption means that the URL resolver at the
> https layer, however, is based on the client's connection state , not
> the host/port parsing. This includes the binding of URLs used in
> session creation, and the URL used in connection establishment (which
> are allowed to differ)
>
> IN the cited case, a server responding from a given layer 4 port of
> the second URL refused to resume a session (for some reason, like it
> didn't share session state records with another implementation). It
> then correctly engaged in a full handshake (with unusual custom
> pipelining of full handshake messages).
>
> The client is entitled to reject the handshake, as in any full/partial
> rehandshake case. The client uses the conforming option to close the
> TLS Transport (TCP) rather than perform a close. This is reasonable,
> given the URL resource showed no knowledge of the sessionid/keying
> material.

Peter, 

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.

-Ekr

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