-----BEGIN PGP SIGNED MESSAGE----- Here is a posting I made to www-security a few days ago when Netscape announced SSL. It did not get any response. I see though that they at least fixed their spelling... Date: Sun, 27 Nov 1994 12:12:47 -0800 From: Hal <hfinney@shell.portal.com> X-To: www-security@ns1.rutgers.edu Subject: Re: info on proposed SSL protocol and Netscape implementation Sender: owner-www-security@ns1.Rutgers.EDU I have a few comments on the proposed SSL and Netscape's HTTP-SSL that uses it. First, CHALLENGE is consistently mis-spelled CHALLANGE throughout the SSL document. Second, 3 cyphers are specified in this version of the document: RC4, RC2, and DES. I would like to see 3DES and/or IDEA. RC4 and RC2 have not to my knowledge received much public scrutiny, and the 56 bit key size of DES is of questionable security today. Of course these would be for the non-export versions. Third, it is not clear how practical the use of X.509 certificates will be. For example, the "name" field in the certificate must somehow be checked against the information which the client has about the server. Typically this will just be a machine address like home.mcom.com or something similar. Is X.509 a good fit for this purpose? I am not too familiar with X.509 but generally the names that I have seen are not in this form. Fourth, it would be nice if there were some support for non-certificate authentication of the server's public key. For example, the client may have obtained that key previously. I believe SHTTP is more flexible in this area. Fifth, I don't really like the idea that the Netscape client embeds "approved" certificate authority keys. I suspect that the CA situation is going to be in flux for quite a long time and one's client could easily get out of date. Note that the reliance on CA's seems to have slowed the acceptance of PEM as a widely used standard. PGP's anarchic "web of trust" has perhaps been a better fit to net culture. Sixth, the use of "https:" as a URL type for secure links provides for a very strict separation of secure and non-secure connections. Furthermore, this separation is chosen by the server operator. I would like to see a more flexible system, one where the client has more control over what information is transferred securely. The server may want to set a minimum, and refuse to exchange certain information non-securely, but it should not IMO also set the maximum. Some clients may be more privacy conscious than others. Some may not want information about which URL's they use to be available to local snoopers. The Netscape approach seems to put too much control into the hands of the servers and not enough into the hands of the clients. SHTTP also uses a special URL, but it seemed to be more open to the possibility of a negotiation between client and server for secure connections even on "http:" URLs. This would be done by having backwards compatibility with HTTP in which a non-secure-aware client or server would ignore or reject the security enhancements. The transaction could then proceed in non-secure mode with appropriate information displays to the user. SSL does not appear to allow for this kind of compatibility. Despite the negative tone here I think that SSL is potentially a good step towards enhanced privacy on the net. I think though that eventually encryption will be used far more widely than Netscape seems to have in mind. The net is so insecure that I suspect people will want privacy for all but the most casual uses. Hal Finney hfinney@shell.portal.com -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAwUBLujrKhnMLJtOy9MBAQFYdwH/VAObt9l6IKb44Z9mbCiz6DiRPjjA/mQp ZZq0ns/6xKQZvw3L77mTRECRuU8Gf1j3jUXZnqPxo7t8v+IyUuplCQ== =Z+0f -----END PGP SIGNATURE-----