From khare@pest.w3.org Fri Mar 8 15:06:34 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id PAA15265 for ; Fri, 8 Mar 1996 15:06:34 -0500 Received: from pest.w3.org by www10.w3.org (5.0/NSCS-1.0S) id AA28407; Fri, 8 Mar 1996 15:06:35 +0500 Received: by pest.w3.org (NX5.67f2/NX3.0S) id AA05630; Fri, 8 Mar 96 15:08:04 -0500 Message-Id: <9603082008.AA05630@pest.w3.org> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Received: by NeXT.Mailer (1.118.3) From: Rohit Khare Date: Fri, 8 Mar 96 15:08:02 -0500 To: ietf-tls@w3.org Subject: Welcome to the IETF-TLS mailing list Reply-To: khare@w3.org X-Url: http://xent.w3.org/ content-length: 285 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls This is the mailing list announced at the March 4 Transport Layer Security BOF in Los Angeles. The list's initial focus is to define a charter and plan for a proposed TLS Working Group. The BOF chair was Jeff Schiller, JIS@mit.edu. I am only maintaining this list... Rohit Khare From elgamal@netscape.com Mon Mar 11 12:41:07 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id MAA19018 for ; Mon, 11 Mar 1996 12:41:06 -0500 Received: from urchin.netscape.com (unknown.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA08425; Mon, 11 Mar 1996 12:41:05 +0500 Received: from taher.mcom (cipher.mcom.com [205.217.236.28]) by urchin.netscape.com (8.6.12/8.6.9) with SMTP id JAA10790 for ; Mon, 11 Mar 1996 09:41:05 -0800 Message-Id: <3144664F.6D3A@netscape.com> Date: Mon, 11 Mar 1996 09:43:43 -0800 From: Taher Elgamal X-Mailer: Mozilla 2.0GoldB1 (Win95; I) Mime-Version: 1.0 To: ietf-tls@w3.org Subject: Draft Charter -- Please review and comment Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 2144 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Charter for TLS (Transport Layer Security) WG: Current status: drafts Chair(s): TBD Security Area Director(s): Jeffrey Schiller Mailing lists: General discussion: ietf-tls@w3.org To subscribe: ietf-tls-request@w3.org Archive: Description and charter of the TLC Working Group: Several methods of providing a secure and authenticated channel between a client and a server on the Internet above the TCP layer have appeared. The objective of this proposed working group is to write standards track RFC(s) for protocols using the currently available Internet drafts as a basis. The SSL, PCT and SSH protocols are examples of mechanisms of establishing a secure channel for general purpose or special purpose Internet applications running over a reliable transport, TCP in the most part. The TLS working group is a focused effort on providing security features at the transport layer, rather than general purpose security and key management mechanisms. The standard track protocol specification will provide a method of implementing privacy, authentication and integrity above the transport layer. The work currently under way in the area of secure IP is outside the scope of this working group. Also, general authentication mechanism discussions are outside the focus of this group. However, best efforts will be made to utilize as much as possible of the already existing technologies and methodologies in the IETF and other places to solve common problems, for example key management. An informational RFC might also be issued to describe conventions for the interface to a Socket (or transport) layer secure library to build specific applications as well as TCP port number conventions for running secure versions of network applications. Goals and Milestones March 96 Agreement on charter and issues in current draft. July 96 Final draft for Secure Transport Layer Protocol "STLP" Nov 96 Working group "Last Call" Dec 96 Offer to IESG for IETF "Last Call" -- Taher Elgamal elgamal@netscape,com Chief Scientist, Netscape Communications (T) 415 528 2898, (F) 415 528 4122 From khare@pest.w3.org Mon Mar 11 15:02:39 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id PAA26657 for ; Mon, 11 Mar 1996 15:02:38 -0500 Received: from pest.w3.org by www10.w3.org (5.0/NSCS-1.0S) id AA09478; Mon, 11 Mar 1996 15:02:37 +0500 Received: by pest.w3.org (NX5.67f2/NX3.0S) id AA08233; Mon, 11 Mar 96 15:04:00 -0500 Message-Id: <9603112004.AA08233@pest.w3.org> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Received: by NeXT.Mailer (1.118.3) From: Rohit Khare Date: Mon, 11 Mar 96 15:03:57 -0500 To: Taher Elgamal Subject: Re: Draft Charter -- Please review and comment Cc: ietf-tls@w3.org Reply-To: khare@w3.org References: <3144664F.6D3A@netscape.com> X-Url: http://xent.w3.org/ content-length: 161 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls >> provide a method of implementing privacy, authentication and integrity At the BOF, I believe there was a sentiment to make this an "and/or"... Rohit Khare From ericm@lne.com Mon Mar 11 15:13:09 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id PAA27253 for ; Mon, 11 Mar 1996 15:13:09 -0500 Received: from slack.lne.com by www10.w3.org (5.0/NSCS-1.0S) id AA09554; Mon, 11 Mar 1996 15:13:06 +0500 Received: (from ericm@localhost) by slack.lne.com (8.7.1/1.0) id MAA06380; Mon, 11 Mar 1996 12:12:29 -0800 From: Eric Murray Message-Id: <199603112012.MAA06380@slack.lne.com> Subject: Re: Draft Charter -- Please review and comment To: elgamal@netscape.com (Taher Elgamal) Date: Mon, 11 Mar 1996 12:12:28 -0800 (PST) Cc: ietf-tls@w3.org In-Reply-To: <3144664F.6D3A@netscape.com> from "Taher Elgamal" at Mar 11, 96 09:43:43 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit content-length: 350 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Taher Elgamal writes: > Charter for TLS (Transport Layer Security) WG: > > Current status: drafts > > Chair(s): TBD What's the current status with regard to selecting the Chair(s)? -- Eric Murray ericm@lne.com ericm@motorcycle.com http://www.lne.com/ericm PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03 92 E8 AC E6 7E 27 29 AF From khare@pest.w3.org Mon Mar 11 15:36:58 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id PAA28428 for ; Mon, 11 Mar 1996 15:36:58 -0500 Received: from pest.w3.org by www10.w3.org (5.0/NSCS-1.0S) id AA09744; Mon, 11 Mar 1996 15:36:57 +0500 Received: by pest.w3.org (NX5.67f2/NX3.0S) id AA08337; Mon, 11 Mar 96 15:38:13 -0500 Message-Id: <9603112038.AA08337@pest.w3.org> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Received: by NeXT.Mailer (1.118.3) From: Rohit Khare Date: Mon, 11 Mar 96 15:38:11 -0500 To: Taher Elgamal Subject: Re: Draft Charter -- Please review and comment Cc: ietf-tls@w3.org Reply-To: khare@w3.org References: <3144664F.6D3A@netscape.com> X-Url: http://xent.w3.org/ content-length: 325 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls > Chair(s): TBD > > Security Area Director(s): > Jeffrey Schiller Also for the record, the following candidates stood for Chair, and they will discuss a solution jointly with Jeff this week: Win Treese, Open Market Charlie Kaufman, Iris Taher ElGamal, Netscape Barbara Fox, Microsoft Rohit Khare From bfox@microsoft.com Mon Mar 11 16:24:00 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id QAA00004 for ; Mon, 11 Mar 1996 16:24:00 -0500 Received: from tide10.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA10044; Mon, 11 Mar 1996 16:23:50 +0500 Received: by tide10.microsoft.com; id NAA05463; Mon, 11 Mar 1996 13:25:18 -0800 Received: from unknown(157.54.17.74) by tide10.microsoft.com via smap (g3.0.3) id xma005448; Mon, 11 Mar 96 13:25:03 -0800 Received: from xnet1 (xnet1.microsoft.com [157.54.17.204]) by imail2.microsoft.com (8.7.3/8.7.1) with SMTP id NAA09072 for ; Mon, 11 Mar 1996 13:27:32 -0800 (PST) X-Received: from red-42-msg by xnet1 with receive; Mon, 11 Mar 1996 13:23:09 -0800 X-Msmail-Message-Id: 10A78311 X-Msmail-Conversation-Id: 10A78311 From: Barb Fox To: ietf-tls@w3.org Date: Mon, 11 Mar 96 13:24:55 PST Subject: Comment on Draft Charter X-Msxmtid: red-42-msg960311212257MTP[01.52.00]000000ce-378 Message-Id: content-length: 299 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Read the draft charter published on this list and noticed the following: July 96 Final draft for Secure Transport Layer Protocol "STLP" This date wasn't mentioned in the BOF. Doesn't this presume that a Proposed Standard has already come from the working group? Barb Fox bfox@microsoft.com From khare@pest.w3.org Mon Mar 11 16:48:17 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id QAA01246 for ; Mon, 11 Mar 1996 16:48:08 -0500 Received: from pest.w3.org by www10.w3.org (5.0/NSCS-1.0S) id AA10200; Mon, 11 Mar 1996 16:47:40 +0500 Received: by pest.w3.org (NX5.67f2/NX3.0S) id AA08465; Mon, 11 Mar 96 16:49:04 -0500 Message-Id: <9603112149.AA08465@pest.w3.org> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Received: by NeXT.Mailer (1.118.3) From: Rohit Khare Date: Mon, 11 Mar 96 16:49:03 -0500 To: Barb Fox Subject: Re: Comment on Draft Charter Cc: ietf-tls@w3.org Reply-To: khare@w3.org References: red-42-msg960311212257MTP[01.52.00]000000ce-378 X-Url: http://xent.w3.org/ content-length: 993 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls > Read the draft charter published on this list and noticed > the following: > > July 96 Final draft for Secure Transport Layer Protocol > "STLP" > > This date wasn't mentioned in the BOF. Doesn't this > presume that a Proposed Standard has already come from > the working group? > > Barb Fox bfox@microsoft.com The *date* was certainly not brought up in the BOF, especially since this is te crucial, debated expectation of "unification by Montreal". This was not an oversight, though; the charter discussion explicitly avoided milestone issues that evening. Separately, though, I thought I'd note that the WG's 'final draft' is only the beginning of the stdization process. Final drafts are submitted to the IESG with a recommendation to Proposed; then a Last Call is held. Later, evidence of its success can be brought to the IESG to promote it to STD status. Besides, I can think of a pretty cool logo for STP -- STLP can't even be pronounced! :-) Rohit Khare From elgamal@netscape.com Mon Mar 11 17:06:02 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id RAA02223 for ; Mon, 11 Mar 1996 17:06:02 -0500 Received: from urchin.netscape.com (unknown.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA10459; Mon, 11 Mar 1996 17:06:00 +0500 Received: from taher.mcom (cipher.mcom.com [205.217.236.28]) by urchin.netscape.com (8.6.12/8.6.9) with SMTP id OAA20192; Mon, 11 Mar 1996 14:05:38 -0800 Message-Id: <3144A44D.2484@netscape.com> Date: Mon, 11 Mar 1996 14:08:13 -0800 From: Taher Elgamal X-Mailer: Mozilla 2.0GoldB1 (Win95; I) Mime-Version: 1.0 To: Barb Fox Cc: ietf-tls@w3.org Subject: Re: Comment on Draft Charter References: red-42-msg960311212257MTP[01.52.00]000000ce-378 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 803 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Barb Fox wrote: > > Read the draft charter published on this list and noticed the following: > > July 96 Final draft for Secure Transport Layer Protocol "STLP" > > This date wasn't mentioned in the BOF. Doesn't this presume that a > Proposed Standard has already come from the working group? > > Barb Fox > bfox@microsoft.com These are "guess" dates at this point. The point is that if we were to get an RFC by the end of the year -- a "final" draft needs to be available soon. My guess is that the sooner this get resolved the better -- with the right technical soltion of course. We also have enough combined expertise that this is not totally out of the question. -- Taher Elgamal elgamal@netscape,com Chief Scientist, Netscape Communications (T) 415 528 2898, (F) 415 528 4122 From WEAVER%SPARKS.decnet@hydra.dra.hmg.gb Wed Mar 13 10:44:37 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id KAA27120 for ; Wed, 13 Mar 1996 10:44:37 -0500 Received: from LCS.MIT.EDU (mintaka.lcs.mit.edu) by www10.w3.org (5.0/NSCS-1.0S) id AA18500; Wed, 13 Mar 1996 10:44:35 +0500 Received: from hydra.dra.hmg.gb by MINTAKA.LCS.MIT.EDU id aa29332; 13 Mar 96 10:43 EST Date: 13 Mar 96 15:31:00 GMT From: "SPARKS::WEAVER" Subject: Info_reqd To: "ietf-tls" Message-Id: <9603131043.aa29332@MINTAKA.LCS.MIT.EDU> content-length: 222 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls At the TLS BOF a recommended reading list was given. Unfortunatley I lost my notes ! Could someone please forward the URL's for the documents that were recommended for reading. Elfed T. Weaver weaver@hydra.dra.hmg.gb From cmadson@baynetworks.com Thu Mar 14 18:41:03 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id SAA25232 for ; Thu, 14 Mar 1996 18:41:03 -0500 Received: from lobster.wellfleet.com (lobster.corpeast.baynetworks.com) by www10.w3.org (5.0/NSCS-1.0S) id AA26360; Thu, 14 Mar 1996 18:41:03 +0500 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA12310; Thu, 14 Mar 96 18:40:18 EST Received: from gopher.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA23703; Thu, 14 Mar 96 18:41:01 EST Date: Thu, 14 Mar 96 18:41:01 EST From: cmadson@baynetworks.com (Cheryl Madson) Message-Id: <9603142341.AA23703@pobox.BayNetworks.com> To: ietf-tls@w3.org Subject: re. Draft Charter Cc: cmadson@baynetworks.com content-length: 508 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls I'll throw something on the table: why just TCP-based sessions? Why not UDP? I'm not overly hopeful of *secure* SNMPv(whatever) coming along "soon". I suspect many management stations have the same stack problem as our web browser systems. I'd like to see something in the standards space to address alternative solutions to this issue. [Unfortunately I'm way behind in plowing through the mountain of existing IDs, etc., so if there is anything that does address this, I'm interested in pointers.] - C From paulh@imc.org Sun Mar 31 16:51:15 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id QAA02229 for ; Sun, 31 Mar 1996 16:51:14 -0500 Received: from imc.org by www10.w3.org (5.0/NSCS-1.0S) id AA15334; Sun, 31 Mar 1996 16:51:13 +0500 Received: from [165.227.10.43] (cruzio43.cruzio.com [165.227.10.43]) by imc.org (8.7.4/8.7.1) with ESMTP id NAA05010 for ; Sun, 31 Mar 1996 13:49:45 -0800 (PST) X-Sender: paulh@imc.imc.org Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 31 Mar 1996 13:51:56 -0800 To: ietf-tls@w3.org From: Paul Hoffman Subject: Do we have chairpeople yet? content-length: 281 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Unless I missed something, we haven't heard about who is going to chair this potential WG. So far the questions put on this mailing list (a request for information on the chairs, or a repeat of the reading list) have gone unanswered. This does not bode well for an active group. From ChristopherA@consensus.com Sun Mar 31 17:42:34 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id RAA02994 for ; Sun, 31 Mar 1996 17:42:33 -0500 Received: from consensus.com ([157.22.240.7]) by www10.w3.org (5.0/NSCS-1.0S) id AA15508; Sun, 31 Mar 1996 17:42:32 +0500 Received: from [157.22.240.12] by consensus.com with ESMTP (Apple Internet Mail Server 1.0); Sun, 31 Mar 1996 14:42:19 -0800 Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Organization: Consensus Development Corporation Date: Sun, 31 Mar 1996 14:42:00 -0800 To: ietf-tls@w3.org From: Christopher Allen Subject: Re: Do we have chairpeople yet? content-length: 891 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls At 1:51 PM 3/31/96, Paul Hoffman wrote: >Unless I missed something, we haven't heard about who is going to chair >this potential WG. > >So far the questions put on this mailing list (a request for information on >the chairs, or a repeat of the reading list) have gone unanswered. This >does not bode well for an active group. I'm interested in becoming very actively involved and offer support to this WG, but having just heard about it I also don't have any information on who is else is involved, the exact charter, etc. ------------------------------------------------------------------------ ..Christopher Allen Consensus Development Corporation.. .. 1563 Solano Avenue #355.. .. Berkeley, CA 94707-2116.. .. o510/559-1500 f510/559-1505.. From khare@pest.w3.org Sun Mar 31 22:49:26 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id WAA05294 for ; Sun, 31 Mar 1996 22:49:25 -0500 Received: from pest.w3.org by www10.w3.org (5.0/NSCS-1.0S) id AA16265; Sun, 31 Mar 1996 22:49:20 +0500 Received: by pest.w3.org (NX5.67f2/NX3.0S) id AA02996; Sun, 31 Mar 96 22:51:21 -0500 Date: Sun, 31 Mar 96 22:51:21 -0500 From: Rohit Khare Message-Id: <9604010351.AA02996@pest.w3.org> To: ietf-tls@w3.org, paulh@imc.org Subject: Re: Do we have chairpeople yet? content-length: 251 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls My aplogies: as list administrator, I did not realize that Jeff Schiller's announcment of Win Treese as chair did not get sent to the list (because jis@mit.edu is not a subscriber, it was bounced; I have fixed the list to accept anyone now). Rohit From khare@pest.w3.org Sun Mar 31 22:51:13 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id WAA05314 for ; Sun, 31 Mar 1996 22:51:12 -0500 Received: from pest.w3.org by www10.w3.org (5.0/NSCS-1.0S) id AA16274; Sun, 31 Mar 1996 22:51:11 +0500 Received: by pest.w3.org (NX5.67f2/NX3.0S) id AA03007; Sun, 31 Mar 96 22:53:12 -0500 Date: Sun, 31 Mar 96 22:53:12 -0500 From: Rohit Khare Message-Id: <9604010353.AA03007@pest.w3.org> To: ietf-tls@w3.org Subject: Win Treese will Chair the Working Group [From Jeff Schiller] content-length: 818 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Old-Date: Fri, 29 Mar 1996 13:31:48 -0500 To: ietf-tls@w3.org From: jis@mit.edu (Jeffrey I. Schiller) Subject: Win Treese will Chair the Working Group Content-Length: 517 X-List-Url: http://lists.w3.org/Archives/Public/ietf-tls X-Diagnostic: Not on the accept list X-Envelope-To: ietf-tls Status: RO At the TLS BOF in Los Angeles four people volunteered to chair the working group. Rather then hash out who would in fact chair the group during the meeting, we agreed to have the four volunteers and myself have a conversation to decide how to proceed. On March 14th Taher Elgamal, Barbara Fox, Charlie Kaufman, Win Treese, and myself conducted a teleconference settle this issue. Our conclusion was that we all felt it best if Win Treese would act as the Chair of the group. -Jeff From treese@openmarket.com Sat Apr 6 01:30:34 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id BAA15062 for ; Sat, 6 Apr 1996 01:30:33 -0500 Received: from relay.openmarket.com by www10.w3.org (5.0/NSCS-1.0S) id AA03299; Sat, 6 Apr 1996 01:30:31 +0500 Received: from caddo.openmarket.com (aqaba.openmarket.com [199.170.183.105]) by relay.openmarket.com (8.6.10/8.6.6) with ESMTP id BAA21313 for ; Sat, 6 Apr 1996 01:30:30 -0500 Received: from OpenMarket.com (treese@localhost [127.0.0.1]) by caddo.openmarket.com (8.6.12/8.6.6) with ESMTP id BAA02321 for ; Sat, 6 Apr 1996 01:30:25 -0500 Message-Id: <199604060630.BAA02321@caddo.openmarket.com> To: ietf-tls@w3.org Subject: Revised Draft Charter Date: Sat, 06 Apr 1996 01:30:25 -0500 From: Win Treese content-length: 2723 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Hello. As Jeff mentioned, I will be chairing the working group. Our first order of business is to nail down the charter so the working group can be officially created. Taher Elgamal posted his original draft charter for the group a couple of weeks ago. I have incorporated the comments from the list and a few other minor changes into the revised charter below. If there are no substantive changes proposed by April 15, I will forward the proposed charter to Jeff Schiller for the IESG. Win Treese Open Market, Inc. treese@OpenMarket.com http://www.openmarket.com Charter for TLS (Transport Layer Security) WG: Current status: drafts Chair(s): Win Treese Security Area Director(s): Jeffrey Schiller Mailing lists: General discussion: ietf-tls@w3.org To subscribe: ietf-tls-request@w3.org Archive: http://lists.w3.org/Archives/Public/ietf-tls/ Description and charter of the TLS Working Group: Several methods of providing a secure and authenticated channel between a client and a server on the Internet above the TCP layer have appeared. The objective of this proposed working group is to write standards track RFC(s) for protocols using the currently available Internet drafts as a basis. The SSL, PCT and SSH protocols are examples of mechanisms of establishing a secure channel for general purpose or special purpose Internet applications running over a reliable transport, usually TCP. The TLS working group is a focused effort on providing security features at the transport layer, rather than general purpose security and key management mechanisms. The standard track protocol specification will provide methods for implementing privacy, authentication, and integrity above the transport layer. The work currently under way in the area of secure IP is outside the scope of this working group. Also, general authentication mechanism discussions are outside the focus of this group. However, best efforts will be made to utilize as much as possible of the already existing technologies and methodologies in the IETF and other places to solve common problems, such as key management. The group may also produce an informational RFC to describe conventions for the interface to a Socket (or transport) layer secure library to build specific applications as well as TCP port number conventions for running secure versions of network applications. Goals and Milestones April 96 Agreement on charter and issues in current draft. July 96 Final draft for Secure Transport Layer Protocol ("STLP") Nov 96 Working group "Last Call" Dec 96 Offer to IESG for IETF "Last Call" From paulh@imc.org Sat Apr 6 14:09:15 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id OAA19228 for ; Sat, 6 Apr 1996 14:09:14 -0500 Received: from imc.org by www10.w3.org (5.0/NSCS-1.0S) id AA04406; Sat, 6 Apr 1996 14:09:12 +0500 Received: from [165.227.10.43] (cruzio43.cruzio.com [165.227.10.43]) by imc.org (8.7.4/8.7.1) with ESMTP id LAA19132 for ; Sat, 6 Apr 1996 11:07:29 -0800 (PST) Message-Id: In-Reply-To: <199604060630.BAA02321@caddo.openmarket.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 6 Apr 1996 11:08:00 -0800 To: ietf-tls@w3.org From: Paul Hoffman Subject: Re: Revised Draft Charter content-length: 893 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls The charter looks good to me. I have one small concern that, if others agree, could be easily resolved. >Several methods of providing a secure and authenticated channel >between a client and a server on the Internet above the TCP layer have >appeared. The objective of this proposed working group is to write >standards track RFC(s) for protocols using the currently available >Internet drafts as a basis. These two sentences together make it sound lke the protocol will be for client-server channels only. As the HTTP WG has discovered, calling something a "client" or a "server" can cause all sorts of problems when you later have "proxies". Further, we may want STLP to work in peer-to-peer situations. I suggest we reword the first sentence to read: Several methods of providing a secure and authenticated channel between computers on the Internet above the TCP layer have appeared. From treese@openmarket.com Sat Apr 6 23:45:11 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id XAA20661 for ; Sat, 6 Apr 1996 23:45:06 -0500 Received: from relay.openmarket.com by www10.w3.org (5.0/NSCS-1.0S) id AA05472; Sat, 6 Apr 1996 23:45:02 +0500 Received: from caddo.openmarket.com (caddo2.openmarket.com [204.178.213.13]) by relay.openmarket.com (8.6.10/8.6.6) with ESMTP id XAA00185; Sat, 6 Apr 1996 23:45:01 -0500 Received: from OpenMarket.com (treese@localhost [127.0.0.1]) by caddo.openmarket.com (8.6.12/8.6.6) with ESMTP id DAA02758; Sat, 6 Apr 1996 03:34:06 -0500 Message-Id: <199604060834.DAA02758@caddo.openmarket.com> To: Paul Hoffman Cc: ietf-tls@w3.org Subject: Re: Revised Draft Charter In-Reply-To: Message from Paul Hoffman of 6 Apr 1996 11:08:00 PST Date: Sat, 06 Apr 1996 03:34:06 -0500 From: Win Treese content-length: 323 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls > I suggest we reword the first sentence to read: > > Several methods of providing a secure and authenticated channel > between computers on the Internet above the TCP layer have appeared. I'll take that as a friendly amendment. Win Treese Open Market, Inc. treese@OpenMarket.com http://www.openmarket.com From wsimpson@greendragon.com Sun Apr 7 09:58:02 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id JAA22003 for ; Sun, 7 Apr 1996 09:58:00 -0400 Received: from merit.edu by www10.w3.org (5.0/NSCS-1.0S) id AA06145; Sun, 7 Apr 1996 09:57:58 +0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm002-21.dialip.mich.net [141.211.7.157]) by merit.edu (8.7.5/merit-2.0) with SMTP id JAA21824 for ; Sun, 7 Apr 1996 09:57:52 -0400 (EDT) Date: Sun, 7 Apr 96 13:50:48 GMT From: "William Allen Simpson" Message-Id: <5210.wsimpson@greendragon.com> To: ietf-tls@w3.org Subject: Re: Revised Draft Charter content-length: 1213 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls > From: Win Treese > standards track RFC(s) for protocols using the currently available > Internet drafts as a basis. The SSL, PCT and SSH protocols are > examples of mechanisms of establishing a secure channel for general > purpose or special purpose Internet applications running over a > reliable transport, usually TCP. > Are we limited to these drafts? Or do other drafts already presented to the IPSec WG (specifically Photuris) that include general mechanisms for transport-layer security negotiation possible? The above seems to conflict with the "best effort" clause on key management: > The work currently under way in the area of secure IP is outside the > scope of this working group. Also, general authentication mechanism > discussions are outside the focus of this group. However, best efforts > will be made to utilize as much as possible of the already existing > technologies and methodologies in the IETF and other places to solve > common problems, such as key management. > WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From rodney@sabletech.com Sun Apr 7 14:59:02 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id OAA22874 for ; Sun, 7 Apr 1996 14:59:02 -0400 Received: from wizard.pn.com by www10.w3.org (5.0/NSCS-1.0S) id AA06597; Sun, 7 Apr 1996 14:59:00 +0500 Received: from ferguson ([199.249.254.9]) by wizard.pn.com (8.6.12) with SMTP id OAA17210 for ; Sun, 7 Apr 1996 14:58:58 -0400 Message-Id: <199604071858.OAA17210@wizard.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 07 Apr 1996 13:56:57 -0400 To: ietf-tls@w3.org From: Rodney Thayer Subject: regarding draft charter content-length: 610 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls I think it is important to address the issue of migration from existing protocols to the charter. Even if what ends up getting produced contains an explicit claim it does not address migration. I do not think it should be silently ignored. Rodney Thayer :: rodney@sabletech.com Sable Technology Corp :: +1 617 332 7292 246 Walnut St :: Fax: +1 617 332 7970 Newton MA 02160 USA :: http://www.shore.net/~sable "Developers of communications software" From rodney@sabletech.com Sun Apr 7 14:59:05 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id OAA22880 for ; Sun, 7 Apr 1996 14:59:04 -0400 Received: from wizard.pn.com by www10.w3.org (5.0/NSCS-1.0S) id AA06600; Sun, 7 Apr 1996 14:59:03 +0500 Received: from ferguson ([199.249.254.9]) by wizard.pn.com (8.6.12) with SMTP id OAA17217 for ; Sun, 7 Apr 1996 14:59:00 -0400 Message-Id: <199604071859.OAA17217@wizard.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 07 Apr 1996 13:56:59 -0400 To: ietf-tls@w3.org From: Rodney Thayer Subject: tls + photuris? content-length: 2598 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls I'm not sure how to say this in the charter in a clear and concise manner, but I thought this was intended as an actual mechanism for passing data, i.e. the example being ssl3 used for a web browser to exchange data with a web server. Note the ongoing data transmission. I thought photuris was only for the negotiation phase and was not intended for use in sending the actual data -- the model being that photuris did the negotiation then something else (esp?) did the data transmission. >Resent-Date: Sun, 7 Apr 1996 09:58:08 -0400 >Resent-Message-Id: <199604071358.JAA22022@www19.w3.org> >Date: Sun, 7 Apr 96 13:50:48 GMT >From: "William Allen Simpson" >To: ietf-tls@w3.org >Subject: Re: Revised Draft Charter >X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls >Resent-From: ietf-tls@w3.org >X-Mailing-List: archive/latest/18 >X-Loop: ietf-tls@w3.org >Sender: ietf-tls-request@w3.org >Resent-Sender: ietf-tls-request@w3.org > >> From: Win Treese >> standards track RFC(s) for protocols using the currently available >> Internet drafts as a basis. The SSL, PCT and SSH protocols are >> examples of mechanisms of establishing a secure channel for general >> purpose or special purpose Internet applications running over a >> reliable transport, usually TCP. >> >Are we limited to these drafts? Or do other drafts already presented to >the IPSec WG (specifically Photuris) that include general mechanisms for >transport-layer security negotiation possible? > >The above seems to conflict with the "best effort" clause on key >management: > > >> The work currently under way in the area of secure IP is outside the >> scope of this working group. Also, general authentication mechanism >> discussions are outside the focus of this group. However, best efforts >> will be made to utilize as much as possible of the already existing >> technologies and methodologies in the IETF and other places to solve >> common problems, such as key management. >> > >WSimpson@UMich.edu > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 >BSimpson@MorningStar.com > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 > > > Rodney Thayer :: rodney@sabletech.com Sable Technology Corp :: +1 617 332 7292 246 Walnut St :: Fax: +1 617 332 7970 Newton MA 02160 USA :: http://www.shore.net/~sable "Developers of communications software" From rodney@sabletech.com Sun Apr 7 15:14:22 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id PAA22927 for ; Sun, 7 Apr 1996 15:14:22 -0400 Received: from wizard.pn.com by www10.w3.org (5.0/NSCS-1.0S) id AA06643; Sun, 7 Apr 1996 15:14:20 +0500 Received: from ferguson ([199.249.254.9]) by wizard.pn.com (8.6.12) with SMTP id PAA17710 for ; Sun, 7 Apr 1996 15:14:14 -0400 Message-Id: <199604071914.PAA17710@wizard.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 07 Apr 1996 14:12:14 -0400 To: ietf-tls@w3.org From: Rodney Thayer Subject: Re: Revised Draft Charter content-length: 1944 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls sounds like a reasonable change. I personally would have said "nodes" not computers (never can tell when we'll have to update those light switches and garage door openers to IPv6) >Resent-Date: Sat, 6 Apr 1996 14:09:20 -0500 >Resent-Message-Id: <199604061909.OAA19243@www19.w3.org> >Date: Sat, 6 Apr 1996 11:08:00 -0800 >To: ietf-tls@w3.org >From: Paul Hoffman >Subject: Re: Revised Draft Charter >X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls >Resent-From: ietf-tls@w3.org >X-Mailing-List: archive/latest/16 >X-Loop: ietf-tls@w3.org >Sender: ietf-tls-request@w3.org >Resent-Sender: ietf-tls-request@w3.org > >The charter looks good to me. I have one small concern that, if others >agree, could be easily resolved. > >>Several methods of providing a secure and authenticated channel >>between a client and a server on the Internet above the TCP layer have >>appeared. The objective of this proposed working group is to write >>standards track RFC(s) for protocols using the currently available >>Internet drafts as a basis. > >These two sentences together make it sound lke the protocol will be for >client-server channels only. As the HTTP WG has discovered, calling >something a "client" or a "server" can cause all sorts of problems when you >later have "proxies". Further, we may want STLP to work in peer-to-peer >situations. > >I suggest we reword the first sentence to read: > >Several methods of providing a secure and authenticated channel >between computers on the Internet above the TCP layer have appeared. > > > > Rodney Thayer :: rodney@sabletech.com Sable Technology Corp :: +1 617 332 7292 246 Walnut St :: Fax: +1 617 332 7970 Newton MA 02160 USA :: http://www.shore.net/~sable "Developers of communications software" From tim@dierks.org Mon Apr 8 04:21:11 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id EAA28402 for ; Mon, 8 Apr 1996 04:21:10 -0400 Received: from dns2.noc.best.net by www10.w3.org (5.0/NSCS-1.0S) id AA08410; Mon, 8 Apr 1996 04:21:05 +0500 Received: from [205.149.165.24] (tdierks.vip.best.com [205.149.165.24]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id BAA12311 for ; Mon, 8 Apr 1996 01:21:01 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 8 Apr 1996 01:17:15 -0700 To: ietf-tls (Transport Layer Security WG) From: timd@consensus.com (Tim Dierks) Subject: Re: Revised Draft Charter content-length: 1401 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls At 1:30 AM 4/6/96, Win Treese wrote: >The group may also produce an informational RFC to describe conventions for >the interface to a Socket (or transport) layer secure library to build >specific applications as well as TCP port number conventions for running >secure versions of network applications. I'd like to see the group address issues surrounding disambiguating secure sessions from insecure ones. For example, issues have been raised on the SSL-talk list about whether using different port numbers is an appropriate method of distinguishing protocols which are identical except for their use (or lack thereof) of a secure transport layer. Given the limited number of "trusted" port numbers (1024 or so), it seems that multiplying the number of services by the number of possible transports might quickly lead to a crisis. We should at least discuss methods of sharing ports between secure and insecure sessions. I'd also like to discuss authentication requirements for secure transports (i.e., should there be required attributes in X.509 certificates for TLS which specify the IP address or DNS name of the host in question), but I'm not certain if that isn't already covered by the charter or if it doesn't begin to dilute the focus of the working group. - Tim Dierks Tim Dierks -- timd@consensus.com -- www.consensus.com Head of Thing-u-ma-jig Engineering, Consensus Development From hsw@columbia.sparta.com Mon Apr 8 08:44:05 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id IAA01641 for ; Mon, 8 Apr 1996 08:44:04 -0400 Received: from columbia.sparta.com (bugs_bunny.columbia.SPARTA.COM) by www10.w3.org (5.0/NSCS-1.0S) id AA08937; Mon, 8 Apr 1996 08:43:57 +0500 Received: from katahdin.columbia.sparta.com by columbia.sparta.com (4.1/cfm-7-21-95) id AA10401; Mon, 8 Apr 96 08:43:36 EDT Received: by katahdin.columbia.sparta.com (5.61/SMI-4.1) id AA06044; Mon, 8 Apr 96 08:43:32 -0400 From: hsw@columbia.sparta.com (Howard Weiss) Message-Id: <9604081243.AA06044@katahdin.columbia.sparta.com> Subject: Re: Revised Draft Charter To: treese@openmarket.com (Win Treese) Date: Mon, 8 Apr 1996 08:43:30 -0400 (EDT) Cc: ietf-tls@w3.org In-Reply-To: <199604060630.BAA02321@caddo.openmarket.com> from "Win Treese" at Apr 6, 96 01:30:25 am Organization: SPARTA Inc. (Secure Systems Engineering Division) Usmail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046 Phone: (410) 381-9400 x201 Fax: (410) 381-5559 X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1211 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls > The work currently under way in the area of secure IP is outside the > scope of this working group. Also, general authentication mechanism > discussions are outside the focus of this group. However, best efforts > will be made to utilize as much as possible of the already existing > technologies and methodologies in the IETF and other places to solve > common problems, such as key management. ^^^^^^^^^^^^^^^^^^^^^^ Does this mean that the TLS group will make use of the IPSEC key management solution (whichever one that turns out to be)? In other words, where/how is key management for TLS going to be addressed within this working group? Howard Weiss ________________________________________________________________________ | | | Howard Weiss phone (410) 381-9400 x201 | | SPARTA, Inc. (301) 621-8145 x201 (DC)| | 9861 Broken Land Parkway, suite 300 fax: (410) 381-5559 | | Columbia, MD 21046 email: hsw@columbia.sparta.com| |________________________________________________________________________| From ChristopherA@consensus.com Mon Apr 8 21:43:45 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id VAA13424 for ; Mon, 8 Apr 1996 21:43:45 -0400 Received: from consensus.com (mail.consensus.com) by www10.w3.org (5.0/NSCS-1.0S) id AA13043; Mon, 8 Apr 1996 21:43:43 +0500 Received: from [157.22.240.12] by consensus.com with ESMTP (Apple Internet Mail Server 1.0); Mon, 8 Apr 1996 17:43:34 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Organization: Consensus Development Corporation Date: Mon, 8 Apr 1996 18:31:32 -0700 To: ietf-tls@w3.org From: Christopher Allen Subject: TLD Draft Charter & Proxies? content-length: 1492 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Does the scope of the TLS working group include interaction with firewalls and/or proxy servers? I think it should, as I think it will be difficult to have a generic (i.e. non-protocol based) solution to this problem. If scope includes this, it should be reflected in the draft charter. I suggest adding the following language in the change bars be added to the following paragraph of the draft: At 11:30 PM 4/5/96, Win Treese wrote: >Several methods of providing a secure and authenticated channel >between a client and a server on the Internet above the TCP layer have >appeared. The objective of this proposed working group is to write >standards track RFC(s) for protocols using the currently available >Internet drafts as a basis. The SSL, PCT and SSH protocols are >examples of mechanisms of establishing a secure channel for general >purpose or special purpose Internet applications running over a |reliable transport, usually TCP. In addition, this proposed working |group will address methods of providing secure channels through |firewalls, proxy servers or other reasonable intermediaries in the |connection. ------------------------------------------------------------------------ ..Christopher Allen Consensus Development Corporation.. .. 1563 Solano Avenue #355.. .. Berkeley, CA 94707-2116.. .. o510/559-1500 f510/559-1505.. From rodney@sabletech.com Tue Apr 9 11:59:31 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id LAA24553 for ; Tue, 9 Apr 1996 11:59:30 -0400 Received: from dg-webo.webo.dg.com (dg-webo.us.dg.com) by www10.w3.org (5.0/NSCS-1.0S) id AA16060; Tue, 9 Apr 1996 11:59:27 +0500 Received: from loki-onc by dg-webo.webo.dg.com (5.4R3.10/dg-webo-v1) id AA06892; Tue, 9 Apr 1996 11:59:17 -0400 Received: from ferguson (ferguson.webo.dg.com) by loki.webo.dg.com (1.00/2.1) id AA00099; Tue, 9 Apr 96 11:58:57 edt Message-Id: <9604091558.AA00099@loki.webo.dg.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 09 Apr 1996 11:59:14 -0400 To: ietf-tls@w3.org From: Rodney Thayer Subject: Re: Revised Draft Charter content-length: 2497 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls one would like to think the existing body of work on port mappers for the nfs world could be examined to address this (interesting/valid) concern. Any NFS types in the crowd? >Resent-Date: Mon, 8 Apr 1996 04:21:16 -0400 >Resent-Message-Id: <199604080821.EAA28421@www19.w3.org> >Date: Mon, 8 Apr 1996 01:17:15 -0700 >To: ietf-tls (Transport Layer Security WG) >From: timd@consensus.com (Tim Dierks) >Subject: Re: Revised Draft Charter >X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls >Resent-From: ietf-tls@w3.org >X-Mailing-List: archive/latest/22 >X-Loop: ietf-tls@w3.org >Sender: ietf-tls-request@w3.org >Resent-Sender: ietf-tls-request@w3.org > >At 1:30 AM 4/6/96, Win Treese wrote: >>The group may also produce an informational RFC to describe conventions for >>the interface to a Socket (or transport) layer secure library to build >>specific applications as well as TCP port number conventions for running >>secure versions of network applications. > >I'd like to see the group address issues surrounding disambiguating secure >sessions from insecure ones. For example, issues have been raised on the >SSL-talk list about whether using different port numbers is an appropriate >method of distinguishing protocols which are identical except for their use >(or lack thereof) of a secure transport layer. Given the limited number of >"trusted" port numbers (1024 or so), it seems that multiplying the number >of services by the number of possible transports might quickly lead to a >crisis. We should at least discuss methods of sharing ports between secure >and insecure sessions. > >I'd also like to discuss authentication requirements for secure transports >(i.e., should there be required attributes in X.509 certificates for TLS >which specify the IP address or DNS name of the host in question), but I'm >not certain if that isn't already covered by the charter or if it doesn't >begin to dilute the focus of the working group. > > - Tim Dierks > >Tim Dierks -- timd@consensus.com -- www.consensus.com >Head of Thing-u-ma-jig Engineering, Consensus Development > > > > Rodney Thayer :: rodney@sabletech.com Sable Technology Corp :: +1 617 332 7292 246 Walnut St :: Fax: +1 617 332 7970 Newton MA 02160 USA :: http://www.shore.net/~sable "Developers of communications software" From dpkemp@missi.ncsc.mil Wed Apr 10 13:19:14 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id NAA07539 for ; Wed, 10 Apr 1996 13:19:13 -0400 Received: from guardian.guard.ncsc.mil by www10.w3.org (5.0/NSCS-1.0S) id AA21392; Wed, 10 Apr 1996 13:19:12 +0500 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id NAA18150 for ; Wed, 10 Apr 1996 13:19:28 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma018148; Wed Apr 10 13:19:13 1996 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id NAA29168 for ; Wed, 10 Apr 1996 13:15:29 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id NAA06822; Wed, 10 Apr 1996 13:19:13 -0400 Date: Wed, 10 Apr 1996 13:19:13 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199604101719.NAA06822@argon.ncsc.mil> To: ietf-tls@w3.org Subject: Re: TLS Draft Charter? X-Sun-Charset: US-ASCII content-length: 4461 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls > From: Win Treese > > ... The SSL, PCT and SSH protocols are > examples of mechanisms of establishing a secure channel for general > purpose or special purpose Internet applications running over a > reliable transport, usually TCP. The SecureWare HannaH protocol (http://www.secureware.com/products/hanna/) is another example of a suitable mechanism, one which may have something to offer this group. I believe the SecureWare folks plan to participate here, but even if they don't, the above is good reading material. With regard to TCP, both HannaH and the newly-released PCT 2.0 spec address unreliable transport (UDP). I mildly believe that this WG should confine itself to reliable connection-oriented protocols and that UDP security should be provided by IPSEC technology. But either way, the charter should contain an explicit statement that datagram security is, or is not, a goal/requirement/appropriate-topic-of-discussion. > Goals and Milestones > > April 96 Agreement on charter and issues in current draft. > > July 96 Final draft for Secure Transport Layer Protocol ("STLP") > > Nov 96 Working group "Last Call" > > Dec 96 Offer to IESG for IETF "Last Call" I see a lot of handwaving between the April and July milestones :-). After all, we are dealing with three or four entrenched existing implementations, not writing a spec ab initio. It may be useful to write a "Requirements" document that defines the goals and non-goals in greater detail than can be done in the charter, against which the various proposals can be evaluated. > From: Rodney Thayer > > I think it is important to address the issue of migration from existing > protocols to the charter. Even if what ends up getting produced contains an > explicit claim it does not address migration. I do not think it should be > silently ignored. Agreed. The TLS candidate sponsors should provide some guidance to the WG as to how they intend to address migration. In the absense of such statements, the charter should include the explicit claim that it does not address migration. In any case, the result should be a single coherent STLP, not a mishmash framework that supports backward compatibility with everything that's out there now. > From: Christopher Allen > > Does the scope of the TLS working group include interaction with firewalls > and/or proxy servers? I think it should, as I think it will be difficult to > have a generic (i.e. non-protocol based) solution to this problem. > > If scope includes this, it should be reflected in the draft charter. Strongly agreed. One of the problems is defining exactly what controls proxies are expected to place on TLS connections: punch a hole to allow all traffic on specific ports? authenticate one or both endpoints? have access to the full encrypted record stream? (my suggestion is NO!, both, and no, respectively.) > From: timd@consensus.com (Tim Dierks) > > I'd like to see the group address issues surrounding disambiguating secure > sessions from insecure ones. For example, issues have been raised on the > SSL-talk list about whether using different port numbers is an appropriate > method of distinguishing protocols which are identical except for their use > (or lack thereof) of a secure transport layer. Given the limited number of > "trusted" port numbers (1024 or so), it seems that multiplying the number > of services by the number of possible transports might quickly lead to a > crisis. We should at least discuss methods of sharing ports between secure > and insecure sessions. Agreed. If it is technically feasible to support the distinction without disrupting existing TCP implementations, it should be done. (A browser should be able to connect to an existing, unmodified nntp server on port 119, somehow attempt to establish a secure connection, and if that fails fall back to a normal TCP connection. A TLS-modified nntp server on port 119 would be configurable to either fall back or refuse to connect to unmodified clients.) I believe that neither SSH nor HannaH use reserved ports, but I don't know if either of them interoperate with unmodified peers. Following the IETF principle of "rough consensus and working code", if none of the existing implementations interoperate with standard peers on standard port numbers, then that shouldn't be a requirement of this WG. Otherwise it should. From davismc@vnet.ibm.com Tue Apr 16 08:40:15 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id IAA08421 for ; Tue, 16 Apr 1996 08:40:15 -0400 Received: from VNET.IBM.COM by www10.w3.org (5.0/NSCS-1.0S) id AA15439; Tue, 16 Apr 1996 08:40:13 +0500 Message-Id: <9604161240.AA15439@www10.w3.org> Received: from RALVM12 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 9521; Tue, 16 Apr 96 08:39:28 EDT Date: Tue, 16 Apr 96 08:38:32 EDT From: "Mark C. Davis ((919)254-7865)" To: ietf-tls@w3.org Subject: STLP Dccument Source content-length: 134 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls According to InfoWeek Elec, the STLP document has been submitted to the IETF as a draft. Can somebody give me a URL? Thanks - Mark From paulh@imc.org Tue Apr 16 16:49:43 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id QAA13591 for ; Tue, 16 Apr 1996 16:49:43 -0400 Received: from imc.org by www10.w3.org (5.0/NSCS-1.0S) id AA17620; Tue, 16 Apr 1996 16:49:36 +0500 Received: from [165.227.113.247] (phoffman.sc.scruznet.com [165.227.113.247]) by imc.org (8.7.4/8.7.1) with ESMTP id NAA24540; Tue, 16 Apr 1996 13:46:52 -0700 (PDT) Message-Id: In-Reply-To: <9604161240.AA15439@www10.w3.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 Apr 1996 13:50:34 -0700 To: "Mark C. Davis ((919)254-7865)" , ietf-tls@w3.org From: Paul Hoffman Subject: Re: STLP Dccument Source content-length: 776 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls At 5:38 AM 4/16/96, Mark C. Davis ((919)254-7865) wrote: >According to InfoWeek Elec, the STLP document has been submitted to >the IETF as a draft. Can somebody give me a URL? This appears in the paper version of InfoWorld as well. The article starts off: Microsoft Corp. has submitted to the Internet Engineering Task Force a draft proposal for an encryption standard that combines Microsoft technology with that of its main Internet rival, Netscape Communications Corp. It starts with Netscape's Secure Sockets Layer 3.0 (SSL) and adds features from Microsoft's Private Communication Technology 2.0 (PCT), said a Microsoft spokesman. Is that spokesman/spokeswoman on this list? Or, can another Microsoft person describe what's up? I didn't see any draft come by yet... From dpkemp@missi.ncsc.mil Thu Apr 18 19:41:33 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id TAA23578 for ; Thu, 18 Apr 1996 19:41:33 -0400 Received: from guardian.guard.ncsc.mil by www10.w3.org (5.0/NSCS-1.0S) id AA28625; Thu, 18 Apr 1996 19:41:33 +0500 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id MAA02383; Tue, 16 Apr 1996 12:10:29 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id smaa02378; Tue Apr 16 12:10:13 1996 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id MAA11645; Tue, 16 Apr 1996 12:04:45 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id MAA10426; Tue, 16 Apr 1996 12:08:29 -0400 Date: Tue, 16 Apr 1996 12:08:29 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199604161608.MAA10426@argon.ncsc.mil> To: ietf-tls@w3.org Subject: Re: Merged Transport Layer Protocol Development X-Sun-Charset: US-ASCII content-length: 7770 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Here are some preliminary comments on: > Microsoft Strawman Proposal for a > Secure Transport Layer Protocol ("STLP") > > Discussion Draft 1.0 > April 8, 1996 > > [...] > To expedite this process, Microsoft and Netscape have agreed to start > face-to-face discussions with the objective of presenting a viable > draft proposal to the IETF working group at its next meeting in June. This is the best news I've heard all week! Ran Atkinson recently commented on the One Time Password working group: "PS: Its a credit to Neil and the WG members that the OTP WG is easily the most harmonious working group in the IETF since the late 1980s. Once upon a time, many working groups were as nice as OTP. In modern days, few are." The release of this discussion draft, and the agreement of the major participants to cooperate on the development of a proposal, bodes well for the prospects of this group to accomplish it's task in a similar spirit. > (1) There is no significant implementation cost for separate > negotiation of the message digest algorithm and the bulk cypher. In > fact, the code could be better if they were separate; instead of one > large table with a lot of repetition between entries there would be > two small tables with no repetition. Agreed. The message digest algorithm (hash function) is used in several places - the Message Authentication Code (MAC), derivation of keying material, certificate signatures, handshake finished message, etc. I don't see any need to bundle together the MAC hash function and the bulk cipher, and haven't seen any compelling arguments that unanalyzed combinations of MAC and bulk cipher might lead to cryptographic weakness. > (3) Provide a stronger error reportage. If a packet is refused, there > should be notification. The hardest thing in implementing SSL is > figuring out why some anonymous server refused your record. Also, it > is desirable to be able to explain to the user what the problem is. Agreed in principle, however I don't understand the specific proposal in this draft. Section 4 contains: struct { AlertLevel level; AlertDescription description; AlertDetails details<0..2>; } Alert; where AlertDetails is a set of bits that can be OR'ed together, and are used only with the handshake_failure and no_certificate AlertDescriptions. I see why details might contain 0 or 1 bytes, but not when it might contain 2 bytes. I also question the complication of adding a variable-length field; not only is it messier than a fixed-field structure, but it also requires more data to be transmitted on the wire (since the length must be sent). Instead, I propose that the Alert structure contain only the Level and Description fields, but that the details be incorporated into the description codes. It isn't obvious that anything is gained by being able to OR multiple detail codes - after all a fatal error is a fatal error, and one reason is sufficient: enum { close_notify(0), unexpected_message(10), bad_record_mac(20), decompression_failure(30), cipher_mismatch(40), hash_mismatch(41), exchange_mismatch(42), signature_mismatch(43), authentication_mismatch(44), illegal_parameter(45), bad_certificate(61), unsupported_certificate(62), certificate_revoked(63), certificate_expired(64), certificate_unknown(65), certificate_mismatch(66), certifier_mismatch(67), combination_mismatch(68), (255) } AlertDescription; > > (6) Password authentication (particularly for clients) is extremely > desirable. Right now, it has to be done at an application protocol > level (and differently for every protocol). Having part of > authentication occur at the SSL level and part at the application > protocol level is not desirable. No. Password "authentication" is not an acceptable means of establishing a secure connection. It may be acceptable at the application layer, for example to control access to particular portions of a html document tree. In that case, the basic authentication or digest authentication occur at the application layer, independently of whether transport layer security is being used. I don't agree that that layering scheme is "not desirable". Normally, protocol definitions should provide mechanisms, and configuration options should be the means of enforcing policy. However if the STLP is defined in such a way as to allow weak authentication, it will not be meeting it's goals. As stated in the SSL spec, goal number 1 is cryptographic security. I hope most TLS working group members agree with that. I strongly recommend that STLP contain no provisions for password authentication. > (8) MD2 and MD4 need to be phased out owing to the detection of a > security problem. SHA is recommended. Agree. > (9) There is real value in a secure datagram, particularly for > broadcast and multicast purposes. If UDP can be done without excessively complicating the STLP, then fine. I'd like to see more details, though. Are you proposing that handshake be done over a reliable connection and only support application-data datagrams, or do you envision handshake / alert / change-cipherspec over UDP? If the former, what mechanism is used to get the client and server to switch from TCP to UDP and back? If the latter, how do you propose handling lost/reordered/duplicate packets? The ipsec work seems more suited to providing datagram security. There is a real need, but I'm not sure STLP is the right vehicle. As mentioned before on the TLS mail list, it would also be nice if the STLP proposal would address: (11) Operation over normal port numbers, instead of special duplicate reserved ports for each application protocol (http, smtp, nntp, telnet, etc). (12) Providing sufficient information to allow firewall proxies to authenticate the client and server and enforce access control. > > 2. Changes from SSL version 3.0 > > The changes made to SSL version 3.0 to produce STLP can be summarized > as follows: > > [...] > > * UNIX time is removed from the random challenges, to preserve sources > of randomness. NO! When random numbers are used as secrets, the property of interest is "randomness" (unpredictability or entropy). However, both the client- and server-generated challenges are exchanged in the clear, and once they are known, they are no longer unpredictable. Thus "preserving randomness" is a non-goal for challenges. Instead, the useful property of challenges is that they not repeat over the lifetime of the key pair (certificate) with which they are used. A truly random N bit number has a small but non-zero probability of repeating any particular value. A challenge with a deterministic component such as time or a sequence number has a zero probability of repeating, as long as the sequential component is reliable. But it is nearly impossible to guarantee that reliability, so challenges should have both sequential and random components. > The connection state includes the following elements: > > Each party maintains separate sequence numbers for transmitted and > received messages for each connection. When a party sends or receives a > change cipher spec message, the appropriate sequence number is set to > zero. Sequence numbers are of type uint32 and may not exceed 2^32-1. Since sequence numbers are not transmitted, there is no reason to skimp on their size. SSLv3 uses uint64 sequence numbers; I don't see why STLP should use less even if current applications aren't likely to overflow a uint32. The world is full of examples of "unreachable" limits which were later found to be inadequate. (640K comes to mind :-) From tomste@microsoft.com Fri Apr 19 17:32:54 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id RAA05468 for ; Fri, 19 Apr 1996 17:32:53 -0400 Received: from tide19.microsoft.com (tide19.itg.microsoft.com) by www10.w3.org (5.0/NSCS-1.0S) id AA02926; Fri, 19 Apr 1996 17:32:52 +0500 Received: by tide19.microsoft.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB2DFD.0BA921B0@tide19.microsoft.com>; Fri, 19 Apr 1996 14:32:32 -0700 Message-Id: From: Tom Stephens To: "'ietf-tls@w3.org'" Subject: RE: Merged Transport Layer Protocol Development Date: Fri, 19 Apr 1996 13:57:22 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit content-length: 8610 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls David made some excellent points regarding STLP. These points and others will be discussed in some detail on tls-draft@w3.org - as that is the alias for discussion of the STLP strawman document. If you are not a member of that alias, I would strongly encourage you to join and >participate in the discussion. To join the tls-draft alias, send an >mail to tls-draft-request@w3.org with the word "subscribe" in the subject line. Tom Stephens >---------- >From: dpkemp@missi.ncsc.mil[SMTP:dpkemp@missi.ncsc.mil] >Sent: Tuesday, April 16, 1996 9:08 AM >To: ietf-tls@w3.org >Subject: Re: Merged Transport Layer Protocol Development > >Here are some preliminary comments on: > >> Microsoft Strawman Proposal for a >> Secure Transport Layer Protocol ("STLP") >> >> Discussion Draft 1.0 >> April 8, 1996 >> >> [...] >> To expedite this process, Microsoft and Netscape have agreed to start >> face-to-face discussions with the objective of presenting a viable >> draft proposal to the IETF working group at its next meeting in June. > >This is the best news I've heard all week! Ran Atkinson recently >commented on the One Time Password working group: > > "PS: Its a credit to Neil and the WG members that the OTP WG is easily >the > most harmonious working group in the IETF since the late 1980s. Once > upon a time, many working groups were as nice as OTP. In modern >days, > few are." > >The release of this discussion draft, and the agreement of the major >participants to cooperate on the development of a proposal, bodes well >for the prospects of this group to accomplish it's task in a similar >spirit. > > >> (1) There is no significant implementation cost for separate >> negotiation of the message digest algorithm and the bulk cypher. In >> fact, the code could be better if they were separate; instead of one >> large table with a lot of repetition between entries there would be >> two small tables with no repetition. > >Agreed. The message digest algorithm (hash function) is used in >several >places - the Message Authentication Code (MAC), derivation of keying >material, certificate signatures, handshake finished message, etc. >I don't see any need to bundle together the MAC hash function and the >bulk cipher, and haven't seen any compelling arguments that unanalyzed >combinations of MAC and bulk cipher might lead to cryptographic >weakness. > > >> (3) Provide a stronger error reportage. If a packet is refused, there >> should be notification. The hardest thing in implementing SSL is >> figuring out why some anonymous server refused your record. Also, it >> is desirable to be able to explain to the user what the problem is. > >Agreed in principle, however I don't understand the specific proposal >in this draft. Section 4 contains: > > struct { > AlertLevel level; > AlertDescription description; > AlertDetails details<0..2>; > } Alert; > >where AlertDetails is a set of bits that can be OR'ed together, and are >used only with the handshake_failure and no_certificate >AlertDescriptions. > >I see why details might contain 0 or 1 bytes, but not when it >might contain 2 bytes. I also question the complication of adding a >variable-length field; not only is it messier than a fixed-field >structure, >but it also requires more data to be transmitted on the wire (since >the length must be sent). > >Instead, I propose that the Alert structure contain only the Level and >Description fields, but that the details be incorporated into the >description codes. It isn't obvious that anything is gained by being >able to OR multiple detail codes - after all a fatal error is a fatal >error, and one reason is sufficient: > > enum { > close_notify(0), > unexpected_message(10), > bad_record_mac(20), > decompression_failure(30), > cipher_mismatch(40), hash_mismatch(41), exchange_mismatch(42), > signature_mismatch(43), authentication_mismatch(44), > illegal_parameter(45), > bad_certificate(61), unsupported_certificate(62), > certificate_revoked(63), certificate_expired(64), > certificate_unknown(65), certificate_mismatch(66), > certifier_mismatch(67), combination_mismatch(68), > (255) > } AlertDescription; > > >> >> (6) Password authentication (particularly for clients) is extremely >> desirable. Right now, it has to be done at an application protocol >> level (and differently for every protocol). Having part of >> authentication occur at the SSL level and part at the application >> protocol level is not desirable. > >No. Password "authentication" is not an acceptable means of >establishing >a secure connection. It may be acceptable at the application layer, >for example to control access to particular portions of a html document >tree. In that case, the basic authentication or digest authentication >occur at the application layer, independently of whether transport >layer >security is being used. I don't agree that that layering scheme is >"not desirable". > >Normally, protocol definitions should provide mechanisms, and >configuration >options should be the means of enforcing policy. However if the STLP >is defined in such a way as to allow weak authentication, it will not >be meeting it's goals. As stated in the SSL spec, goal number 1 is >cryptographic security. I hope most TLS working group members agree >with that. > >I strongly recommend that STLP contain no provisions for password >authentication. > > >> (8) MD2 and MD4 need to be phased out owing to the detection of a >> security problem. SHA is recommended. > >Agree. > > >> (9) There is real value in a secure datagram, particularly for >> broadcast and multicast purposes. > >If UDP can be done without excessively complicating the STLP, then >fine. I'd like to see more details, though. Are you proposing that >handshake be done over a reliable connection and only support >application-data datagrams, or do you envision handshake / alert / >change-cipherspec over UDP? If the former, what mechanism is used >to get the client and server to switch from TCP to UDP and back? >If the latter, how do you propose handling lost/reordered/duplicate >packets? > >The ipsec work seems more suited to providing datagram security. >There is a real need, but I'm not sure STLP is the right vehicle. > > >As mentioned before on the TLS mail list, it would also be nice if >the STLP proposal would address: > > (11) Operation over normal port numbers, instead of special duplicate >reserved ports for each application protocol (http, smtp, nntp, telnet, >etc). > > (12) Providing sufficient information to allow firewall proxies to >authenticate the client and server and enforce access control. > > >> >> 2. Changes from SSL version 3.0 >> >> The changes made to SSL version 3.0 to produce STLP can be summarized >> as follows: >> >> [...] >> >> * UNIX time is removed from the random challenges, to preserve sources >> of randomness. > >NO! When random numbers are used as secrets, the property of interest >is "randomness" (unpredictability or entropy). However, both the >client- >and server-generated challenges are exchanged in the clear, and once >they >are known, they are no longer unpredictable. Thus "preserving >randomness" >is a non-goal for challenges. > >Instead, the useful property of challenges is that they not repeat over >the lifetime of the key pair (certificate) with which they are used. >A truly random N bit number has a small but non-zero probability >of repeating any particular value. A challenge with a deterministic >component such as time or a sequence number has a zero probability of >repeating, as long as the sequential component is reliable. But it is >nearly impossible to guarantee that reliability, so challenges should >have both sequential and random components. > > > >> The connection state includes the following elements: >> >> Each party maintains separate sequence numbers for transmitted and >> received messages for each connection. When a party sends or receives a >> change cipher spec message, the appropriate sequence number is set to >> zero. Sequence numbers are of type uint32 and may not exceed 2^32-1. > >Since sequence numbers are not transmitted, there is no reason to >skimp on their size. SSLv3 uses uint64 sequence numbers; I don't see >why STLP should use less even if current applications aren't likely >to overflow a uint32. The world is full of examples of "unreachable" >limits which were later found to be inadequate. (640K comes to mind >:-) > > From dmk@allegra.att.com Fri Apr 19 18:09:05 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id SAA06290 for ; Fri, 19 Apr 1996 18:09:04 -0400 Received: from research.att.com (ns.research.att.com) by www10.w3.org (5.0/NSCS-1.0S) id AA03116; Fri, 19 Apr 1996 18:09:03 +0500 Received: from research.att.com by ns; Fri Apr 19 18:07:18 EDT 1996 Received: from allegra.tempo.att.com by research; Fri Apr 19 18:05:55 EDT 1996 Received: from aleatory.tempo.att.com by allegra.tempo.att.com; id AA29524; Fri, 19 Apr 96 18:05:54 EDT Received: by aleatory.tempo.att.com; id AA27492; Fri, 19 Apr 96 18:05:44 EDT Date: Fri, 19 Apr 96 18:05:44 EDT From: dmk@allegra.att.com (Dave Kristol) Message-Id: <9604192205.AA27492@aleatory.tempo.att.com> To: ietf-tls@w3.org Subject: RE: Merged Transport Layer Protocol Development content-length: 750 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls A procedural question... Tom Stephens wrote: > David made some excellent points regarding STLP. These points and > others will be discussed in some detail on tls-draft@w3.org - as that is > the alias for discussion of the STLP strawman document. If you are not > a member of that alias, I would strongly encourage you to join and > >participate in the discussion. To join the tls-draft alias, send an > >mail to tls-draft-request@w3.org with the word "subscribe" in the > subject line. Why is there yet another mailing list? If ietf-tls is meant to discuss standards track work, and if STLP is a step toward a standard, why create a separate mailing list to discuss it? Why not use ietf-tls? Dave Kristol From tomw@netscape.com Fri Apr 19 18:12:08 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id SAA06329 for ; Fri, 19 Apr 1996 18:12:07 -0400 Received: from urchin.netscape.com (h-198-95-250-59.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA03153; Fri, 19 Apr 1996 18:12:05 +0500 Received: from ammodump (ammodump.mcom.com [205.217.232.97]) by urchin.netscape.com (8.6.12/8.6.9) with SMTP id PAA06129 for ; Fri, 19 Apr 1996 15:12:41 -0700 Sender: tomw@netscape.com Message-Id: <31780FA4.41C6@netscape.com> Date: Fri, 19 Apr 1996 15:11:48 -0700 From: Tom Weinstein Organization: Netscape Communications, Inc. X-Mailer: Mozilla 3.0b3 (X11; U; IRIX 5.3 IP22) Mime-Version: 1.0 To: ietf-tls@w3.org Subject: Re: Merged Transport Layer Protocol Development References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 811 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Tom Stephens wrote: > > David made some excellent points regarding STLP. These points and > others will be discussed in some detail on tls-draft@w3.org - as that > is the alias for discussion of the STLP strawman document. If you > are not a member of that alias, I would strongly encourage you to > join and participate in the discussion. To join the tls-draft alias, > send an mail to tls-draft-request@w3.org with the word "subscribe" in > the subject line. > > Tom Stephens Why is there a need for another mailing list? The ietf-tls mailing list already exists. If the STLP strawman document is to be seriously considered, shouldn't it be discussed here? -- Sure we spend a lot of money, but that doesn't mean | Tom Weinstein we *do* anything. -- Washington DC motto | tomw@netscape.com From ericm@lne.com Fri Apr 19 18:18:22 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id SAA06534 for ; Fri, 19 Apr 1996 18:18:21 -0400 Received: from slack.lne.com by www10.w3.org (5.0/NSCS-1.0S) id AA03198; Fri, 19 Apr 1996 18:18:17 +0500 Received: (from ericm@localhost) by slack.lne.com (8.7.1/1.0) id PAA18739; Fri, 19 Apr 1996 15:18:10 -0700 From: Eric Murray Message-Id: <199604192218.PAA18739@slack.lne.com> Subject: Re: Merged Transport Layer Protocol Development To: tomste@microsoft.com (Tom Stephens) Date: Fri, 19 Apr 1996 15:18:08 -0700 (PDT) Cc: ietf-tls@w3.org In-Reply-To: from "Tom Stephens" at Apr 19, 96 01:57:22 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit content-length: 957 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Tom Stephens writes: > > David made some excellent points regarding STLP. These points and > others will be discussed in some detail on tls-draft@w3.org - as that is > the alias for discussion of the STLP strawman document. If you are not > a member of that alias, I would strongly encourage you to join and > >participate in the discussion. To join the tls-draft alias, send an > >mail to tls-draft-request@w3.org with the word "subscribe" in the > subject line. Perhaps I don't understand IETF procedure, but I am puzzled as to why there is now a second mailing list. It's not like the original TLS list is getting too much traffic. In fact, it's not getting enough traffic... for one, I can't find any reference to any mail that included the URL for the STLP "strawman". Where is it? -- Eric Murray ericm@lne.com ericm@motorcycle.com http://www.lne.com/ericm PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03 92 E8 AC E6 7E 27 29 AF From tomste@microsoft.com Fri Apr 19 22:57:53 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id WAA09102; Fri, 19 Apr 1996 22:57:52 -0400 Received: from tide19.microsoft.com (tide19.itg.microsoft.com) by www10.w3.org (5.0/NSCS-1.0S) id AA03955; Fri, 19 Apr 1996 22:57:52 +0500 Received: by tide19.microsoft.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB2E2A.8A2ADE70@tide19.microsoft.com>; Fri, 19 Apr 1996 19:58:12 -0700 Message-Id: From: Tom Stephens To: "'ietf-tls@w3.org'" Cc: "'tls-draft@w3.org'" Subject: RE: Merged Transport Layer Protocol Development Date: Fri, 19 Apr 1996 19:32:07 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit content-length: 1789 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Tls-draft was created specifically as a forum for the discussion of the Microsoft STLP strawman document. The reason for this is that the STLP strawman document is not an official IETF document. Win Treese, Microsoft and Netscape did not want this document to be confused in any way with the actual spec that is being developed by the working group. However, since the consensus of the emails is to discuss the STLP strawman document on ietf-tls, then Microsoft does not object. To facilitate the discussion, you can find the STLP strawman document at: http://pct.microsoft.com/stlp. Tom Stephens >---------- >From: Eric Murray[SMTP:ericm@lne.com] >Sent: Friday, April 19, 1996 3:18 PM >To: Tom Stephens >Cc: ietf-tls@w3.org >Subject: Re: Merged Transport Layer Protocol Development > >Tom Stephens writes: >> >> David made some excellent points regarding STLP. These points and >> others will be discussed in some detail on tls-draft@w3.org - as that is >> the alias for discussion of the STLP strawman document. If you are not >> a member of that alias, I would strongly encourage you to join and >> >participate in the discussion. To join the tls-draft alias, send an >> >mail to tls-draft-request@w3.org with the word "subscribe" in the >> subject line. > >Perhaps I don't understand IETF procedure, but I am puzzled as to why >there is now a second mailing list. It's not like the original >TLS list is getting too much traffic. > >In fact, it's not getting enough traffic... for one, I can't find any >reference to any mail that included the URL for the STLP "strawman". > >Where is it? > > > >-- >Eric Murray ericm@lne.com ericm@motorcycle.com >http://www.lne.com/ericm >PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03 92 E8 AC E6 7E >27 29 AF > > From sanders_james@tandem.com Mon Apr 22 10:52:37 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id KAA05248; Mon, 22 Apr 1996 10:52:37 -0400 Received: from suntan.tandem.com by www10.w3.org (5.0/NSCS-1.0S) id AA15590; Mon, 22 Apr 1996 10:52:36 +0500 Received: from adm.loc201.tandem.com by suntan.tandem.com (8.6.12/suntan5.960119) id HAA13608; Mon, 22 Apr 1996 07:52:34 -0700 Received: from [130.252.143.82] (clr4-2.mis.tandem.com) by adm.loc201.tandem.com (4.1/6main.940209) id AA02902; Mon, 22 Apr 96 07:52:29 PDT X-Sender: sanders_james\comm@igate.cup.tandem.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Apr 1996 07:53:16 -0700 To: tomste@microsoft.com From: sanders_james@tandem.com (Jim Sanders) Subject: Re: Status (if any) of STLP? Cc: ietf-tls@w3.org, tls-draft@w3.org content-length: 1765 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls On Friday 4/19, at 8:24 PM, Tom Stephens wrote: >Tls-draft was created specifically as a forum for the discussion of the >Microsoft STLP strawman document. The reason for this is that the STLP >strawman document is not an official IETF document. Win Treese, >Microsoft and Netscape did not want this document to be confused in any >way with the actual spec that is being developed by the working group. > >However, since the consensus of the emails is to discuss the STLP >strawman document on ietf-tls, then Microsoft does not object. To >facilitate the discussion, you can find the STLP strawman document at: > >http://pct.microsoft.com/stlp. >> >Tom Stephens >--------------------------------- Tom, could you or Win Treese tell us exactly what is going on? I was there in LA on March 6 evening meeting, and this (recent unilateral release by Microsoft of a document of unknown status to an unknown enitity) does not feel like the intentions I heard expressed at that time. If Microsoft released a unilateral draft, to whom did you release it? If it was to the IETF, but is "not an official IETF document," what status does it have? Most of all, if the working group is still working on an "actual spec," what purpose is served by this unilateral STLP document? These (apparently sub rosa) machinations do not inspire confidence in the integrity of the original commitments (surprising as they were) to work out a unified protocol. The rest of the industry needs to have confidence in this process. --Jim Sanders-- "Speaking for myself, not necessarily for my employer." << Jim Sanders, Staff Scientist, Transaction Security >> << Network Applications Services, Tandem Computers >> << Voice: 408-285-492; E-mail: sanders_james@tandem.com )) From tomste@microsoft.com Mon Apr 22 11:55:01 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id LAA17834; Mon, 22 Apr 1996 11:55:00 -0400 Received: from tide21.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA16611; Mon, 22 Apr 1996 11:54:59 +0500 Received: by tide21.microsoft.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB3029.6D541540@tide21.microsoft.com>; Mon, 22 Apr 1996 08:55:16 -0700 Message-Id: From: Tom Stephens To: "'sanders_james@tandem.com'" Cc: "'ietf-tls@w3.org'" , "'tls-draft@w3.org'" Subject: RE: Status (if any) of STLP? Date: Mon, 22 Apr 1996 08:54:53 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit content-length: 2612 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Jim, Win Treese and representatives from Microsoft and Netscape met a couple of weeks ago to begin hammering out some of the components for the foundation of a spec. At that meeting, Microsoft precented our STLP strawman document. That document was an experiment by Microsoft to determine how well SSL and PCT could be merged into one protocol - using SSL as a base and adding PCT deltas. Our goal was to deal with the differences Microsoft and Netscape quickly so that the normal IETF process would move forward without any detractions from either Microsoft or Netscape. Tom >---------- >From: sanders_james@tandem.com[SMTP:sanders_james@tandem.com] >Sent: Monday, April 22, 1996 7:53 AM >To: Tom Stephens >Cc: ietf-tls@w3.org; tls-draft@w3.org >Subject: Re: Status (if any) of STLP? > >On Friday 4/19, at 8:24 PM, Tom Stephens wrote: > >>Tls-draft was created specifically as a forum for the discussion of the >>Microsoft STLP strawman document. The reason for this is that the STLP >>strawman document is not an official IETF document. Win Treese, >>Microsoft and Netscape did not want this document to be confused in any >>way with the actual spec that is being developed by the working group. >> >>However, since the consensus of the emails is to discuss the STLP >>strawman document on ietf-tls, then Microsoft does not object. To >>facilitate the discussion, you can find the STLP strawman document at: >> >>http://pct.microsoft.com/stlp. >>> >>Tom Stephens >>--------------------------------- >Tom, could you or Win Treese tell us exactly what is going on? I was >there >in LA on March 6 evening meeting, and this (recent unilateral release >by >Microsoft of a document of unknown status to an unknown enitity) does >not >feel like the intentions I heard expressed at that time. If Microsoft >released a unilateral draft, to whom did you release it? If it was to >the >IETF, but is "not an official IETF document," what status does it have? >Most of all, if the working group is still working on an "actual spec," >what purpose is served by this unilateral STLP document? > >These (apparently sub rosa) machinations do not inspire confidence in >the >integrity of the original commitments (surprising as they were) to work >out >a unified protocol. The rest of the industry needs to have confidence >in >this process. > >--Jim Sanders-- >"Speaking for myself, not necessarily for my employer." > ><< Jim Sanders, Staff Scientist, Transaction Security >> ><< Network Applications Services, Tandem Computers >> ><< Voice: 408-285-492; E-mail: sanders_james@tandem.com )) > > > From sanders_james@tandem.com Mon Apr 22 13:34:47 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id NAA00406; Mon, 22 Apr 1996 13:34:46 -0400 Received: from suntan.tandem.com by www10.w3.org (5.0/NSCS-1.0S) id AA00404; Mon, 22 Apr 1996 13:34:45 +0500 Received: from adm.loc201.tandem.com by suntan.tandem.com (8.6.12/suntan5.960119) id KAA29800; Mon, 22 Apr 1996 10:34:44 -0700 Received: from [130.252.143.104] (clr6-4.mis.tandem.com) by adm.loc201.tandem.com (4.1/6main.940209) id AA07716; Mon, 22 Apr 96 10:34:35 PDT X-Sender: sanders_james\comm@igate.cup.tandem.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Apr 1996 09:39:46 -0800 To: tomste@microsoft.com From: sanders_james@tandem.com (Jim Sanders) Subject: RE: Status (if any) of STLP? Cc: ietf-tls@w3.org, tls-draft@w3.org content-length: 1600 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls >Jim, > >Win Treese and representatives from Microsoft and Netscape met a couple >of weeks ago to begin hammering out some of the components for the >foundation of a spec. At that meeting, Microsoft precented our STLP >strawman document. That document was an experiment by Microsoft to >determine how well SSL and PCT could be merged into one protocol - using >SSL as a base and adding PCT deltas. Our goal was to deal with the >differences Microsoft and Netscape quickly so that the normal IETF >process would move forward without any detractions from either Microsoft >or Netscape. > >Tom ----------------------------- Thanks Tom, I have no dispute with the events you describe, but process integrity would have been better served if you or Win had described this intent up front, and answered the queries by other folks who, like me, could not figure out what was going on. This was especialy true in light of the press reports of "Draft submitted to IETF." I believe that what you are saying is that no draft was "submitted," but rather "made available for review," albeit with rather late instructions as to location and ownership. All the above reflects my personal belief that this particular BOF-cum-WG should stretch to maintain the status of "Caesar's wife;" and also reflects my concern at the questions being raised by others last week. Thanks again for your prompt response. --Jim-- << Jim Sanders, Staff Scientist - Transaction Security >> << Network Application Services, Tandem Computers >> << Voice: 408-285-4192; E-mail: sanders_james@tandem.com >> From tomste@microsoft.com Mon Apr 22 15:22:35 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id PAA01439; Mon, 22 Apr 1996 15:22:35 -0400 Received: from tide19.microsoft.com (tide19.itg.microsoft.com) by www10.w3.org (5.0/NSCS-1.0S) id AA00895; Mon, 22 Apr 1996 15:22:33 +0500 Received: by tide19.microsoft.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB3046.79454F50@tide19.microsoft.com>; Mon, 22 Apr 1996 12:23:12 -0700 Message-Id: From: Tom Stephens To: "'sanders_james@tandem.com'" Cc: "'ietf-tls@w3.org'" , "'tls-draft@w3.org'" Subject: RE: Status (if any) of STLP? Date: Mon, 22 Apr 1996 12:10:54 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit content-length: 2108 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Jim, As you pointed out, there has been some confusion over this issue. It was unfortunate that the strawman document was labeled as a draft in the press and by others. That was never our intention. For that confusion, we apologize. Tom >---------- >From: sanders_james@tandem.com[SMTP:sanders_james@tandem.com] >Sent: Monday, April 22, 1996 10:39 AM >To: Tom Stephens >Cc: ietf-tls@w3.org; tls-draft@w3.org >Subject: RE: Status (if any) of STLP? > >>Jim, >> >>Win Treese and representatives from Microsoft and Netscape met a couple >>of weeks ago to begin hammering out some of the components for the >>foundation of a spec. At that meeting, Microsoft precented our STLP >>strawman document. That document was an experiment by Microsoft to >>determine how well SSL and PCT could be merged into one protocol - using >>SSL as a base and adding PCT deltas. Our goal was to deal with the >>differences Microsoft and Netscape quickly so that the normal IETF >>process would move forward without any detractions from either Microsoft >>or Netscape. >> >>Tom >----------------------------- >Thanks Tom, > >I have no dispute with the events you describe, but process integrity >would >have been better served if you or Win had described this intent up >front, >and answered the queries by other folks who, like me, could not figure >out >what was going on. This was especialy true in light of the press >reports of >"Draft submitted to IETF." I believe that what you are saying is that >no draft >was "submitted," but rather "made available for review," albeit with >rather late >instructions as to location and ownership. > >All the above reflects my personal belief that this particular >BOF-cum-WG >should stretch to maintain the status of "Caesar's wife;" and also >reflects >my concern at the questions being raised by others last week. > >Thanks again for your prompt response. >--Jim-- > ><< Jim Sanders, Staff Scientist - Transaction Security >> ><< Network Application Services, Tandem Computers >> ><< Voice: 408-285-4192; E-mail: sanders_james@tandem.com >> > > > From dpkemp@missi.ncsc.mil Mon Apr 22 16:32:22 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id QAA02135 for ; Mon, 22 Apr 1996 16:32:22 -0400 Received: from guardian.guard.ncsc.mil ([144.51.52.1]) by www10.w3.org (5.0/NSCS-1.0S) id AA01196; Mon, 22 Apr 1996 16:32:10 +0500 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id QAA16269 for ; Mon, 22 Apr 1996 16:31:55 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma016267; Mon Apr 22 16:31:29 1996 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id QAA24268 for ; Mon, 22 Apr 1996 16:27:45 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id QAA16798; Mon, 22 Apr 1996 16:31:26 -0400 Date: Mon, 22 Apr 1996 16:31:26 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199604222031.QAA16798@argon.ncsc.mil> To: ietf-tls@w3.org Subject: Re: Merged Transport Layer Protocol Development X-Sun-Charset: US-ASCII content-length: 5522 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls There has indeed been some unfortunate confusion surrounding the discussion paper, but it's difficult to comprehend some of the ideas being bandied about lately - "sub-rosa" dealings, a Netscape-Microsoft conspiracy to bypass the IETF ?!?, etc. As I see it, two mistakes were made: 1 - the creation of two mailing lists, ietf-tls@w3.org and tls-draft@w3.org, when one would have been sufficient 2 - the discussion paper was widely distributed both by hardcopy and email to people who had previously commented on either SSL or PCT, but was not posted to either of the above lists nor to the SSL or PCT lists. Tom Stephens has addressed both of these: > To: "'ietf-tls@w3.org'" > Date: Fri, 19 Apr 1996 19:32:07 -0700 > > However, since the consensus of the emails is to discuss the STLP > strawman document on ietf-tls, then Microsoft does not object. To > facilitate the discussion, you can find the STLP strawman document at: > > http://pct.microsoft.com/stlp. But to further dispel any Watergate-type speculation ("What did he know and when did he know it?"), here is the cover letter I received with the original stlp paper. The tone of the letter is clearly inclusive, and may help to clear up any lingering misunderstandings. My only criticism of this working group is that the chairman has not yet taken an active role in moderating the discussion. Perhaps that will change soon. ----- Begin Included Message ----- From tomste@microsoft.com Fri Apr 12 20:11:57 1996 From: Tom Stephens To: "'dpkemp@missi.ncsc.mil'" Subject: Merged Transport Layer Protocol Development Date: Fri, 12 Apr 1996 17:11:02 -0700 >Your input is needed for the creation of a new open transport-layer >security protocol! > >Via the IETF, Microsoft and Netscape are working together to converge >on a single open transport-layer security protocol, using the existing >protocols (SSL, PCT, SSH - Secure Shell Remote Login) as a base. We're >happy to be involved in this because we believe a single, open >specification will benefit both developers and users. > >We're committed to making this convergence happen as quickly as >possible, through the IETF process. To help things move as quickly as >possible, Microsoft has written a discussion draft called STLP (Secure >Transport Layer Protocol). The discussion draft is not a spec suitable >for implementation; it's a starting point for a converged >specification. > >This draft starts with Netscape's SSL 3.0 and adds features from >Microsoft's PCT 2.0 based on feedback from cryptographers and >implementers. It is intended to provide a simpler and more robust >implementation, additional scalability, improved security and the >additional functionality needed for wider application of the >specification. We're sending this draft to Netscape and to the firms >who provided substantial input to SSL and to PCT. > >When the converged spec is finished, Microsoft will develop and >distribute no-charge reference and object code versions which implement >the converged spec. > >W3C has created two list servers to foster the STLP development: > >ietf-tls@w3.org >Ietf-tls@w3.org provides support for the Transport Layer Protocol >Working Group. To become a member of ietf-tls@w3.org, email >ietf-tls@request@w3.org with the word "subscribe" in the subject line. > > >tls-draft@w3.org >Tls-draft@w3.org was specifically created to foster discussion about >the development of a new transport layer protocol. The current plan >calls for a draft document to be presented at the IETF Montreal Conference in June. As a result, the creation of a spec will move ahead >very quickly, so it is very important that you post to this alias >information about what you would like to see included in the new spec. >Please take the time to review the attached STLP document and post any >comments you might have regarding features, present or missing, that >you would like to see added to the new spec. To join tls-draft@w3.org, >send an mail to tls-draft-request@w3.org with the word "subscribe" in >the subject line. > >Please also take a look at the PCT 2.0 spec. It's available at >http://pct.microsoft.com. Comments on PCT 2.0 are also welcomed. > >Security and privacy are important. We're pleased to be working with >other industry players to deliver a single spec for scaleable transport >security with a broad range of functionality. > >Tom Stephens >Program Manager >Microsoft > >----------------------------------------------------------------- > >Secure Transport Layer Protocol discussion draft pertinent points: > >1. It's not a spec, it's a discussion draft -- a starting point. > >2. It uses SSL v3 as a base, and adds on top of that (mainly from PCT >v2) > >3. It suggests changes to the base protocol to make implementation >simpler and more >robust: e.g. stronger error reporting, uniform message headers, etc. > >4. Specific deltas from SSL v3 include: > - datagram support > - new keys and cipher specs allowed, supporting pre-encrypted data > - less long-term dependence on particular algorithms > - more information in alerts for robust error-handling > - improved handshaking, allows speed-up when the client has the >server's key > - additional authentication options, including previously shared >secrets >- full specification of cert types and names for both clients and >servers > [word and text attachments deleted - dpk] ----- End Included Message ----- From ericm@lne.com Mon Apr 22 21:40:23 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id VAA03899 for ; Mon, 22 Apr 1996 21:40:23 -0400 Received: from slack.lne.com by www10.w3.org (5.0/NSCS-1.0S) id AA02091; Mon, 22 Apr 1996 21:40:16 +0500 Received: (from ericm@localhost) by slack.lne.com (8.7.1/1.0) id SAA10768; Mon, 22 Apr 1996 18:40:03 -0700 From: Eric Murray Message-Id: <199604230140.SAA10768@slack.lne.com> Subject: Re: Merged Transport Layer Protocol Development To: dpkemp@missi.ncsc.mil (David P. Kemp) Date: Mon, 22 Apr 1996 18:40:02 -0700 (PDT) Cc: ietf-tls@w3.org In-Reply-To: <199604222031.QAA16798@argon.ncsc.mil> from "David P. Kemp" at Apr 22, 96 04:31:26 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit content-length: 1759 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls David P. Kemp writes: > > > There has indeed been some unfortunate confusion surrounding the > discussion paper, but it's difficult to comprehend some of the ideas > being bandied about lately - "sub-rosa" dealings, a Netscape-Microsoft > conspiracy to bypass the IETF ?!?, etc. I'm not sure anyone has said outright that there's some sort of consipracy, although many have noted that the recent events could be construed as evidence of one... > As I see it, two mistakes were made: > 1 - the creation of two mailing lists, ietf-tls@w3.org and tls-draft@w3.org, > when one would have been sufficient > 2 - the discussion paper was widely distributed both by hardcopy and > email to people who had previously commented on either SSL or PCT, > but was not posted to either of the above lists nor to the SSL > or PCT lists. The paper was _not_ very widely distributed- I was an early reviewer of SSL3 (my name's listed in the draft as such) yet I didn't receive a copy. Neither did anyone else I know who was a reviewer of SSL3. > But to further dispel any Watergate-type speculation ("What did he > know and when did he know it?") "Hey, there's 19 minutes of this crypto protocol spec that have been erased!" > My only criticism of this working group is that the chairman has > not yet taken an active role in moderating the discussion. Perhaps > that will change soon. I wish it would, and would like to politely suggest to the chairman that if he has time to conduct what should be working group business in private then he should make time to post some email about it. -- Eric Murray ericm@lne.com ericm@motorcycle.com http://www.lne.com/ericm PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03 92 E8 AC E6 7E 27 29 AF From bsy@work.ucsd.edu Tue Apr 23 00:33:03 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id AAA05073 for ; Tue, 23 Apr 1996 00:33:02 -0400 Received: from odin.ucsd.edu by www10.w3.org (5.0/NSCS-1.0S) id AA02568; Tue, 23 Apr 1996 00:33:00 +0500 Received: from work.ucsd.edu by odin.ucsd.edu; id AA17370 sendmail 8.73/UCSDPSEUDO.4-CS via SMTP Mon, 22 Apr 96 21:32:58 -0700 for ietf-tls@w3.org Received: from work.ucsd.edu (localhost [127.0.0.1]) by work.ucsd.edu (8.7.1/8.7.1) with ESMTP id VAA25435 for ; Mon, 22 Apr 1996 21:32:57 -0700 (PDT) Message-Id: <199604230432.VAA25435@work.ucsd.edu> To: ietf-tls@w3.org Reply-To: Bennet Yee Subject: Re: Merged Transport Layer Protocol Development Date: Mon, 22 Apr 1996 21:32:55 -0700 From: Bennet Yee content-length: 2077 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Rather than discuss conspiracy theories, how about getting back to the technical sides of TLS? One aspect that I particularly liked about PCTv2 that is absent from SSLv3 and the proposed merged protocol is the ability to handle pre-encrypted data. I believe that this is a very good way to amortize the bulk cryptography overhead over many sessions for some applications -- e.g., where images or text are being sold on a subscription/per-item basis and the service provider would like to make the data a little more secure so that network sniffers can not trivially obtain it. In such applications, reusing the same key for the data is not a big deal, in that (1) while it exposes the data-encrypting key a little more due to its being transferred to multiple recipients under different session keys, it is up to the server to determine the amount of this kind of exposure prior to re-encrypting the data with a fresh key, (2) malicious subscribers have the ability already to redistribute the data (or the key to the encrypted data, if the subscriber has the ability to extract it from his/her browser). When the server is willing to send the data only if it is possible to transmit it in encrypted form, there would be no extra storage overhead other than that for the bulk encryption key -- only the pre-encrypted copy of the data would be needed -- and for most transfers data may be streamed directly from the disk to the network interface. The same reasoning applies to pre-MAC'ing the data. I believe it is good to expose this encryption cost -vs- communication security tradeoff to the Web server administrators, and I believe that it is generally useful for other "data broadcast / publishing" applications. One problem with existing SSLv2 and PCTv1 Web servers is that the crypto overhead is sometimes unacceptably high, and this is one way to ameliorate this. -bsy -------- Bennet S. Yee Phone: +1 619 534 4614 Email: bsy@cs.ucsd.edu Web: http://www-cse.ucsd.edu/users/bsy/ USPS: Dept of Comp Sci and Eng, 0114, UC San Diego, La Jolla, CA 92093-0114 From bsy@work.ucsd.edu Tue Apr 23 01:39:13 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id BAA05323 for ; Tue, 23 Apr 1996 01:39:13 -0400 Received: from odin.ucsd.edu by www10.w3.org (5.0/NSCS-1.0S) id AA02700; Tue, 23 Apr 1996 01:39:11 +0500 Received: from work.ucsd.edu by odin.ucsd.edu; id AA19315 sendmail 8.73/UCSDPSEUDO.4-CS via SMTP Mon, 22 Apr 96 22:39:10 -0700 for ietf-tls@w3.org Received: from work.ucsd.edu (localhost [127.0.0.1]) by work.ucsd.edu (8.7.1/8.7.1) with ESMTP id WAA28161 for ; Mon, 22 Apr 1996 22:39:09 -0700 (PDT) Message-Id: <199604230539.WAA28161@work.ucsd.edu> To: ietf-tls@w3.org Reply-To: Bennet Yee Subject: Re: Merged Transport Layer Protocol Development In-Reply-To: Your message of "Mon, 22 Apr 1996 21:32:55 -0700." <199604230432.VAA25435@work.ucsd.edu> Date: Mon, 22 Apr 1996 22:39:07 -0700 From: Bennet Yee content-length: 330 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls I made a mistake. Efficiently handling pre-encrypted data -is- available in STLP; it is unavailable only in SSLv3. My apologies. -bsy -------- Bennet S. Yee Phone: +1 619 534 4614 Email: bsy@cs.ucsd.edu Web: http://www-cse.ucsd.edu/users/bsy/ USPS: Dept of Comp Sci and Eng, 0114, UC San Diego, La Jolla, CA 92093-0114 From elgamal@netscape.com Tue Apr 23 02:14:08 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id CAA05408 for ; Tue, 23 Apr 1996 02:14:08 -0400 Received: from urchin.netscape.com (h-198-95-250-59.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA02777; Tue, 23 Apr 1996 02:14:07 +0500 Received: from kingtut (loving176.mcom.com [205.217.240.176]) by urchin.netscape.com (8.6.12/8.6.9) with SMTP id XAA01508 for ; Mon, 22 Apr 1996 23:14:46 -0700 Message-Id: <317C743E.6950@netscape.com> Date: Mon, 22 Apr 1996 23:10:06 -0700 From: Taher Elgamal X-Mailer: Mozilla 2.01Gold (Win95; I) Mime-Version: 1.0 To: ietf-tls@w3.org Subject: STLP and proposal Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 2942 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls This is in response to the mailings and press announcements exchanged regarding the Microsoft proposed modifications to the SSL 3.0 specifications -- apparently referred to in the industry as "STLP". Microsoft has proposed to Netscape and to the chair of the proposed IETF TLS working group to produce a specification that is a "merge" between SSL 3.0 and PCT 2.0 and provide that combined specification document to the IETF as a starting draft to write a Secure Transport Layer Protocol (STLP) specification. The intent of the merged document is not as a proposed standard of any kind, it is provided just as a starting point so that the working group does not have to consider two different specifications. The document produced by Microsoft did not include any input from Netscape other than it is based completely on SSL 3.0 (without any hints from PCT). Microsoft suggested several modifications to the SSL3.0 spec that they considered to provide added value to the spec. It was interesting to see that the proposed "closed" discussion meeting appear in all magazines as the new Microsoft proposed STLP standard. Aside from that, all the recommended changes to the SSL 3.0 spec either cause possible security holes, are unrelated to securing transport layers or totally irrelevant. For example one of the recommended (by Microsoft) changes is to support datagrams (UDP) as well as TCP traffic. While having a secure version of UDP is a useful tool, it certainly does not belong at all to this discussion since the SSL protocol (and its variants including PCT) is designed assuming a reliable transport. Supporting UDP actually better belongs to the IP layer security efforts because of the "non-reliable" nature of the datagram delivery. There is also a request to change the signal called "ChangeCipherSpec" that determines the starting point of the new agreed upon algorithms to include other values, that actually has the potential of breaking the data stream since that signal is provided as a synchronization point between the client and the server to switch algorithms. There were several editorial changes to the front half of the document that made the document quite unreadable and therefore we did not finish analysing the proposed changes to th protocol. Since Microsoft decided to use the SSL3.0 protocol as the basis for new features, and for the sake of saving time, the TLS working group should review the SSL3.0 spec as the starting point for the TLS discussions, and since the IETF is truely an open forum, Micorsoft does have the opportunity of poposing any changes they see are advantageous to the funationality of the protocol. During the course of the coming several months all these changes and proposed changes from other interested parties will be looked at by the working group. -- Taher Elgamal elgamal@netscape.com Chief Scientist, Netscape Communications (T) 415 937 2898, (F) 415 428 4054 From treese@openmarket.com Tue Apr 23 11:01:19 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id LAA09106 for ; Tue, 23 Apr 1996 11:01:19 -0400 Received: from relay.openmarket.com by www10.w3.org (5.0/NSCS-1.0S) id AA04178; Tue, 23 Apr 1996 11:01:18 +0500 Received: from w4-8.openmarket.com (caddo2.openmarket.com [204.178.213.13]) by relay.openmarket.com (8.6.10/8.6.6) with SMTP id LAA22231 for ; Tue, 23 Apr 1996 11:01:16 -0400 Message-Id: <2.2.32.19960423145300.006ccdd4@OpenMarket.com> X-Sender: treese@OpenMarket.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 Apr 1996 10:53:00 -0400 To: ietf-tls@w3.org From: Win Treese Subject: what's going on content-length: 2043 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Apparently, taking a couple of days off from e-mail can be pretty risky. My apologies for the confusion that has arisen. On the whole, we're all talking about the same thing. Our goal is to reach a consensus on a protocol that fulfills the goals outlined in the draft charter. When trying to nail down a protocol, some off-list discussions among document authors or potential document authors can be useful in resolving some details. Some of those discussions inadvertently spilled into other arenas, causing many of us to be unsure of what was going on. Because the working group has an aggressive proposed schedule, and because some of the details to be resolved were minor and required some initial agreement, several people were trying to get some of those details nailed down quickly. That's all. The working group has not been constituted to rubber-stamp anything. On the other hand, there is great value in standardizing existing practice rather than trying to invent something from whole cloth. The goal of the working group is to agree on a transport layer security protocol as discussed in the charter. The important thing is that the working group comes to that consensus, and that everyone with an interest has an opportunity to contribute to that process. Document authors often need to have side conversations to work out details, and that's part of the usual process. Now that lots of documents are floating around, however, we (as a group) need to decide how to focus attention. I'll check with authors of the various documents and make a proposal in a couple of days so we aren't too diverted by different-but-similar documents. Finally, there were a few questions about details of the protocol we might come up with, but I got a general sense that the the last draft charter was acceptable to the group. If there are no objections to the charter as is in the next couple of days, I'll forward it to Jeff Schiller so we can formally create the working group. Thanks for your attention. - Win Treese From paulh@imc.org Tue Apr 23 13:32:45 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id NAA09750 for ; Tue, 23 Apr 1996 13:32:44 -0400 Received: from imc.org by www10.w3.org (5.0/NSCS-1.0S) id AA04760; Tue, 23 Apr 1996 13:32:41 +0500 Received: from [165.227.113.247] (phoffman.sc.scruznet.com [165.227.113.247]) by imc.org (8.7.4/8.7.1) with ESMTP id KAA27889; Tue, 23 Apr 1996 10:29:39 -0700 (PDT) Message-Id: In-Reply-To: <2.2.32.19960423145300.006ccdd4@OpenMarket.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 Apr 1996 10:33:47 -0700 To: Win Treese , ietf-tls@w3.org From: Paul Hoffman Subject: Re: what's going on content-length: 612 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls At 7:53 AM -0700 4/23/96, Win Treese wrote: >Finally, there were a few questions about details of the protocol we might >come up with, but I got a general sense that the the last draft charter was >acceptable to the group. If there are no objections to the charter as is in >the next couple of days, I'll forward it to Jeff Schiller so we can formally >create the working group. Win, could you repost the "last draft charter" before passing it on? There was some suggestions for changes after the last one I saw, and want to be sure we're all agreeing on the same thing, at least as far as the charter goes. From dansimon@microsoft.com Tue Apr 23 16:44:33 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id QAA10987 for ; Tue, 23 Apr 1996 16:44:33 -0400 Received: from tide21.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA05879; Tue, 23 Apr 1996 16:44:32 +0500 Received: by tide21.microsoft.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB311B.1258AD20@tide21.microsoft.com>; Tue, 23 Apr 1996 13:45:02 -0700 Message-Id: From: Dan Simon To: "'ietf-tls@w3.org'" Subject: RE: STLP and proposal Date: Tue, 23 Apr 1996 13:44:19 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit content-length: 1793 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls > >This is in response to the mailings and press announcements exchanged >regarding the Microsoft proposed modifications to the SSL 3.0 >specifications -- apparently referred to in the industry as "STLP". > Taher addresses only two technical points: datagram support and support for pre-encrypted data. The former, while certainly not the *main* function for a TLS protocol, is useful for such purposes as sending out-of-band data, and for protocols like PPTP, which establish a TCP connection for control messages but use IP for bulk data transmission. Taher claims that the mechanism proposed for the latter (pre-encrypted data) "breaks" the protocol, but I don't see that it poses any security (or other) problems. (If it does, I would certainly like to see the details.) In the absence of such problems, I believe that support for pre-encrypted data would be a useful efficiency feature of the protocol. (I might add that there are most probably other ways of implementing the feature safely, if use of the "change cipher spec" message is unworkable.) There are a number of other technical issues raised by the STLP document that I believe merit consideration. The most salient is the possibility of revamping the handshake protocol flow to make it more flexible, symmetric and efficient. Another is that the negotiation of authentication options can be made more flexible and explicit by including, for example, certificate types and the option of password-based authentication. (This latter topic has already been raised by David Kemp, who opposes the inclusion of the password option, and has also commented on some of the other technical issues; I'll respond to his points as soon as I can.) Daniel Simon Cryptographer, Microsoft Corp. dansimon@microsoft.com > From bfox@microsoft.com Tue Apr 23 17:40:05 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id RAA11275 for ; Tue, 23 Apr 1996 17:40:05 -0400 Received: from abash1.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA06170; Tue, 23 Apr 1996 17:40:04 +0500 Received: by abash1.microsoft.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB3122.87436290@abash1.microsoft.com>; Tue, 23 Apr 1996 14:38:25 -0700 Message-Id: From: Barb Fox To: "'ietf-tls@w3.org'" Subject: RE: STLP and proposal Date: Tue, 23 Apr 1996 14:35:01 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit content-length: 1850 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls OK - this list is for TECHNICAL discussions. On this alias we should discuss the features needed in a new and better transport-layer protocol and not the politics of choosing one existing protocol over another. (If we fall into the trap of the latter, we will all lose...) Our only intent is to accelerate the process and get an open standard within the IETF quickly. It is Microsoft's goal with the STLP strawman to avoid the anticipated shootout between SSL and PCT. We would have preferred to have taken PCT 2 as the basis for an STLP standard, but we felt that doing this would have been viewed as contentious and have merely delayed the development and adoption of a new protocol standard. So despite the risk that we would appear to be abandoning PCT and our PCT partners, we decided to base our STLP strawman on SSLv3. We remain committed to supporting PCT and PCT developers just as Netscape is committed to SSL and SSL developers. But the new protocol is not about PCT or SSL or any other individual protocol. It is simply about developing an OPEN standard. We're frankly delighted that transport layer security is an IETF working group! btw: our STLP starting point incorporated the following ideas from PCT: - datagram support - new keys and cipher specs allowed, supporting pre-encrypted data - less long-term dependence on particular algorithms - more information in alerts for robust error-handling - improved handshaking, allowing speed-up when the client has the server's key - additional authentication options, including previously shared secrets - full specification of cert types and names for both clients and servers The idea tho is to get other than MS and Netscape to comment on what should be in STLP. So please let's get an active discussion going on the technology. Barbara Fox Senior Architect Microsoft From stephenr@tde.com Tue Apr 23 18:25:57 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id SAA11426 for ; Tue, 23 Apr 1996 18:25:50 -0400 Received: from tde2.tde.com by www10.w3.org (5.0/NSCS-1.0S) id AA06343; Tue, 23 Apr 1996 18:25:49 +0500 Received: from stephenr.tde.com (sl126.tde.com [199.45.251.26]) by tde2.tde.com (8.6.12/8.6.12) with SMTP id QAA12442; Tue, 23 Apr 1996 16:25:41 -0600 Message-Id: <317D58E2.2DF@tde.com> Date: Tue, 23 Apr 1996 16:25:38 -0600 From: Stephen Rial Organization: Steve's Corner of the World X-Mailer: Mozilla 2.01Gold (Win95; I) Mime-Version: 1.0 To: ietf-tls@w3.org Cc: bfox@microsoft.com Subject: What is going on?????? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 571 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Dear Sirs: I have asked several times that I be taken off of your mailing list. This has been going on for a couple weeks now and my mailbox keeps getting flooded with mail that has been labeled "RESENT" from so and so. I don't know why anyone needs to resend mail to anyone with regard to a subscription of unpdated information. Please remove my name from your list and hopefully this bit with information that is over my head dealing with layers of protocols (sounds like baking a cake!) will get resolved with all you folks out there. THANKS!! Stephen Rial From elgamal@netscape.com Tue Apr 23 23:02:16 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id XAA13053 for ; Tue, 23 Apr 1996 23:02:16 -0400 Received: from urchin.netscape.com (h-198-95-250-59.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA07097; Tue, 23 Apr 1996 23:02:15 +0500 Received: from kingtut (loving197.mcom.com [205.217.240.197]) by urchin.netscape.com (8.6.12/8.6.9) with SMTP id UAA05429; Tue, 23 Apr 1996 20:02:54 -0700 Message-Id: <317D9A93.4BFA@netscape.com> Date: Tue, 23 Apr 1996 20:05:55 -0700 From: Taher Elgamal X-Mailer: Mozilla 2.01Gold (Win95; I) Mime-Version: 1.0 To: Dan Simon Cc: "'ietf-tls@w3.org'" Subject: Re: STLP and proposal References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 2660 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls I only mentione these two not as a complete set at all. The working group should consider all possible features, improvements and enhancements. My message was sent because the "private" STLP discussions became public very quickly and I do not see the need to discuss these things twice, once in one-on-one and once in the WG. My opinions about some of the proposed features do not reflect what the WG would like to do or otherwise propose. I just noticed that SSL3.0 looks like a good starting point, and if we start now we have a chnace of getting somewhere. Taher Dan Simon wrote: > > > > >This is in response to the mailings and press announcements exchanged > >regarding the Microsoft proposed modifications to the SSL 3.0 > >specifications -- apparently referred to in the industry as "STLP". > > > Taher addresses only two technical points: datagram support and support > for pre-encrypted data. The former, while certainly not the *main* > function for a TLS protocol, is useful for such purposes as sending > out-of-band data, and for protocols like PPTP, which establish a TCP > connection for control messages but use IP for bulk data transmission. > Taher claims that the mechanism proposed for the latter (pre-encrypted > data) "breaks" the protocol, but I don't see that it poses any security > (or other) problems. (If it does, I would certainly like to see the > details.) In the absence of such problems, I believe that support for > pre-encrypted data would be a useful efficiency feature of the protocol. > (I might add that there are most probably other ways of implementing > the feature safely, if use of the "change cipher spec" message is > unworkable.) > > There are a number of other technical issues raised by the STLP document > that I believe merit consideration. The most salient is the possibility > of revamping the handshake protocol flow to make it more flexible, > symmetric and efficient. Another is that the negotiation of > authentication options can be made more flexible and explicit by > including, for example, certificate types and the option of > password-based authentication. (This latter topic has already been > raised by David Kemp, who opposes the inclusion of the password option, > and has also commented on some of the other technical issues; I'll > respond to his points as soon as I can.) > > Daniel Simon > Cryptographer, Microsoft Corp. > dansimon@microsoft.com > > > -- Taher Elgamal elgamal@netscape.com Chief Scientist, Netscape Communications (T) 415 937 2898, (F) 415 428 4054 From elgamal@netscape.com Tue Apr 23 23:02:25 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id XAA13072 for ; Tue, 23 Apr 1996 23:02:25 -0400 Received: from urchin.netscape.com (h-198-95-250-59.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA07100; Tue, 23 Apr 1996 23:02:23 +0500 Received: from kingtut (loving197.mcom.com [205.217.240.197]) by urchin.netscape.com (8.6.12/8.6.9) with SMTP id UAA05432; Tue, 23 Apr 1996 20:03:09 -0700 Message-Id: <317D9AA4.2117@netscape.com> Date: Tue, 23 Apr 1996 20:06:12 -0700 From: Taher Elgamal X-Mailer: Mozilla 2.01Gold (Win95; I) Mime-Version: 1.0 To: Dan Simon Cc: "'ietf-tls@w3.org'" Subject: Re: STLP and proposal References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 2661 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls I only mentioned these two not as a complete set at all. The working group should consider all possible features, improvements and enhancements. My message was sent because the "private" STLP discussions became public very quickly and I do not see the need to discuss these things twice, once in one-on-one and once in the WG. My opinions about some of the proposed features do not reflect what the WG would like to do or otherwise propose. I just noticed that SSL3.0 looks like a good starting point, and if we start now we have a chnace of getting somewhere. Taher Dan Simon wrote: > > > > >This is in response to the mailings and press announcements exchanged > >regarding the Microsoft proposed modifications to the SSL 3.0 > >specifications -- apparently referred to in the industry as "STLP". > > > Taher addresses only two technical points: datagram support and support > for pre-encrypted data. The former, while certainly not the *main* > function for a TLS protocol, is useful for such purposes as sending > out-of-band data, and for protocols like PPTP, which establish a TCP > connection for control messages but use IP for bulk data transmission. > Taher claims that the mechanism proposed for the latter (pre-encrypted > data) "breaks" the protocol, but I don't see that it poses any security > (or other) problems. (If it does, I would certainly like to see the > details.) In the absence of such problems, I believe that support for > pre-encrypted data would be a useful efficiency feature of the protocol. > (I might add that there are most probably other ways of implementing > the feature safely, if use of the "change cipher spec" message is > unworkable.) > > There are a number of other technical issues raised by the STLP document > that I believe merit consideration. The most salient is the possibility > of revamping the handshake protocol flow to make it more flexible, > symmetric and efficient. Another is that the negotiation of > authentication options can be made more flexible and explicit by > including, for example, certificate types and the option of > password-based authentication. (This latter topic has already been > raised by David Kemp, who opposes the inclusion of the password option, > and has also commented on some of the other technical issues; I'll > respond to his points as soon as I can.) > > Daniel Simon > Cryptographer, Microsoft Corp. > dansimon@microsoft.com > > > -- Taher Elgamal elgama