11 Jun 2007 18:11
Re: Three short fixes
Thomas Pornin <pornin <at> bolet.org>
2007-06-11 16:11:39 GMT
2007-06-11 16:11:39 GMT
On Mon, Jun 11, 2007 at 07:23:56AM -0700, Hallam-Baker, Phillip wrote: > I don't see why I should appologize for a fix for being 'centered' on > the only X.509 prototocol that can be regarded as a real success. This is a technical debate on a technical mailing-list. This is not a trial and there is nothing to apologize about yet. > The reason for using a certificate is to allow for backwards > compatibility with a billion installed browsers. The dilution of trust > is inevitable, all it takes to get a WebTrust audit is to do what you > say. Eventually someone is going to get a WebTrust audit on the null > CPS. For backward compatibility, SSL/TLS already has a beautiful scheme which is called "cipher suite selection" and it works. Basically, the client sends a message ("ClientHello") where it states which cipher suites it supports, and then the server selects one which it also supports. The cipher suite defines how the session will be protected. For DH_anon cipher suites, both client and server know that there is no X.509 certificate involved, only a public key. Let's assume that we have a server which wishes to use encryption but needs not any kind of authentication(*). This server will be fine with a DH_anon suite. A client comes along: -- Either this is a client which supports the concept of an unauthenticated but encrypted session. That client then implements DH_anon cipher suites, because that is exactly what these suites are about, and they have been standard for quite a long time. The client states that it supports DH_anon suites, the server selects one, and the session is encrypted but not authenticated. No X.509 certificate is involved here, and, in particular, no X.509-related warning message is displayed to the user. -- Or the client does not support the concept of an unauthenticated but encrypted session. This means that the client does not support DH_anon cipher suites (because DH_anon suites are meant for one thing and one thing only: unauthenticated but encrypted session). The client will send a ClientHello message which will not contain a DH_anon suite, but other cipher suites which expect a X.509 certificate from the server. The server sends a certificate which cannot be authenticated by the client. The client displays a warning to the user, but we cannot do better than that since the client does not support unauthenticated sessions: this is the "backward compatibility" situation. What could be done here to makes things even better would be the following: -- Make DH_anon suites more "supported" (newer TLS specifications tell that DH_anon suites are obsolescent due to the involved security issues(**)). -- Define RSA_anon suites which should provide better performance for computationaly challenged clients (RSA encryption is cheap). Both of these are issues for the IETF TLS mailing-list, not the IETF PKIX mailing-list. To sum up, what you ask for _already exists_ in a better way (less network traffic and less X.509 processing for the same functionality). Unless what you want is something entirely different. You write: > I want to be able to issue device SSL certs. People want to buy them. Of course, if you sell certificates, you will not like a scheme where nobody uses certificates and, as such, nobody buys certificates. --Thomas Pornin (*) Basically, unauthenticated but encrypted session are useful only if the security model allows only passive attacks. This is rarely a valid assumptions, but this is not the issue in this discussion. We assume here that there are plausible situations where unauthenticated but encrypted sessions are what is needed. (**) People involved in the definition of TLS do not believe in the existence of plausible situations where unauthenticated but encrypted sessions are what is needed. This is why DH_anon suites are currently deprecated. But the same people, and, more importantly from your point of view, the TLS implementors will think just the same about any way to get unauthenticated but encryted sessions, whether by using the TLS features which have been designed for exactly that usage (DH_anon), or by any X.509-related trickery such as your fake certificates. So this is not an issue in this debate.