On Sat, Mar 21, 2009 at 2:58 PM, Nelson B Bolyard <nel...@bolyard.me> wrote: > Kyle Hamilton wrote, On 2009-03-21 14:07: >> 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*.
For the sake of advancing the argument before us (and not something personal), I will acquiesce, and simplify: I blame TLS for some of its requirements (such as "it is always a fatal protocol_error alert for an unauthenticated server to request authentication of the client" in the TLS specifications themselves -- not simply the HTTP-over-TLS informational RFC, which is where such a statement should be made *in relation to the browser*). I blame NSS for choosing not to adhere to certain aspects of the SSL 3.0 and TLS 1.0 standards (accepting a ClientCertificateRequest with a zero-length list of identifiers of acceptable CAs), enforcing others (including the 'fatal protocol_error alert' I alluded to above) and not exposing details (such as sessions) to its clients. (My apology if it does this last, and the upper-layer client just refuses to access it.) Since NSS is also responsible for authenticating against the PKIX standards, and it does so, I do not have any issues with it in that manner. I *do*, however, blame NSS for requiring client keys and certificates to be installed in the current user's certificate store in order to use them. I blame the browser UI for not usefully exposing useful details of PKIX, TLS, and what it's doing with the users' keys and when. I still, however, believe that server-auth is -- if not the the worst feature of TLS -- certainly the most overhyped and misused. > 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. Interesting. So my friend in Ann Arbor who has a 6-to-4 IPsec tunnel should be able to use it without problems (and can't, as the tunnel uses IPsec and is blocked), and my friend in San Jose who needed to upgrade to a business account so that he could do work from home (using the Cisco VPN utility) shouldn't have needed to? Did you purchase a business account? (This is an honest question, and I have no political motivation to ask it -- I would simply like to know so that I can help my friend figure out his issues.) >> 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. Alright, fair point. I am (and have been) looking at it from the view of a single webserver providing a single service. I realize that there are other implementations in production -- for example, https://documents.google.com/a/domainnamethatusesit.com, with many different domains that use that same hostname. > 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). This wouldn't particularly work in the Google case above, either. (I use both a private-domain google documents store and my public gmail account for a google documents store.) Particularly if the session has to ask, every time it wants to switch credentials, what certificate to use for it. > 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. Is it? Or is it something that, like the CA/B forum, needs a S/B forum? Rather than making all the assumptions from the RFCs and standards that exist, which have been shown to have failed in the underlying goal of interoperability, perhaps the most important thing would be to settle down, stop blaming the other, sit down, and negotiate on exactly what the various things *mean*. (I swear, this is almost worse than the Hatfields and McCoys...) > 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". Maybe, just maybe, you should get off your high-horse. You are describing this as if it is The Way Things Are And Cannot Be Changed (like the human body). This isn't the human body, it's software. It's insanely configurable. It's insanely re-editable. It may be THE SOLE CAUSE as far as YOUR IMPLEMENTATION goes... but if there's enough people who don't understand the configuration, that means that there's a major disconnect in communication somewhere. Yes, the problem exists on the servers -- but until you sit down and explain *why* certain decisions on the client have been made, to the people working with the servers, so that they can go "oh, but what about *this?*" and explain why certain decisions on the server have been made, and you can come to a real workable compromise that addresses your concerns AND the concerns on the server side... nothing's going to happen. Nothing CAN happen. Everyone is pointing at the other side, and nobody wants to own up to the fact that they could be even possibly even partly able to bend and make things better. >> 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. ...I'd like to see what statistics you have to back that one up, for client certificate usage *within Firefox*. I'd also like to see what statistics you have on non-enterprise usage of client certificates, broken down by product. >> 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? Interesting. So my friends and contacts in the various IT substructures in the Navy, Marines, and Air Force have been misrepresenting that to me all these years. They have stated to me that Firefox doesn't go on computers that connect to the Official Network, but only on the Morale & Recreation machines. -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
