Secure Socket Layer BOF (SSL) Reported by Antonio Fernandez/Bellcore The SSL BOF was chaired by Taher Elgamal. The first six sections of these minutes reflect information that was presented in a set of viewgraphs. The last section details group discussion. Agenda o Agenda and charter discussion o Comments o Implementations and experiences o The current draft ``01'' and how it works (i.e., changes from the previous draft) o More changes proposed o Proposed future plan Proposed SSL Working Group Charter A very specialized working group to be setup to define the standard for using SSL as a socket layer security mechanism for Internet applications. The working group will not deal with other network layer security, such as efforts in the IPSEC Working Group, other security APIs being discussed in the CAT Working Group or other WWW security specific discussion in the HTTPSEC Working Group. Open to discussion: should the working group discuss other ``socket layer'' mechanisms or proposals? There is a need to use common structures to be able to interact with the work of other working groups like IPSP and IKMP. Also to have handy roots. SSL Working Group Proposal Chair: Taher Elgamal Area: Security Area Director: Jeff Schiller Mailing list: session_layer_security@netscape.com To subscribe: session_layer_security-request@netscape.com Implementations and Presentations o SSLREF o Australian implementation o MarketNet o OpenMarket The Current Draft The current version is draft-hickman-netscape-ssl-01.txt. Changes from the previous draft: o Backward compatibility with previous system. o Key exchange modifications: - Added DH key exchange in different flavors. - Maintain requirement for server authentication; client authentication happens on-line. o Changed the secret in the MAC computations to work with hardware tokens. o Changed the finish messages to hash all negotiation exchanges and prevent cipher-specs attacks. o Added certification chain support. o Security escape for key re-negotiation for long sessions. o Detecting ``last record'' using a security escape. Future Plan for SSL Working Group July 95 Charter agreement October 95 Next draft November 95 Final notice for the working group December 95 Final notice for the IESG Discussion The charter that Taher Elgamal is trying to write says specifically that the group is not going to write what the relationship is; SSL was implemented originally at Netscape, but SSL should be at the application layer. Someone mentioned that the SSL application is built into the top of the stack so it is transparent to the application. Taher confirmed that it is, but all you have to do is provide another port number and then you have built the secure applications. It is easier to deploy a socket layer solution that actually changes IP stack, that is, which SSL works and will continue to exist for a while until the world agrees on the IP security method. An attendee asked for confirmation of the understanding that IPSP will obsolete SSL. Taher responded that it absolutely will. From the beginning it was developed with that in mind. However, until then, we have to have the current system going, which is, people do SSL whatever, we still regulate how it is done. It was pointed out that, at the same time, SSL is not an standard. Taher asked what ``standard'' means? There are a million copies of SSL deployed. He is concerned (because he works for Netscape) since it uses the Internet and he would like to reach a consensus. An inaudible question(s) was asked by the audience. Taher asked what the differences is? The completely independent SSLREF is a Netscape implementation that corresponds to what Netscape feels, and the Australian implementation is completely independent. They are inter-operable and they use the same socket. It was asked if there are other applications written on top of SSL besides the Netscape product? Taher confirmed that there is another application written in England, but that he does not know if it is deployed yet. There is also SSL licensing by other companies; there are a couple of licenses for SSL. An attendee was wondering if SSL can be used for multicast. Taher said that it cannot and that there are not really any plans to do it because they would like to first finish the current plan. Taher said that the goal is to take the SSL work and kind of regulate in the way that we all agree on it. He is not trying to solve all the world problems, but would like people in the audience to share their experiences and discuss the draft that was put out, and in some months, to come out with some document that all can agree on. Try to be generic, using SSL as the base for it, and maybe there is a point in doing security at the socket layer. There will not be future licensing needs, there is no licensing for a specification. The intention is really to get an agreement. It could have some communality with work done in the IPSEC Working Group. The latest draft has some inputs of what is being done in IPSEC. Netscape has to make the router configurable, or the work has to be marked clearly saying that this is something you can do but implementing this does not mean you will be able to talk to SSL routers. Within this year, a router that does precisely that will be implemented by Netscape. The router will have different functions, and e-mail, etc., will have different flavors. There is the question of trust (e.g., for e-mail) and it is a difficult task. OK, but PEM failed, and the reason is that lawyers were invited in and they drafted a contract that has very wide implications and risk of liabilities for the companies trying to get into the framework of the work being done at PEM. It was pointed out that the group is not here to discuss exports issues, otherwise, the topic would never end. There was a floor discussion in the aspects of licensing, CAs and roots for certification. These roots should be easy to get in order for the standard to fly. There is the effort to be common in the root hierarchy such that SSL and SHHTP will be able to use the common hierarchy. Why not have a SSL Internet standard? There was comments from the floor in favor and against. Will the engineering coming from the working group be accepted from the vendor (Netscape) or just ignored? Is security a good thing just by itself? Yes, but that depends on if Netscape will accept the outputs from the working group. If there are different groups coming here with different ideas, it is not a sign for success. Also, we cannot define something that Netscape will follow. It is important to set up clear goals for the working group to be successful. One of the problems with IPSP work is that it needs to be able to access the kernel, but SSL uses the session layer which gives the solution for the user with no kernel access. The implementation from Netscape replaces the Unix Socket and that is the reason for the name SSL. There is also a need for being used in UDP not just TCP. The actual specifications of SSL ties with X.509, but the majority feel the need to be expanded to others like the PGP structure. The group cannot be so general that it will lead to a situation where at the end, even at the application layer, the kernel will need to be modified. Since the X.509 is not in existence now, it could be a problem. To which Taher answered that Netscape does not need X.509 to operate. Netscape is offering a proposal as a starting point and the working group will be able to elaborate above it. This is a possibility to avoid the problem of the migration that IPSP has because IPSP operates in a modified kernel. The only way to operate with Netscape today is by being part of their customer base. It is more difficult to have a hierarchy that will use more than the Netscape customer base. At this stage, SSL and S-HHTP will be distinct protocols indefinitely, whatever implication and key manager is something that will come from the work of each group. So the transactions with S-HHTP and SSL will be able to inter-communicate. One concern is that the more things that are bundled together, the more vulnerable we are to interruptions and breakings. One characteristic of SSL is that it bundled the protocol integration of how to protect the socket protocol along with the mechanism that implements that. But it may be preferable for something that works at the socket and does not need to go to the kernel. There was a discussion of the need for a working group. It was felt that if a working group is not formed, Netscape can go ahead with whatever plans it has and there will not be any chance to interact and somehow influence something that could dominate the market. There are people today looking into using SSL for more than just for browsers. There was agreement to form a working group and discussion will be moved to the mailing list.