Kyle Hamilton wrote, On 2009-03-20 02:15: > This is a stupid comment. Then why post it?
> 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. > there's no way to figure out what CAs are available on the client for > multiple-certification strategies, But it is possible to tell the client which CAs are acceptable. The server doesn't need to know more about the client than that it can be authenticated with a cert acceptable to the server. > 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). Even if there was, I believe most browsers would refuse to implement it. Surely I need not explain why. > 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. Right. That's a session at the application layer, not a session at the transport layer. You're trying to bind/couple the two. You're applying design goals and requirements of one to the other. You're trying to make TLS sessions serve double duty as also being application sessions. "Doctor, it hurts when I do this." > 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. Both the client and the server can impose their requirements on transport session duration. Either one is free to terminate the session at any time, at will. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
