Editor's Note: These minutes have not been edited. Reported by Win Treese The TLS working group met during the 38th IETF meeting in Memphis, Tennessee, on Wednesday, 4/9/97. The meeting was chaired by Win Treese (treese@OpenMarket.com). Minutes by Christopher Allen (ChristopherA@consensus.com); edited by Win Treese. Introduction and status ------------------------------- The Internet Draft for TLS 1.0 is in Last Call for Proposed Standard with the IESG. The comment period closes April 25. The chair commended Tim Dierks and Christopher Allen for their work on the draft. Tim Dierks summarized some minor changes for the current draft to be incorporated into the final version: * The vendor ID string was removed for lack of consensus. * A new construction for the PRF (as previously noted on the mailing list) * PRF will also be used for Finish message. An objection was raised of using MD5 since there are now some doubts about how good it is. Ran Canetti noted that the construction does not require strong collision-randomness. Dan Simon added that there are no known attacks against this function. Tim then discussed specifying additional cipher suites in additional documents, including the specification for bulk encryption, hashes, key exchange, and compression. There have been some suggestions to share values with other groups, like PPP and IPSEC; these will be pursued off-line. It has also been proposed that new certificate types can be defined by adding additional cipher suites, but no agreement was reached on this approach. There was some discussion of using a truncated PRF in the Finish messages, but there are no changes at this time. We discussed whether or not the TLS specification should require a minimum set of cipher suites for conforming implementations. One difficulty of this is that it would either require weak cipher suites to enable exportable implementations, or make it impossible to export conforming implementations. It was suggested that any minimum cipher specs required for particular applications using TLs could be specified in "XXX protocol over TLS" documents such as "HTTP over TLS". The group agreed not to add any minimum requirements at this time. There was no objections on proceeding through IESG last call, with the changes described by Tim Dierks. Possible New Work --------------------------- Rodney Thayer (thayer@sabletech.com) summarized some issues from the mailing list as potential work items going forward: Cryptographic Issues MAC, Encryption schemes, new schemes Authentication Issues Shared Key Authenticaiton, PGP, non-X.509 certificates, SPKI Relationship to other IETF work IPSEC, SASL, ISAKMP Interoperability requirements Interface and service definitions Applications usage SSH, port mapping, immediate "customer needs" for using TLS (e.g., FTP, SMTP, SSH). Enhancements to handshake protocol These items were presented as possible work items; no decisions were made on particular items. Short presentations on proposed modifications --------------------------------------------------------------- John Wilson (Intel) discussed the use of TLS for Internet Telephony & Conferencing. ITU H.323 (protocol for Internet telephony) wants to use TLS. The key issues causing problems with TLS are end-to-end trust relationship with a proxy in the center, and a lack of symmetry with certificate discovery. The proposed fix is to make the initial handshake symmetric. Dan Simon noted that reversing the the client/server relationship could be used as a temporary fix for this particular application. Ran Canetti (IBM) described some possible changes to TLS that incorporate some of the ideas from ISAKMP. These include making the RSA-encryption mode two-directional, key exchange that is anonymous for eavesdroppers, perfect forward secrecy for resuming sessions, and PRF negotiation. There was separate discussion about making TLS work well with ISAKMP and other IPSEC work so it may or may not be worthwhile to add those changes. Matt Hur (CyberSafe) described a proposal to add Kerberos as a cipher suite for TLS. The group agreed to consider the document for the standards track. A reference implementation is available at ftp://prospero.isi.edu/pub/ssl-kerb There was some discussion of putting registering the identifiers for the Kerberos cipher suites into the TLS draft, but we decided not to do so. Ned Smith (Intel) proposed a way to incorporate non-X509 certificates into the current protocol by overloading current fields. Adding such support seems like a good idea for the next version, where it might be done more cleanly. Paul Hoffman (Internet Mail Consortium) described his proposed implementation of SMTP over TLS using an ESMTP extension to negotiate TLS, rather than using a different port. John Gardner described two alternative approaches to layering SASL on TLS. The two are not completely compatible, but no TLS changes were proposed at this time. For more discussion, join the SASL mailing list: ietf-sasl-request@imc.org, or see the web page http://www.imc.org/ietf-sasl Tatu Ylonen presented some ideas for changing TLS to make it possible to use TLS as the transport security layer for SSH. SSH needs forward secrecy, more encryption ciphers, and compression, among other proposed changes. These will be discussed in more detail on the mailing list. Work Items going forward ------------------------------------ Treese summarized the work items for continued discussion: * Moving forward on the Kerberos cipher suite draft * Investigating how to benefit from IPSEC and other security area working groups. * Shared key authentication (which was not discussed much in the meeting, but had previously been deferred) * Support for non-X509 certificates * Making the initial handshake symmetric * Proposed changes to work better with SSH * IANA registration for cipher suites