home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / tls / tls-minutes-97apr.txt < prev    next >
Text File  |  1997-05-29  |  6KB  |  154 lines
  1. Editor's Note:  These minutes have not been edited.
  2.  
  3.  
  4. Reported by Win Treese <treese@openmarket.com>
  5.  
  6. The TLS working group met during the 38th IETF meeting
  7. in Memphis, Tennessee, on Wednesday, 4/9/97. The meeting
  8. was chaired by Win Treese (treese@OpenMarket.com).
  9.  
  10. Minutes by Christopher Allen (ChristopherA@consensus.com);
  11. edited by Win Treese.
  12.  
  13. Introduction and status
  14. -------------------------------
  15. The Internet Draft for TLS 1.0 is in Last Call for
  16. Proposed Standard with the IESG. The comment
  17. period closes April 25. The chair commended Tim
  18. Dierks and Christopher Allen for their work on the
  19. draft.
  20.  
  21. Tim Dierks summarized some minor changes for
  22. the current draft to be incorporated into the final
  23. version:
  24.  
  25. * The vendor ID string was removed for lack of consensus.
  26. * A new construction for the PRF (as previously noted
  27.     on the mailing list)
  28. * PRF will also be used for Finish message.
  29.  
  30. An objection was raised of using MD5 since there are now some
  31. doubts about how good it is. Ran Canetti noted that the construction
  32. does not require strong collision-randomness. Dan Simon added that
  33. there are no known attacks against this function.
  34.  
  35. Tim then discussed specifying additional cipher suites in additional
  36. documents, including the specification for bulk encryption,
  37. hashes, key exchange, and compression. There have been some
  38. suggestions to share values with other groups, like PPP and IPSEC;
  39. these will be pursued off-line.
  40.  
  41. It has also been proposed that new certificate types can be defined by
  42. adding additional cipher suites, but no agreement was reached on this
  43. approach.
  44.  
  45. There was some discussion of using a truncated PRF in the Finish
  46. messages, but there are no changes at this time.
  47.  
  48. We discussed whether or not the TLS specification should require a
  49. minimum set of cipher suites for conforming implementations. One
  50. difficulty of this is that it would either require weak cipher suites to
  51. enable exportable implementations, or make it impossible to export
  52. conforming implementations. It was suggested that any minimum
  53. cipher specs required for particular applications using TLs could be
  54. specified in "XXX protocol over TLS" documents such as "HTTP over
  55. TLS". The group agreed not to add any minimum requirements at
  56. this time.
  57.  
  58. There was no objections on proceeding through IESG last call, with
  59. the changes described by Tim Dierks.
  60.  
  61. Possible New Work
  62. ---------------------------
  63. Rodney Thayer (thayer@sabletech.com) summarized some
  64. issues from the mailing list as potential work items going forward:
  65.  
  66. Cryptographic Issues
  67.     MAC, Encryption schemes, new schemes
  68. Authentication Issues
  69.     Shared Key Authenticaiton, PGP, non-X.509 certificates,
  70.     SPKI
  71. Relationship to other IETF work
  72.     IPSEC, SASL, ISAKMP
  73. Interoperability requirements
  74. Interface and service definitions
  75. Applications usage
  76.     SSH, port mapping, immediate "customer needs" for using
  77.     TLS (e.g., FTP, SMTP, SSH).
  78. Enhancements to handshake protocol
  79.  
  80. These items were presented as possible work items; no decisions
  81. were made on particular items.
  82.  
  83. Short presentations on proposed modifications
  84. ---------------------------------------------------------------
  85. John Wilson (Intel) discussed the use of TLS for
  86. Internet Telephony & Conferencing. ITU H.323
  87. (protocol for Internet telephony) wants to use TLS.
  88. The key issues causing problems with TLS are end-to-end
  89. trust relationship with a proxy in the center, and a lack
  90. of symmetry with certificate discovery. The proposed
  91. fix is to make the initial handshake symmetric.
  92. Dan Simon noted that reversing the the client/server
  93. relationship could be used as a temporary fix for this
  94. particular application.
  95.  
  96. Ran Canetti (IBM) described some possible changes to
  97. TLS that incorporate some of the ideas from ISAKMP.
  98. These include making the RSA-encryption mode
  99. two-directional, key exchange that is anonymous for
  100. eavesdroppers, perfect forward secrecy for resuming sessions,
  101. and PRF negotiation. There was separate discussion about
  102. making TLS work well with ISAKMP and other IPSEC work
  103. so it may or may not be worthwhile to add those changes.
  104.  
  105. Matt Hur (CyberSafe) described a proposal to add Kerberos
  106. as a cipher suite for TLS. The group agreed to consider the
  107. document for the standards track. A reference implementation
  108. is available at ftp://prospero.isi.edu/pub/ssl-kerb
  109.  
  110. There was some discussion of putting registering the identifiers
  111. for the Kerberos cipher suites into the TLS draft, but we
  112. decided not to do so.
  113.  
  114. Ned Smith (Intel) proposed a way to incorporate non-X509
  115. certificates into the current protocol by overloading current
  116. fields. Adding such support seems like a good idea for the
  117. next version, where it might be done more cleanly.
  118.  
  119. Paul Hoffman (Internet Mail Consortium) described his
  120. proposed implementation of SMTP over TLS using an ESMTP
  121. extension to negotiate TLS, rather than using a different port.
  122.  
  123. John Gardner described two alternative approaches to layering
  124. SASL on TLS. The two are not completely compatible, but
  125. no TLS changes were proposed at this time. For more discussion,
  126. join the SASL mailing list: ietf-sasl-request@imc.org, or see the
  127. web page http://www.imc.org/ietf-sasl
  128.  
  129. Tatu Ylonen presented some ideas for changing TLS to
  130. make it possible to use TLS as the transport security layer
  131. for SSH. SSH needs forward secrecy, more encryption ciphers,
  132. and compression, among other proposed changes. These
  133. will be discussed in more detail on the mailing list.
  134.  
  135. Work Items going forward
  136. ------------------------------------
  137. Treese summarized the work items for continued discussion:
  138.  
  139. * Moving forward on the Kerberos cipher suite draft
  140. * Investigating how to benefit from IPSEC and other security
  141.     area working groups. 
  142. * Shared key authentication (which was not discussed much in
  143.     the meeting, but had previously been deferred)
  144. * Support for non-X509 certificates
  145. * Making the initial handshake symmetric
  146. * Proposed changes to work better with SSH
  147. * IANA registration for cipher suites
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.