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

["Kyle Hamilton" <[e-mail]>]

An IP/port pair is sacred.  This has two consequences:

1) session IDs should never be leaked beyond the sacred space into
another sacred space, and
2) Even when resumption is requested, the server must be prepared for
the client not to resume, and the client must be prepared for the
server not to resume.

When you 'exploit' the wording of any given publication, you end up
with a situation such as what you describe: whether it's "choking" or
"gracefully failing", the behavior is not what the end-user expects --
and since it's the end-user who must be built to, it's the end-user
who determines what to describe it as, and the developers tasked with
building to that end-user.

"Be conservative in what you send."  This has much more specific
meaning in security-related protocols, because "...and liberal in what
you accept" tends to reduce the security thereof.

If a browser gets a "bad request" response from the server, does it
instantly abort the connection and say "cannot connect"?  No, it goes
through its list of alternate protocols that it can possibly use.

(more comments interspersed)

On 1/15/07, [e-mail] <[e-mail]> wrote:
>
> So the only thing we are disagreeing on is the definition of
> "must be prepared".

The session-resumption mechanism is explicitly optional negotiation
acceleration in all of the drafts I've seen.  This means that at all
times a new connection is made and security parameters negotiated, it
MUST be possible for either side to say "I want a full negotiation"
and, regardless of the preference of the other side, get it.

>From a user interface standpoint, throwing a fit when you don't get
your way is a surefire way to get users not to use your software.

> You say choked, I say graceful fail.

tomato, tomahto.  To the user of the software, it's the same damned thing.

> I fail to see why the UI behavior of a multi-URL-protocol
> browser should be different for https vs other URL
> protocols. Furthermore, a non-Navigator-style web client is
> even less constrained, because it may a moniker resolver
> aswell as a URL resolver built into the application. We all
> know wininet has different https behavior to IE, which is
> yet different to the MSN Explorer. We all know Navigator in
> turn has "unique" security semantics concerning its SSL
> session duplication , and a "unique" trust access model to
> cookies by child windows etc... I have no expectation that
> navigator's client-side sessionid caching policy (for https
> resolution) is the same of the other 3 examples, I gave!

Which is why session resumption is an explicitly optional construct.

> If the particular browser experience design has established
> (via a combined security vs usability tradeoff analysis) a
> certain practice concerning how it visualizes and handles
> (connection) failure cases (cannot "connect" to a resource,
> ultimately) when using all the NON-https URL protocols why
> should it vary this view ...for the session resumption
> exception on the https URL?

How is "unable to connect" to a protocol-conforming server a usability
decision?  That's a usability failure.  But, this is layers 6 and 7,
not layer 4.  Layers 6 and 7 build off of the capabilities of layer 4,
and layer 4 provides its capabilities without reliance on information
only available at higher layers.  This is the only way protocol
designers can keep themselves sane.

TLS is "as transparent as possible".  That doesn't mean that it can be
wholly transparent.

-Kyle H

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