Kyle Hamilton wrote, On 2009-03-21 14:07: > On Sat, Mar 21, 2009 at 1:11 PM, Nelson B Bolyard <nel...@bolyard.me> wrote: >> Kyle Hamilton wrote, On 2009-03-20 02:15:
>>> 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, >> Once again, you are complaining about browser UI, but you blame the TLS >> protocol for your issues with browser UI. > > No, I blame the browser UI for not exposing useful details of the TLS > protocol. The TLS protocol explicitly does not call out the handling > of server certificates: this is the realm of PKIX. The TLS protocol > allows for re-use of a session, but there's no UI for identifying when > a session is re-used (as opposed to renegotiated). OK, so you've confirmed that your complaint is really about browser UI. But above, you did not write "server-auth is the worst part of the browser UI" nor "browser UI for server auth is the worst part of the browser experience with https". You wrote that it was the worst part of *TLS*. You're blaming TLS for browser UI. Please try hard to write what you mean. > [...] unfortunately, Comcast (and other ISPs) filter IPsec. I use IPSec through Comcast daily. > SSL transport sessions *are a service which is provided to the upper > clients of the protocol*. TLS session authentication was designed to > make it possible to have a secure authentication mechanism that the > upper layer could then use without having to rely on its own > username/password application authentication. ALL services of the > lower layers are supposed to be presented as capabilities which upper > layers can exploit, otherwise what's the reason for having them? Yes, I agree. But you seem to wish that TLS implement ONE application's idea of good session management as its sole means. What TLS does is define a scheme that has a configurable upper limit for session lifetime, regardless of (in)activity, and the ability for the application at either end to terminate any session at will, according to its own criteria. So, the obvious way to use it is to leave the TLS session lifetime limit set up to some high value, and have the application code terminate it earlier, if it so desires (e.g. at the end of an application session). The problem here is that people so desperately (or ignorantly) want the TLS sessions to be application sessions, that they configure the TLS sessions as if they WERE application sessions. They configure TLS sessions with an upper bound of a few minutes (or seconds), thinking (or wishing) that TLS sessions are based on inactivity times. The solution is not to change TLS to work the way that some single application wants its sessions to work, and it is not to misconfigure TLS sessions with absurdly short maximum lifetimes. That is a server problem, perhaps a server admin problem. It is not a browser problem. Configuring TLS session lifetimes in the server with absurdly short maximum lifetimes (including zero lifetimes) is THE SOLE CAUSE of all that re-prompting for TLS client auth. It's stupid. To all the admins who do that, and then whine that the browser prompts often, I repeat: "Doctor, it hurts when I do this". > Yes. It's just the fact that die-hard "This Is The Way The Standard Is > And This Is The Way The Standard Shall Always Be" viewpoint-holders, like > you, insist on relying on a paradigm which has been shown to be > fundamentally useless in the every-day usage of the protocol. Except for all those users, servers and enterprises that use it all day every day without complaint. > The problem is not simply on the server's end, Nelson. You've been > pointing at them for years. (The DoD also doesn't use Firefox, so > they don't end up filing bugs against it anyway.) Actually, they do. That's a big reason why NSS gets the funding it does. Why do you think Suite B support went into NSS for FF2? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
