I should also add: 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.)
The client was built around the same paradigm as the server. The client paradigm is what keeps the CAs in business, and the client paradigm and its unwillingness to change is part of what's preventing the adoption of client certificates on the global internet. -Kyle H On Sat, Mar 21, 2009 at 2:07 PM, Kyle Hamilton <aerow...@gmail.com> wrote: > 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: >>> This is a stupid comment. >> >> Then why post it? > > Because Anders was referring to the argument as stupid, and I was > referring to his comment as stupid. (Sometimes, just sometimes, it > helps to mirror someone's attitudes and behaviors to get them to > realize just how inappropriate they are. Obviously, it hasn't worked > in this case, and I apologize.) > >>> 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). > >>> 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. > > It's possible for the server to tell the client -- *once the server > has authenticated to the client* -- what CAs are acceptable. It's not > possible for a client to tell a server what CAs it finds acceptable. > This perpetuates the "all or nothing" trust problem which has > historically prevented CAs from being removed from the root store: > there's no way for a business owner to mitigate the risk by having > multiple CA certificates, choosing which one based on what the client > states it is willing to accept. > >>> 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. > > You are also making the assumption that TLS is *only* useful for > browsers, and *only* under the current paradigm of authentication. > IPsec requires that the client authenticate itself before the server > is required to make any reply at all; unfortunately, Comcast (and > other ISPs) filter IPsec. This means that there's no current protocol > means to support the use-case where the client is requesting services > from a server that doesn't want to provide anonymous services, or even > announce its identity. > >>> 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." > > No, the fact that client certificates are used and re-prompted for > whenever the session expires -- interrupting the user's workflow -- is > what makes this completely unsuitable. > > 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? > > (Even ICMP uses the services provided by IP, even though in the OSI > model IP and ICMP are supposed to be at the same layer.) > >>> 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. > > 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. > > Fifteen years. A decade and a half. 1994 saw the release of the > first beta release of Netscape Navigator with SSL support. In all > that time, the client certificate UI has never been fully tested, > never been fully utilized, and almost nobody even knows of its > existence -- because it's too hard to understand, too hard to explain > to Grandma. > > Something is fundamentally broken, and it's not the code. It's not > even the protocol design -- the protocol could be adapted to different > views, and make things better. It's the fundamentalist viewpoints of > those who refuse to see, accept, or acknowledge the existence of > everything that says that the viewpoint -- and its attendant > assumptions/presumptions/correlations -- is wrong. > > -Kyle H > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
