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

> Which is why session resumption is an explicitly optional 
> construct.

And, its why the protocol has an explicit no_renegotiation 
alert; just because the server ASKS for a renegotiate DOES 
NOT MEAN it gets it. Further, the client can assert 
user_cancelled, mid handshake and post-ServerHello anyways, 
even if the full handshake SHOULD proceed.

---------

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.

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.

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.

user_canceled simply means in this context: give me session 
resumption under the cited ciphersuite, or don’t bother. The 
server can send a hello-request if it invites the client to 
retry the sessionid, given it now has knowledge of the 
"insistence"; otherwise it just closes the TLS connection 
using the conventions of the bearer.

Now, as a principle: Why the SSL application cares to do 
this is up to the designer of the application. In all cases, 
as the standard asserts: its never the business of SSL/TLS 
protocol layer to know or care WHY SSL applications open or 
close connections, or under what conditions. Its just a 
state machine that trundles along, doing its automata thing. 
Whether an SSL application such as https support a usable 
hypermedia or other web usage experience or not... requires 
evaluating https and the web client in question. 

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