Re: [TLS] Please discuss: draft-housley-evidence-extns-00<

Omirjan Batyrbaev wrote:
> 
> > Come on David; we can do better than this, as (secure) 
> > networking engineers.
> > 
> > Cookies are not used for session stickyness/persistence in 
> > https, or for failover prep, in HA internet data centers 
> > doing 1000-2000 simultaneous handshakes for https sessions. 
> > In layer 2 switched and layer 3 routed data centers (of 
> > which I've built 2, with teamed nics, redundant gateway 
> > convergence, deterministic convergence, etc ), it's the 
> > SSLv3 session id that is the "cookie" for controlling that 
> > path of the fragment through the switches. 
> 
> But what happens when the application session spans multiple session ids?

You loose (or the application looses).

The secretive security guys are as narrow-minded about
complex application design as some of us are narrow-minded
about the need for multi-level security.

Someone who thinks at EAL6+ security levels is not used
to multi-millions LinesOfCode applications with annual
code growth rates around 10% that have a requirement
to perform a single "transaction" accross several entirely
independent communication channels using independent protocol
abstractions crossing different middleware application components,
and being protected and (re-)authenticated by different
authentication technologies.

People like me try to provide some assurance that
all those seperate communication streams ending
up in the the same Application backend server are
protected and securely authenticated and in fact
belong to the same application session on the frontend
so that they can all have access to the same shared
session state in the backend.

Personally, I don't like such complex application design,
but it's not that anyone in the apps area would listen to me
and cut back on their ambitions.

But looking at the other TLS extension in TLS v1.2, it
seems the amount of different authentication technologies
is going straight up rather than settling down on a single
common scheme.

-Martin

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