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

[Martin Rex <[e-mail]>]

[e-mail] wrote:
> 
> >> > 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.
> 
> 
> Show me the text in the standard that says MUST (or even 
> half hints MUST from the English wording). Tell me it MUST 
> apply to EAP-TLS, too. More importantly, tell me what 
> "appropriate" and "graceful" then mean, for packets on the 
> wire. Tell me what the server MUST do, if the client does 
> not comply. Your both making this out to be security- or 
> interoperability- critical (it's a MUST, Peter!!)

I think it is acceptable for a client to have a certain level
of expectation about the servers characteristics for the exact
same target endpoint (host:port), but not for a different one
on the same host.  Especially in the real world of NATs.


It is an implied MUST, not one that is spelled out, based on
common sense and established practices.

Where in the spec do you find an indication that a client
may blindy assume that all processes on one host will share even
the most valuable secrets, like credentials and an SSL session cache.

In the (Berkeley) Sockets interface there is a tradition that a
server process opens a listener Socket and keeps accepting connections
on this sockets for the lifetime of the process.  Different server
processes traditionally listen on different TCP and UDP ports,
and it is a longstanding security practice to not have each and
every service running with full system privileges.

SSL is an extension to the (Berkeley) Socket interface and
has basically inherited these traditions.


> 
> Concerning the evidence:-
> 
> "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."
> 
> VERY LIKELY! This is in MY purview - as a implementer - to 
> decide; Martin, you are making my point for me. My 
> implementations don't support ANY of the fallback practices, 
> either, by default!

I think it is clear from the protocol handshake and the state machine
that there is a significant difference between a server not resuming
a cached session and an established session doing a renegotiation.
For the denied resume, there is no agreement on a common previous
session state, while for a renegitiation request, there exists
common agreed-upon session state.


-Martin

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