[132266] in cryptography@c2.net mail archive
Re: [OpenID] rfc2817: https vs http
daemon@ATHENA.MIT.EDU (Ben Laurie)
Tue Sep 2 08:35:21 2008
Date: Tue, 2 Sep 2008 03:51:24 +0100
From: "Ben Laurie" <benl@google.com>
To: "Eric Rescorla" <ekr@networkresonance.com>
Cc: "Story Henry" <henry.story@bblfish.net>,
"OpenID General" <general@openid.net>, cryptography@metzdowd.com
In-Reply-To: <20080902003256.D21035FD386@kilo.rtfm.com>
On Tue, Sep 2, 2008 at 1:32 AM, Eric Rescorla <ekr@networkresonance.com> wrote:
> At Mon, 1 Sep 2008 21:56:52 +0100,
> Ben Laurie wrote:
>> > Session caches are often dialed this low, but it's not really necessary
>> > in most applications. First, a session cache entry isn't really that
>> > big. It easily fits into 100 bytes on the server, so you can serve
>> > a million concurrent user for a measly 100M.
>>
>> But if the clients drop them after five minutes, this gets you
>> nowhere.
>
> Agreed. I thought we were contemplating protocol changes in
> any case, so I figured having clients just use a longer session
> cache (5 minutes is silly for a client anyway, since the amount
> of memory consumed on the client is miniscule) wasn't much
> of an obstacle.
Fair point.
>> BTW, sessions are only that small if there are no client
>> certs.
>
> True enough, though that's the common case right now.
>
>
>> > Second, you can use
>> > CSSC/Tickets [RFC5077] to offload all the information onto the client.
>>
>> Likewise.
>
> Except that CSSC actually looks better when client certs are used, since
> you can offload the entire cert storage to the client, so you get
> more memory savings.
I meant "five minutes".
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
