[OpenID] rfc2817: https vs http

[Peter Williams]

Little to do with the non-argument about session handling that is going on, but assuming the google server farm is one giant server block, if we look at the STP BPDU flows (which represent a kind of session) and their 120s timeouts, surely SSL can be using the same kind of distributed, election-leveraging ASIC engineering as does STP/BPDUs - once one is scaling to the kind of load of a Google or live.com?

If protocols like STP and Cisco VTP/DTP accounts for 10% of the bandwidth of a high-end server block, and solves loading, layer-forwarding caching/timeouts, flow load-balancing, and "level 2" session management for such as etherchannels, why cannot SSL be using the same kind of techniques, where the ASICs (vs the server CPUs) are doing the hard part of the work, for another 5% static load?

This whole orientation on servers doing software SSL, or networked HSM's doing SSL ciphersuite offloading in the front end routers of a server block, seems so outdated - once one gets to a google/live-size scale.

We need to start using the same kind of techniques as the phone trunking companies use, when doing ATM-speed encryption; that neustar do when doing key translation and switching, between trunking operators, etc.

If you are capable of running a backbone area for ISPs running OSPF (with all its link state flows, and computation of shortest path etc), surely the same kind of approach can now be used for distributed session management of SSL, and cert chain calculation (where cert issuing now get tied to routes/links, rather than SSLv1-era domain-names from the untrustworthy DNS)?


-----Original Message-----
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of SitG Admin
Sent: Monday, September 01, 2008 11:08 PM
To: Ben Laurie; Eric Rescorla
Cc: Story Henry; general at openid.net
Subject: Re: [OpenID] rfc2817: https vs http

>>  You can use a custom session handler (not too difficult - databases work for
>>  this) to set your own duration.
>
>I repeat: not if the client drops the session after five minutes.

I'm not subscribed to the cryptography list, I think I missed the
first time you said that the *client* would be dropping the session
after five minutes. I'm curious as to why the client would do this
when you explicitly set the expiry date to further than 5 minutes
into the future, too - is that to do with the client certs?

I was thinking of having to work around a server that forgets
sessions more than 5 minutes old, that's why the database. If the
*client* forgets, remembering things server-side any longer *would*
be kinda pointless, then, yeah.

>True, but entirely unrelated to SSL session duration.

True, but since I've wasted several months overall on coming up with
various ways to improve my web security before, just recently,
realizing that it's much more efficient to simply educate users about
using the appropriate passwords to indicate their desired level of
access, I'm a bit strong right now on the "Let's outsource enough
security to the users that we don't have to drive ourselves nuts on
convenience." front.

Though, to be fair, I don't (currently) have to worry about users
that don't know anything and won't learn - all of mine^1 are so
security-conscious already that I'm confident in their willingness to
use one password for "I'm at a public terminal or worried about
interception, give me limited access for a short time so I don't need
to worry about anything." and another password for "I'm at a secure
facility, give me full access and whatever security won't compromise
convenience since I probably won't need it."

It's different for most use-cases, so I'll withhold further
objections along these lines. I'm too used to not having to sacrifice
security for convenience to really be qualified on advising those who
may not enjoy such freedoms.

-Shade, burning tin

^1) In fact, most of them *exceed* my own standards, to such a degree
that some of them won't even try to log in. I haven't bothered
setting up accounts for several, because I expect that they won't try
to deal with me through the site - convincing all these people that
the *internet* is safe is one of the most conflicted, complicated,
*vexing* tasks I face :)
_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general