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

[<home_pw@xxxxxxx>]

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. This is why it 
the handshake design changed, between SSLv2 and SSLv3 - to 
allow for early loadbalancers to control the path take by 
the fragment once it gets out of the layer 3 space into the 
forwarding path set by the layer 2 STP(s).

In military varieties of this, the sessionid sticky state 
controls which 803.11q vlan paths trunks that fragment can 
go over, so the convergence characteristics are known during 
protocol or device failure condition. This allows fixed 
timing -  enforced by the topology of the data center, not 
by certain hacks like someone stuffed naively put into TLS 
1.2.

----- Original Message -----
From: "Kemp, David P." <DPKemp@xxxxxxxxxxxxxx>
To: <tls@xxxxxxxx>
Sent: Wednesday, January 10, 2007 7:21 AM
Subject: RE: [TLS] Please discuss: 
draft-housley-evidence-extns-00<

Like cookies destroyed grandma's trust in the SSL brand?
Yet how many web sites still use cookies, and how many
browsers allow users an easy way to both disable cookies
entirely or selectively, and delete stored cookies
entirely or selectively?   If cookies are such
a trust buster, why are they still used?
A: Because they provide a useful capability.

Browser support for TLS extensions would be just as much
under the user's control as cookies and ciphersuites.
This extension doesn't even exist for grandma unless
she goes to the trouble of obtaining a client cert -
is your grandma that tech-savvy?  And even if she can
request and install a client cert, there is no stealth
involved in that process :-).

The purpose of the proposal is to explore options to
allow certificate-enabled clients to provide broadcast
(1-to-many) persistent authentication without having to
install SOA (WS-*) or other signing-capable plugins on
the client.  It may or may not be architecturally a better
choice to do signing through Web Services vs. TLS.  But
while you're crying crocodile tears over TLS's
"reputation" should it ever gain the ability to do
digital signatures, save a few for Vista and digital IDs.

Consumer-to-provider authentication (as opposed to
consumer-to-provider's-TLS-accelerator) is needed,
has both benefits and the abuse potential you are
worried about, and is happening regardless of whether
TLS is extended.

Dave



-----Original Message-----
From: home_pw@xxxxxxx [mailto:home_pw@xxxxxxx]
Sent: Tuesday, January 09, 2007 6:42 PM
To: Stefan Santesson; martin.rex@xxxxxxx
Cc: tls@xxxxxxxx
Subject: Re: [TLS] Please discuss: 
draft-housley-evidence-extns-00<

I'm convinced the term "corporate wiretapping" is proper,
and that is one that grandma will inevitably associate with
the scheme. And, for that reason, we must recognize that we
have in our hands the power to destroy consumer trust in the
"SSL brandname".  Even this debate could be picked up by
journalists, today, to SSL's disadvantage. It doesn't take
much to destroy trust.



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


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