>This is a stupid comment. Pardon me. I just don't agree with the majority of this list since many governments and banks in the EU are working in another direction. This may be due to ignorance but I insists that there is a problem having *two* competing session mechanisms in web-apps; one [IMO] may have to go.
The other problem is that the signature stuff that the Mozilla community continuously downplays actually lives and this thingy also works contra TLS-c-c-a as since you obviously shouldn't have different PKI UIs for signatures and authentication. We are talking about investments in the range of $100M/Y. happy weekend Anders There are many people who think differently; I, for one, think that server-auth is the *worse* part of TLS (because there's no branding of what CA is responsible for the certification, there's no way to identify when a session is re-used versus renegotiated, there's no way to figure out what CAs are available on the client for multiple-certification strategies, and there's no way -- unlike IPSEC -- to require that a connecting client authenticate itself before the server decides to let its identity be known, among others). It seems pretty clear that the "common case" for authentication, as implemented by banks, utility companies, phone companies, PayPal, etc is to authenticate once and then let that authentication continue for as long as the session holds -- and by 'session' I mean a cookie either as a separate header or as a part of the URL -- and expire those sessions after 10 or 15 minutes of inactivity. The most important part to remember is that *ALL OF THIS CAN BE CONFIGURED ON THE SERVER AT THE TLS LAYER WITHOUT THE CLIENT KNOWING OR SUGGESTING ANYTHING ABOUT IT*. Sessions can be reset to 0-seconds idle when they're used, or not, at the server security configurator's whim. We've been living with the same set of assumptions for over ten years, and the client side of the authentication equation hasn't taken off. (The server side of the equation hasn't, either, really -- we're stuck with the same type of user interface that we had 10 years ago, with the most important [and only] advance being The Green Bar Of EV.) This means that there's a problem with these assumptions -- being made and implemented as they are without any real documented input from the most important people of all: the users. -Kyle H On Fri, Mar 20, 2009 at 12:32 AM, Anders Rundgren <anders.rundg...@telia.com> wrote: > This is a stupid discussion. > > Authentication schemes in general begin with authenticating the user. > How long the authentication should be considered as valid is > not something the client-end has anything to do with unless it > has gotten some kind of expiration data from the server. > > It seems pretty clear that the real culprit is the TLS protocol itself. > > Fortunately a lot of people are working hard to establish schemes > that use the good part of TLS (server-auth) and leave the unwieldy > part to a community that won't be able fix it. > > Anders > > > ----- Original Message ----- > From: "Nelson B Bolyard" <nel...@bolyard.me> > To: "mozilla's crypto code discussion list" > <dev-tech-crypto@lists.mozilla.org> > Sent: Friday, March 20, 2009 07:57 > Subject: Re: client certificates unusable? > > > Kyle Hamilton wrote, On 2009-03-19 23:07: > >> My reason for the conservative time suggestions is because that's what >> banks tend to use (my bank times me out after 15 minutes of >> inactivity, as does my phone company, and my electric company, and >> PayPal, and...). > > But those are *minutes of inactivity*. SSL session lifetimes typically > do not take activity (or inactivity) into account. If you set a 10 > minute lifetime, then 10 minutes later, that session will end, and you > must reauthenticate again. So, 10 minutes means reauthenticating 6 > times each hour, 48 times per work day. :( > >> IE7 does have a "forget sessions" button. I'd like to see a >> reasonable thing implemented as well in Firefox. > > FF has had this feature for years. > > -- > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > -- > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
