Minutes from TLS Working Group Meeting 40th IETF, Washington, DC 10 December 1997 Reported by Win Treese (WG Chair), based in part on notes by Chris Allen . Mailing list: ietf-tls@consensus.com Web site: http://www.consensus.com/ietf-tls Win Treese called the meeting to order, with the following agenda: - Status - Old business: ports, patents, IANA registration - Other drafts before the WG: Kerberos, SSL Tunneling Proxy - Applications using TLS - Description of server-gated crypto (Dierks) - Implementation notes - Next Steps - Summary of Actions Status ------- The TLS draft has been moved by the IESG to Proposed Standard, and it will be issued as an RFC shortly. Congratulations to everyone on the working group for contributing to this milestone. Old Business ------------ Ports. Over time, there has been much discussion about whether or not TLS applications should use different ports from their non-TLS relatives. This decision must be made for each application individually, so the issue is out of scope for the working group. As it turns out, many applications are negotiating TLS within their own protocols. Patents. There has been some concern about a patent for SSL recently issued to Netscape. Netscape has provided a statement that is appended to the TLS specification. In general terms, Netscape is granting a royalty-free patent license to anyone who implements TLS, as long as they do not assert that Netscape's implementation infringes on any patents they hold. See the forthcoming RFC for the precise statement. IANA registration of ciphersuites and other numbers. Based on advice from several sources, new TLS ciphersuites and similar identifiers will not be registered through the IANA. Rather, they will be the subject of new documents, which may be put on the standards track as appropriate. Other Drafts ------------ Two other drafts are before the working group: Kerberos ciphersuites for TLS. This document has been on hold until the main draft moved to Proposed Standard. Now that it has, the Kerberos document will be sent out for last call in the working group as soon as an updated revision is available. SSL Tunneling for HTTP. This document is not formally before the working group, but it might make sense for the WG to adopt it. Win Treese will discuss this with the author. Applications ------------ Quite a few application protocols are specifying TLS. These include SOCKS, LDAP, FTP, SMTP, IMAP4+POP3, and PPP EAP. WebDAV and IPP are in progress and planning to use TLS. At this point, there is no draft specifying the use of TLS with HTTP (for any version of HTTP). Eric Rescorla volunteered to write a draft describing the current usage of HTTP 1.0 over TLS, and we will try to find one for HTTP 1.1 as well. Paul Hoffman noted that LDAP with TLS is currently before IESG, with SMTP over TLS and IMAP4+POP3 likely to follow. Bob Morgan, author of LDAP over TLS, is interested in hearing from WG members about the way LDAP uses TLS. Carl-Uno Manros, co-chair of the IPP working group, said that IPP has all printing related issues done, but still are wobbly on exact use of TLS. Issues are using insecure way. They wanted to use null_null_null, but this is not allowed. They are packaging IPP it over http. Micheal Bowe said the TN3270 working group has a problem: if a suitable ciphersuite can't be negotiated, the TCP connection must be dropped. A response from the floor was that this was changed in the latest TLS draft. Only TLS has to be dropped, not the TCP connection. Discussions of TLS applications take place on the mailing list ietf-apps-tls@imc.org. Server-Gated Crypto ------------------- Tim Dierks described a mechanism called by some "server-gated cryptography." Variations of this are used by both Netscape and Microsoft. The idea is that a client may be exported from the US with both strong and export-grade cryptography, but the strong cryptography is enabled only if the server has a particular kind of certificate. In both SSL and TLS, the client must drop the connection and restart the handshake once it knows that it can use additional ciphers. It would simplify things if the client can simply send a new hello message. A more detailed proposal will be forthcoming. TLS Implementation Warning -------------------------- Tim Dierks also warned implementors about the following problem so they would not repeat it: The definition of an SSL/TLS vector <1..65335> is: Hi Lo Contents |LM|LL| | | | ... In all SSL implementations, the client key exchange field is miscoded in RSA and RSA_EXPORT key exchanges: it is missing the length field. Please avoid this error in TLS implementations. Next Steps ---------- Chris Allen noted that the applications protocols are, in essence, our customers now, and we should talk to them often. There were a number of proposed changes discussed in Memphis (two meetings ago), but we have not seen detailed proposals or new drafts to follow up on them. There is continued interest in combining IPSec key exchange mechanisms with TLS. Thanks to Chris Allen for taking the notes during the WG meeting.