[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] Please discuss: draft-housley-evidence-extns-00<
see inserted:
----- Original Message -----
From: <home_pw@xxxxxxx>
To: "Kemp, David P." <DPKemp@xxxxxxxxxxxxxx>; <tls@xxxxxxxx>
Sent: Wednesday, January 10, 2007 6:47 PM
Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00<
> 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?
-Omirjan
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
>
_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls