W3C home > Mailing lists > Public > ietf-tls@w3.org > April to June 1996

5/29 TLS Meeting Notes

From: Tom Stephens <tomste@microsoft.com>
Date: Wed, 5 Jun 1996 15:12:44 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-88-MSG-960605221244Z-44222@tide19.microsoft.com>
To: "'ietf-tls'" <ietf-tls@w3.org>
A subset (see attendees below) of the TLS working group met in Palo Alto
on May 29.  The purpose of the meeting was to debate and prioritize
which features should be added to SSLv3 to create an Internet standard
TLS.  These are the minutes of that meeting.     

>The following list of topics was discussed.  Below each topic is the
>recommendation of the group and any action items associated with that
>topic.  
>
>1.  Independent algorithm negotiations
>Recommendation:  Do not include in the discussion document or new
>protocol due to time constraints, but consider it for future versions
>of the protocol.
>
>2.  Datagrams
>Recommendation:  Do not include in the discussion document or the new
protocol.  
>
>3.  Pre-encrypted data
>Recommendation:  Include in the discussion document and the new
>protocol if time permits.  
>Action item:  Bennet Yee will examine this issue and report back to the
>group on a way this item can be included in the discussion document.
>
>4.  Pre-MAC'd data
Recommendation:  Bennet Yee and Paul Kocher will look at the issue, and
see if pre-MACing could be included cleanly--in other words, that the
decision was deferred until those two have had a chance to consider it
further.
>
>5.  Remove the fixed combination of SHA and MD5 as the only handshake
hash and add RIPEMD/SHA
Recommendation:  Hardwiring WILL be removed, in the sense that although
there would still be only one defined handshake (and key derivation)
hash method, its definition would be transferred to the cipher suites,
for easier update should it become necessary.  What that new hash method
would be (SHA + RIPEMD or some other combination) was left to the list
for discussion. 
>Action item:  Paul Kocher will propose this to the list.
>
>6.  Password authentication
>Recommendation:  Attendees did not come to a conclusion on this issue.
>Action item:  Include in discussion document.  Dan Simon will write up
>a justification FOR and Phil Karlton will write justification AGAINST
>password authentication in the protocol.  .  Both documents will be
>posted to the mailing list for discussion.
>
>7.  Symmetry
>Recommendation:  Do not include in the discussion document or the new
>protocol.
>Action item:  Dan Simon will write up a proposal for inclusion of hooks
in the new 	protocol for the future symmetry/key exchange options for
discussion in Montreal.

>8.  Error reporting
>Recommendation:  Include in the discussion document and the new
>protocol.
>Action item:  Tom Weinstein will document error/error messages for
>inclusion in the discussion document and the new protocol.
>
>9.  Certificate selection
>Recommendation:  Include in the discussion document and new protocol.
>Action item:  Tom Weinstein will document how to break 3.0.  Tim Dierks
>will document vector details.
>
>10.  Extensibility field
>Recommendation:  Include in the discussion document and new protocol
>for forward compatibility.
>
>11.  Key reset
>Action item:  If time permits, Phil Karlton will write up a proposal
>for including key reset in the discussion document and new protocol.
>
>12.  Non-Fortezza smartcard support
>Recommendation:  Do not include in the discussion document or the new
>protocol due to time constraints.  However, support should be included
>in future versions of the protocol. 
>Action item:  Eric Greenberg will own looking into this issue further.
>
>13.  Application interaction w/protocol
>Action item:  Mark Davis will contribute a paragraph in the discussion
>draft dealing with this issue.
>
>14.  Shortcut certificate discovery
>Recommendation:  Do not include in the discussion document or the new
>protocol.  
>Action item:  Include in Symmetry action item.
>
>15.  Attribute certificates
>Recommendation:  Include in the discussion document and new protocol. 
>Add this topic to the certificate selection topic.
>
>16.  Backwards compatibility
>Recommendation:  Create a policy statement concerning backward
>compatibility.  Consider dropping SSL 2.0 backwards compatibility
>within one year if SSL 2.0 compatibility conflicts with new features.
>Action item:  Discussion document authors to draft a realistic policy
>concerning backwards compatibility.
>
>17.  Port issues
>Recommendation:  Include in the discussion document and new protocol.
>Action item:  Chris Allen will create an appendix to the discussion
>document dealing with this issue.
>
>18.  Data compression
>Recommendation:  Include in the discussion document and new protocol.
Action items:  Review available compression algorithms that are either
not patented or freely available.
>
>19.  Cipher suites
>Recommendation:  Re-examine cipher suites for the discussion document
>and the new protocol.  RC2 should be dropped.
>Action item:  Chris Allen will create a document recommending changes
>in the cipher suite. 
>
>20.  Nomenclature
Recommendation:  No recommendation on what to call the new protocol. 
"TLS" is the current handle.  

21.  The following topics didn't make the cut:

end-point security
>API's
>ASN.1
>Interaction w/Directory
>Certificate management
>CRLs
>Cookies


CONCLUSION:

>The meeting attendees agreed to create a discussion document which
>could be presented to the full TLS mailing list no later than 6/21. 
>Paul Kocher and Bruce Schneier were requested to generate this document
>incorporating features agreed to by the attendees and using the SSL 3.0
>spec as a base.  The goal of this document will be to encourage
>discussion before and during the June IETF meeting so as to expedite
>the creation of an Internet Draft for the TLS protocol.


Tomste@microsoft.com
Tom Stephens, Program Manager
Microsoft


>Attendees:

>Bruce Schneier		Moderator		schneier@counterpane.com
>Gary Brown		CompuServe		gsb@csi.compuserve.com
>Eric Greenberg		Netscape		ericg@netscape.com
>Eric Rescorla		Terisa			ekr@terisa.com
>Carl Cargill		Netscape		carl@netscape.com
>Taher Elgamal		Netscape		elgamal@netscape.com
>Chris Allen		Consensus		christophera@consensus.com
>Joseph Tardo		Raptor			jtardo@raptor.com
>Rob Relyea		Netscape		reylea@netscape.com
>Tom Weinstein		Netscape		tomw@netscape.com
>Paul Kocher		Independent/Netscape	pck@netcom.com
>Martin Abadi		DEC			ma@pa.dec.com
>Mark Davis		IBM			davismc@vnet.ibm.com
>William Soley		Sun			soley@eng.sun.com
>Bennet Yee		UCSD			bsy@cs.ucsd.edu
>Tim Dierks		Consensus		timd@consensus.com
>Ed Eytchison		National Semi, iPower	ed@ipower.nsc.com
>Daniel Simon		Microsoft		dansimon@microsoft.com
>Alan Freier		Netscape		freier@netscape.com
>Phil Karlton		Netscape		karlton@netscape.com
>Susan Langford		Atalla			langford_susan@tandem.com
>Dave Maracchini		Atalla			maracchini_dave@tandem.com
>Mark Schertler		Terisa			mjs@terisa.com
>Barbara Fox		Microsoft		bfox@microsoft.com
>Tom Stephens		Microsoft		tomste@microsoft.com
>John Hines		Netscape		jhines@netscape.com
>Chini Krishnan		Integris Security		chini@inetdata.com
>
Received on Wednesday, 5 June 1996 18:19:16 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:34:49 EDT