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 elgamal@netscape.com Chief Scientist, Netscape Communications (T) 415 937 2898, (F) 415 428 4054 From elgamal@netscape.com Tue Apr 23 23:08:14 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id XAA13098 for ; Tue, 23 Apr 1996 23:08:13 -0400 Received: from urchin.netscape.com (h-198-95-250-59.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA07121; Tue, 23 Apr 1996 23:08:12 +0500 Received: from kingtut (loving197.mcom.com [205.217.240.197]) by urchin.netscape.com (8.6.12/8.6.9) with SMTP id UAA05564; Tue, 23 Apr 1996 20:08:36 -0700 Message-Id: <317D9BEB.17E2@netscape.com> Date: Tue, 23 Apr 1996 20:11:39 -0700 From: Taher Elgamal X-Mailer: Mozilla 2.01Gold (Win95; I) Mime-Version: 1.0 To: Barb Fox Cc: "'ietf-tls@w3.org'" Subject: Re: STLP and proposal References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 2236 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Actually I am trying to avoid politics. I think since the discussion has gone public anyway that we should judt take it public (to the WG) and avoid repetition. Taher Barb Fox wrote: > > 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 -- Taher Elgamal elgamal@netscape.com Chief Scientist, Netscape Communications (T) 415 937 2898, (F) 415 428 4054 From treese@openmarket.com Wed Apr 24 03:09:49 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id DAA13739 for ; Wed, 24 Apr 1996 03:09:48 -0400 Received: from relay.openmarket.com by www10.w3.org (5.0/NSCS-1.0S) id AA07594; Wed, 24 Apr 1996 03:09:47 +0500 Received: from cirocco.openmarket.com (cirocco.openmarket.com [199.170.183.9]) by relay.openmarket.com (8.6.10/8.6.6) with ESMTP id DAA06063 for ; Wed, 24 Apr 1996 03:09:47 -0400 Received: from OpenMarket.com (localhost [127.0.0.1]) by cirocco.openmarket.com (8.6.9/8.6.6) with ESMTP id DAA08380 for ; Wed, 24 Apr 1996 03:09:46 -0400 Message-Id: <199604240709.DAA08380@cirocco.openmarket.com> To: ietf-tls@w3.org Subject: resend of proposed charter Date: Wed, 24 Apr 1996 03:09:45 -0400 From: Win Treese content-length: 2121 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls 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 TLC Working Group: Several methods of providing a secure and authenticated channel between hosts 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 treese@openmarket.com Wed Apr 24 03:24:49 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id DAA13983 for ; Wed, 24 Apr 1996 03:24:49 -0400 Received: from relay.openmarket.com by www10.w3.org (5.0/NSCS-1.0S) id AA07647; Wed, 24 Apr 1996 03:24:48 +0500 Received: from cirocco.openmarket.com (cirocco.openmarket.com [199.170.183.9]) by relay.openmarket.com (8.6.10/8.6.6) with ESMTP id DAA07222 for ; Wed, 24 Apr 1996 03:24:47 -0400 Received: from OpenMarket.com (localhost [127.0.0.1]) by cirocco.openmarket.com (8.6.9/8.6.6) with ESMTP id DAA08397 for ; Wed, 24 Apr 1996 03:24:47 -0400 Message-Id: <199604240724.DAA08397@cirocco.openmarket.com> To: ietf-tls@w3.org Subject: issues with the charter Date: Wed, 24 Apr 1996 03:24:46 -0400 From: Win Treese content-length: 1387 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls >From earlier discussion, there were several points about what the charter might also include: 1. security protocols for UDP 2. producing a requirements document beyond the charter 3. migration from existing protocols 4. relation to proxies 5. relevance of port numbers 6. multiplexing connections over a single secure connection It seems to me that the purpose of the charter is to nail down a few concrete and achievable goals. We can add to those goals, but each new goal adds to the up-front constraints, as opposed to those we choose as we proceed. Item #1 is outside the scope of the current charter, which is about reliable connections. Given the state of current practice, I think it's reasonable to stay with reliable connections and not try to bite off the UDP problem as well. A requirements document (item #2) to help focus discussion could be very useful. Would anyone like to draft one? On the other hand, I don't think it's absolutely necessary, so I suggest we not include it in the charter. The remainder of the items are certainly worth discussing, but it seems to me that putting them into the charter may unnecessarily limit our options as the discussion evolves. As noted earlier, I'd like to close on the charter, but that doesn't mean closing off discussion of all of these topics -- some we may deem relevant, and some not. Comments? - Win Treese From rspoore@ralph-s-poore.com Wed Apr 24 11:08:01 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id LAA18926 for ; Wed, 24 Apr 1996 11:08:00 -0400 Received: from defiant.flash.net by www10.w3.org (5.0/NSCS-1.0S) id AA08959; Wed, 24 Apr 1996 11:07:56 +0500 Received: from p3-15.flash.net (p3-15.flash.net [206.190.63.15]) by defiant.flash.net (8.6.12/8.6.9) with SMTP id KAA13798; Wed, 24 Apr 1996 10:07:42 -0500 Date: Wed, 24 Apr 1996 10:07:42 -0500 Message-Id: <199604241507.KAA13798@defiant.flash.net> X-Sender: rspoore@ralph-s-poore.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Bennet Yee From: Ralph Spencer Poore Subject: Re: Merged Transport Layer Protocol Development Cc: ietf-tls@w3.org content-length: 1862 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls At 09:32 PM 4/22/96 -0700, you wrote: >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. > >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 I agree. Support for pre-encrypted or pre-MAC'ed data also permits the use of very secure hardware implementations of cryptography for highly sensitive data without impacting the server software implementation which might be unable to meet trusted system criteria or other high-security policy of an organization. ================================================= | Ralph Spencer Poore | Ralph Spencer Poore | Ralph Spencer Poore | | Author | President, (ISC)2 | Director, ISS, C&L LLP | | rspoore@flash.net | CompuServe 71242,2723 | rmoorenn@colybrand.com | | | | "Any opinions expressed by me are my opinions and do not necessarily | | reflect the views of any organizations with which I am associated." | ================================================= From paulh@imc.org Wed Apr 24 11:56:50 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id LAA19206 for ; Wed, 24 Apr 1996 11:56:49 -0400 Received: from imc.org by www10.w3.org (5.0/NSCS-1.0S) id AA09140; Wed, 24 Apr 1996 11:56: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 IAA07431 for ; Wed, 24 Apr 1996 08:53:37 -0700 (PDT) Message-Id: In-Reply-To: <199604240724.DAA08397@cirocco.openmarket.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Apr 1996 08:58:08 -0700 To: ietf-tls@w3.org From: Paul Hoffman Subject: Re: issues with the charter content-length: 1714 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls >1. security protocols for UDP I'm willing to not have it in the first product of this group, but I strongly believe that it should be considered when making that product. That is, if a secure solution can include UDP, it should; if it can't, a way to clone much of the work for UDP should be considered. If UDP prevents a secure solution at this layer, we can still rely on secure IP. I think the wording in the charter is good enough on this, but if our first document ignores UDP, it will not be as strong as if we at least consider it. >2. producing a requirements document beyond the charter I am sure we will need a requirements list that the WG agrees on. We may not need to turn this into a formal document, but from the already (and unnecessarily) heated discussion, it is clear that not everyone agrees on the requirements list. This doesn't have to be a charter item, but without such a list, I think we'll not get very much past one or two starting proposals. >3. migration from existing protocols Agree: we don't want to deal with this as a WG. >4. relation to proxies This should be part of the document we produce. As both the SSL and PCT folks have discovered, relation to proxies is non-trivial. We don't have to create a solution that works wonderfully with all of today's proxies, but we do have to take proxies into account in our document and deliniate how they should deal with tunnelling and so on. I believe that this is important enough to be a charter item. >5. relevance of port numbers This could be one or two paragraphs, and doesn't have to be in the charter. >6. multiplexing connections over a single secure connection Not a charter item, but one that could come later. From dpkemp@missi.ncsc.mil Wed Apr 24 12:39:46 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id MAA19653 for ; Wed, 24 Apr 1996 12:39:46 -0400 Received: from guardian.guard.ncsc.mil by www10.w3.org (5.0/NSCS-1.0S) id AA09393; Wed, 24 Apr 1996 12:39:45 +0500 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id MAA22811 for ; Wed, 24 Apr 1996 12:40:00 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma022809; Wed Apr 24 12:39:43 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 MAA29940 for ; Wed, 24 Apr 1996 12:36:00 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id MAA17996; Wed, 24 Apr 1996 12:39:37 -0400 Date: Wed, 24 Apr 1996 12:39:37 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199604241639.MAA17996@argon.ncsc.mil> To: ietf-tls@w3.org Subject: Re: Merged Transport Layer Protocol Development X-Sun-Charset: US-ASCII content-length: 2859 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls > From: Ralph Spencer Poore > > At 09:32 PM 4/22/96 -0700, you wrote: > >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. > > > >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. > > I agree. Support for pre-encrypted or pre-MAC'ed data also permits the use > of very secure hardware implementations of cryptography for highly sensitive > data without impacting the server software implementation which might be > unable to meet trusted system criteria or other high-security policy of an > organization. I disagree. Support for pre-encrypted or pre-MAC'ed data is *only* an efficiency hack, and even then one with negligible or zero benefit over SSL. If you want to pre-process data with a very secure implementation (in the Govt. we call it "Type 1" encryption), you're certainly free to do so. SSL doesn't know or care whether the application-data presented to it is plaintext or super-encrypted; it's all treated the same, using the current CipherSpec. Mr. Yee suggests that pre-encrypting images can eliminate server overhead for bulk crypto, but I don't see how. If you have a large pre-encrypted file to transmit over SSL, then just renegotiate a NULL-WITH-NULL CipherSpec before sending the file, and resume the previous CipherSpec when it's done. The only overhead is for two handshake exchanges, which shouldn't be a serious burden on the server. On the other hand, creating a totally separate set of handshake messages to support pre-encrypted data is just another potential place for security holes to pop up. I admit to not having studied the PCT 2.0 pre-encryption specs in detail, but before spending time doing so I'd like to see answers to the following: 1) How much time does the PCTv2 pre-encryption handshake save over the standard SSLv3 resume-session handshake?, and 2) if the answer to 1 is greater than epsilon, what analysis has been done to show that the pre-encryption handshake does not introduce new vulnerabilities to the protocol? From karlton@netscape.com Wed Apr 24 12:52:53 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id MAA19683 for ; Wed, 24 Apr 1996 12:52:53 -0400 Received: from ghoti.mcom.com (h-205-217-232-38.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA09483; Wed, 24 Apr 1996 12:52:52 +0500 Received: from ghoti (localhost [127.0.0.1]) by ghoti.mcom.com (940816.SGI.8.6.9/8.6.9) with SMTP id JAA14202 for ; Wed, 24 Apr 1996 09:52:51 -0700 Sender: karlton@netscape.com Message-Id: <317E5C62.2781@netscape.com> Date: Wed, 24 Apr 1996 09:52:50 -0700 From: Phil Karlton Organization: Netscape Communications X-Mailer: Mozilla 3.0b4 (X11; U; IRIX 5.3 IP22) Mime-Version: 1.0 To: ietf-tls@w3.org Subject: STLP "implementation comments" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 2971 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Some of the comments in the STLP draft are misdirected and have confused at least one implementor of SSL 3. The responses below are only here to remove confusion about the SSL spec. No inference should be made about agreement or disagreement with any other part of the STLP spec or the implementation comments. > SSLv3 Implementation Comments > > The following non-comprehensive list is derived from implementation > experience with SSL Version 3 published as an Internet Draft in March > 1996. Its intent is to suggest modifications to the base protocol > rather than to specifically critique SSL Version 3. > > (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. There is no API or implementation implied by the SSL 3 spec. In fact, the Netscape implementation is done with mutliple small tables. > (2) Don't use post-compressed, post-hashed, post-encrypted, > post-enveloped data for the final handshake digest. Implementation > is painful. Using the original cleartext, or alternatively, the > compressedtext, makes for a cleaner layer structure in the > implementation. The handshake hashes are done with the plaintext input of the handshake data. A straightforward implementation is possible without any layering violations. > (4) Provision for a uniform message header for all types of messages > is a very good thing. At any time in the process it should be > possible to differentiate control from client data. Since there are 4 sub-protocols on top of the SSL record layer (application data, alerts, handshake, change cipher specs) it is already possible to the differentiation. > (7) Greater symmetry would be valuable from an implementation point > of view. If a given piece of data is being exchanged, it should be > the same whether the server or the client is supplying it (there > should not be two different message formats for supplying a > certificate). Right now, implementing the server and implementing > the client are almost unrelated tasks because the protocol is so > asymmetrical. The final SSL 3.0 protocol was influenced by its implementation. Much sharing is possible betweent the messages dealt with by the client and server. (For instance, The Certificate message is the same independent of direction.) Many messages contain common sub-records. > (8) MD2 and MD4 need to be phased out owing to the detection of a > security problem. SHA is recommended. SSL 3.0 does not use MD2 or MD4. PK -- Philip L. Karlton karlton@netscape.com Principal Curmudgeon http://home.netscape.com/people/karlton Netscape Communications They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin From dansimon@microsoft.com Wed Apr 24 13:50:45 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id NAA20164 for ; Wed, 24 Apr 1996 13:50:45 -0400 Received: from tide21.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA09757; Wed, 24 Apr 1996 13:50:44 +0500 Received: by tide21.microsoft.com with Microsoft Exchange (IMC 4.0.838.5) id <01BB31CB.FBD08710@tide21.microsoft.com>; Wed, 24 Apr 1996 10:51:25 -0700 Message-Id: From: Dan Simon To: "'ietf-tls@w3.org'" Subject: RE: Merged Transport Layer Protocol Development Date: Wed, 24 Apr 1996 10:50:29 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit content-length: 4949 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Some miscellaneous responses to David Kemp's (generally interesting and appreciated) comments (I'll be responding separately on the specific subject of password authentication): >(From dpkemp@missi.ncsc.mil[SMTP:dpkemp@missi.ncsc.mil]:) > >> (8) MD2 and MD4 need to be phased out owing to the detection of a >> security problem. SHA is recommended. > >Agree. I should point out that MD2 and MD4 appear nowhere (as far as I can >tell) in either SSL v3.0, PCT (v1 or v2), or the STLP working document. > A more interesting question is whether MD5 should be phased out as well. I'd be interested to hear opinions on the subject. > >> (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 new PPTP protocol for tunnelling PPP over the Internet specifies a >TCP channel for control messages and IP for bulk data transmission. >I'm not familiar with how they specify managing the two channels separately, but they presumably have something in mind. > >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. >The PCT v2 spec includes a proposal for an "escrow" solution; proxies >are provided with the decryption keys for every connection, for whatever checking purposes they have in mind. Not being too familiar with firewalls, I'd be interested in seeing other proposals as well. > >> >> 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. UNIX time was not removed so that challenges would be more random, but >rather to preserve available randomness resources. UNIX time on a machine may reasonably be expected to contain, say, 3 bits of entropy, >if not sampled too often. This may not sound like much, but when >you're trying to harvest entropy from a PC for psuedorandom generator >seeding, you need every bit you can scrounge. Publicizing this value >on a regular basis takes away its value as a contributor to this >process. On the other hand, given the ease (and frequency) with which >time is reset on many machines, its value as a source of pure non-repeatability for challenges (as opposed to randomness) is, in my view, negligible. > >> 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 >:-) > If a key is used long enough for a 32-bit sequence number to wrap, then it should be discarded and a new one renegotiated. This point is made explicitly in the PCT specs. Daniel Simon Cryptographer, Microsoft Corp. dansimon@microsoft.com > > From dansimon@microsoft.com Wed Apr 24 13:51:15 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id NAA20187 for ; Wed, 24 Apr 1996 13:51:14 -0400 Received: from tide21.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA09760; Wed, 24 Apr 1996 13:51:14 +0500 Received: by tide21.microsoft.com with Microsoft Exchange (IMC 4.0.838.5) id <01BB31CC.0C871790@tide21.microsoft.com>; Wed, 24 Apr 1996 10:51:53 -0700 Message-Id: From: Dan Simon To: "'ietf-tls@w3.org'" Subject: Password Authentication (was RE: Merged Transport Layer Protocol Development) Date: Wed, 24 Apr 1996 10:51:01 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit content-length: 2961 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls I am responding to David Kemp's comments about password authentication separately, because I believe the topic is important enough to deserve separate treatment. >(From dpkemp@missi.ncsc.mil[SMTP:dpkemp@missi.ncsc.mil]:) >> (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. >To me, the issue is not whether password authentication is weaker than >authentication by certified asymmetric key; most everyone would agree >that this is the case. Unfortunately, for reasons ranging from >established practice to portability issues to plain ignorance, many >people will likely continue to use passwords for authentication for >some time to come, whether protocol authors want them to or not. The >issue at hand is therefore whether password-based authentication must >continue to be as weak as the encryption available (which is often, as >we all know, woefully weak), or whether, by our protocol design >choices, we can make the security of password authentication as strong as it can possibly be. >Nobody advocates forcing people to use passwords (even if it were >possible to do so). The question is whether we can force them not to, >and what to do given that we can't. Anyone who doesn't trust password-based security is always free not to support it; in fact, it takes an explicit decision by both parties to share a password before password authentication even becomes possible. People who make that decision are, in my view, no different from those who accept 40-bit encryption, or proprietary, relatively unstudied RC4 over heavily-analyzed (triple-)DES; we cryptographers might prefer that they choose otherwise, but we recognize that security must sometimes yield to other practical priorities. Daniel Simon Cryptographer, Microsoft Corp. dansimon@microsoft.com From dansimon@microsoft.com Wed Apr 24 15:51:14 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id PAA20828 for ; Wed, 24 Apr 1996 15:51:13 -0400 Received: from tide19.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA10273; Wed, 24 Apr 1996 15:51:13 +0500 Received: by tide19.microsoft.com with Microsoft Exchange (IMC 4.0.838.5) id <01BB31DC.ABDA7ED0@tide19.microsoft.com>; Wed, 24 Apr 1996 12:50:52 -0700 Message-Id: From: Dan Simon To: "'ietf-tls@w3.org'" Subject: RE: Password Authentication (was RE: Merged Transport Layer Protocol Development) Date: Wed, 24 Apr 1996 12:50:49 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit content-length: 3105 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls I am resending this email with apologies, and ">" attributions corrected.... ------------ >I am responding to David Kemp's comments about password authentication >separately, because I believe the topic is important enough to deserve >separate treatment. > >>(From dpkemp@missi.ncsc.mil[SMTP:dpkemp@missi.ncsc.mil]:) > >>> (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. > >To me, the issue is not whether password authentication is weaker than >authentication by certified asymmetric key; most everyone would agree >that this is the case. Unfortunately, for reasons ranging from >established practice to portability issues to plain ignorance, many >people will likely continue to use passwords for authentication for >some time to come, whether protocol authors want them to or not. The >issue at hand is therefore whether password-based authentication must >continue to be as weak as the encryption available (which is often, as >we all know, woefully weak), or whether, by our protocol design >choices, we can make the security of password authentication as strong >as it can possibly be. > >Nobody advocates forcing people to use passwords (even if it were >possible to do so). The question is whether we can force them not to, >and what to do given that we can't. Anyone who doesn't trust >password-based security is always free not to support it; in fact, it >takes an explicit decision by both parties to share a password before >password authentication even becomes possible. People who make that >decision are, in my view, no different from those who accept 40-bit >encryption, or proprietary, relatively unstudied RC4 over >heavily-analyzed (triple-)DES; we cryptographers might prefer that they >choose otherwise, but we recognize that security must sometimes yield >to >other practical priorities. > > > Daniel Simon > Cryptographer, Microsoft Corp. > dansimon@microsoft.com > > > > From dansimon@microsoft.com Wed Apr 24 15:53:24 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id PAA20849 for ; Wed, 24 Apr 1996 15:53:24 -0400 Received: from tide21.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA10283; Wed, 24 Apr 1996 15:53:23 +0500 Received: by tide21.microsoft.com with Microsoft Exchange (IMC 4.0.838.5) id <01BB31DC.D857CEE0@tide21.microsoft.com>; Wed, 24 Apr 1996 12:52:07 -0700 Message-Id: From: Dan Simon To: "'ietf-tls@w3.org'" Subject: RE: Merged Transport Layer Protocol Development Date: Wed, 24 Apr 1996 12:51:12 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit content-length: 5142 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls I am resending this email with apologies, and ">" attributions corrected.... ---------------- >Some miscellaneous responses to David Kemp's (generally interesting and >appreciated) comments (I'll be responding separately on the specific >subject of password authentication): > >>(From dpkemp@missi.ncsc.mil[SMTP:dpkemp@missi.ncsc.mil]:) >> >>> (8) MD2 and MD4 need to be phased out owing to the detection of a >>> security problem. SHA is recommended. >> >>Agree. > >I should point out that MD2 and MD4 appear nowhere (as far as I can >tell) in either SSL v3.0, PCT (v1 or v2), or the STLP working document. >A more interesting question is whether MD5 should be phased out as >well. I'd be interested to hear opinions on the subject. > >>> (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 new PPTP protocol for tunnelling PPP over the Internet specifies a >TCP channel for control messages and IP for bulk data transmission. >I'm not familiar with how they specify managing the two channels >separately, but they presumably have something in mind. > >>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. > >The PCT v2 spec includes a proposal for an "escrow" solution; proxies >are provided with the decryption keys for every connection, for >whatever checking purposes they have in mind. Not being too familiar >with firewalls, I'd be interested in seeing other proposals as well. > >>> >>> 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. > >UNIX time was not removed so that challenges would be more random, but >rather to preserve available randomness resources. UNIX time on a >machine may reasonably be expected to contain, say, 3 bits of entropy, >if not sampled too often. This may not sound like much, but when >you're trying to harvest entropy from a PC for psuedorandom generator >seeding, you need every bit you can scrounge. Publicizing this value >on a regular basis takes away its value as a contributor to this >process. On the other hand, given the ease (and frequency) with which >time is reset on many machines, its value as a source of pure >non-repeatability for challenges (as opposed to randomness) is, in my >view, negligible. > >>> 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 >>:-) > >If a key is used long enough for a 32-bit sequence number to wrap, then >it should be discarded and a new one renegotiated. This point is made >explicitly in the PCT specs. > > > Daniel Simon > Cryptographer, Microsoft Corp. > dansimon@microsoft.com > > > > > > > From ylo@ssh.fi Wed Apr 24 18:06:58 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id SAA21644 for ; Wed, 24 Apr 1996 18:06:52 -0400 Received: from muuri.ssh.fi (acr.innopoli.fi) by www10.w3.org (5.0/NSCS-1.0S) id AA10921; Wed, 24 Apr 1996 18:06:26 +0500 Received: from pilari.ssh.fi (pilari.ssh.fi [192.168.2.1]) by muuri.ssh.fi (8.7.5/8.7.3) with ESMTP id BAA20629; Thu, 25 Apr 1996 01:06:22 +0300 (EET DST) Received: (from ylo@localhost) by pilari.ssh.fi (8.7.5/8.7.3) id BAA07216; Thu, 25 Apr 1996 01:06:22 +0300 (EET DST) Date: Thu, 25 Apr 1996 01:06:22 +0300 (EET DST) Message-Id: <199604242206.BAA07216@pilari.ssh.fi> From: Tatu Ylonen To: dpkemp@missi.ncsc.mil (David P. Kemp) Cc: ietf-tls@w3.org Subject: Re: Merged Transport Layer Protocol Development In-Reply-To: <199604241639.MAA17996@argon.ncsc.mil> References: <199604241639.MAA17996@argon.ncsc.mil> Organization: Helsinki University of Technology, Finland content-length: 2191 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls I just wish to say that I also agree that special processing for pre-encrypted data is a Bad Idea. A 90-MHz Pentium can encrypt fast enought to completely fill an ethernet (the ethernet becomes the limiting factor), and the processing speed is doubling every year. The overhead from encryption is negligible all but the most high-volume servers connected to the Internet by something faster than 10Mbits/sec. (Unless you also do a lot of CPU-intensive processing that competes for CPU.) I don't think the complications from special handling are justified. As for pre-encryption with strong hardware algorithms, it does no harm to double-encrypt. Tatu > I disagree. Support for pre-encrypted or pre-MAC'ed data is *only* an > efficiency hack, and even then one with negligible or zero benefit over SSL. > > If you want to pre-process data with a very secure implementation > (in the Govt. we call it "Type 1" encryption), you're certainly free > to do so. SSL doesn't know or care whether the application-data > presented to it is plaintext or super-encrypted; it's all treated > the same, using the current CipherSpec. > > Mr. Yee suggests that pre-encrypting images can eliminate server > overhead for bulk crypto, but I don't see how. If you have a large > pre-encrypted file to transmit over SSL, then just renegotiate a > NULL-WITH-NULL CipherSpec before sending the file, and resume the > previous CipherSpec when it's done. The only overhead is for two > handshake exchanges, which shouldn't be a serious burden on the > server. > > On the other hand, creating a totally separate set of handshake > messages to support pre-encrypted data is just another potential > place for security holes to pop up. I admit to not having studied > the PCT 2.0 pre-encryption specs in detail, but before spending time > doing so I'd like to see answers to the following: > > 1) How much time does the PCTv2 pre-encryption handshake save over > the standard SSLv3 resume-session handshake?, and > > 2) if the answer to 1 is greater than epsilon, what analysis has been > done to show that the pre-encryption handshake does not introduce > new vulnerabilities to the protocol? > From bsy@work.ucsd.edu Wed Apr 24 18:16:50 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id SAA21737 for ; Wed, 24 Apr 1996 18:16:50 -0400 Received: from odin.ucsd.edu by www10.w3.org (5.0/NSCS-1.0S) id AA10962; Wed, 24 Apr 1996 18:16:43 +0500 Received: from work.ucsd.edu by odin.ucsd.edu; id AA10323 sendmail 8.73/UCSDPSEUDO.4-CS via SMTP Wed, 24 Apr 96 15:16:34 -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 PAA07915; Wed, 24 Apr 1996 15:16:33 -0700 (PDT) Message-Id: <199604242216.PAA07915@work.ucsd.edu> To: Dan Simon Cc: "'ietf-tls@w3.org'" Reply-To: Bennet Yee Subject: Re: Merged Transport Layer Protocol Development In-Reply-To: Your message of "Wed, 24 Apr 1996 12:51:12 -0700." Date: Wed, 24 Apr 1996 15:16:31 -0700 From: Bennet Yee content-length: 3029 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls In message , Dan Simon writes: > > UNIX time was not removed so that challenges would be more random, but > rather to preserve available randomness resources. UNIX time on a > machine may reasonably be expected to contain, say, 3 bits of entropy, > if not sampled too often. This may not sound like much, but when > you're trying to harvest entropy from a PC for psuedorandom generator > seeding, you need every bit you can scrounge. Publicizing this value > on a regular basis takes away its value as a contributor to this > process. On the other hand, given the ease (and frequency) with which > time is reset on many machines, its value as a source of pure > non-repeatability for challenges (as opposed to randomness) is, in my > view, negligible. All modern Unix systems provide the time on the daytime port (TCP port 13, also UDP port 13, RFC 867 / STD 25). Perhaps Windows machines, being more recently network-aware, do not yet offer this common service (along with echo, chargen, etc services) as standard configuration. While I have not checked into it, I would imagine that any complete TCP stack implementation for Windows would include these kinds of common services. So while the daytime service is not a _required_ service per se, it is so often provided that expecting much secrecy of the _precise_ time value is probably inappropriate. (Figuring out the value to second resolution is not hard when network latencies range from a few to a hundred millisecond.) Furthermore, many machines use the Network Time Protocol (see RFC 1589) to automatically synchronize their internal clocks with the US time standard and automatically account for hardware clock drift. While this is not a requirement for Internet-aware machines either, it is not uncommon, and it is very likely to lower the amount of hardware drifts / clock jitter that may be available/accessible to a user-level program. While the clock chip is accessible directly from non-NT versions of Windows -- and thus the uncorrected values would be available -- building in such an expectation of being able to use it as a source of randomness implies more kernel-level mods / new installable-drivers for several commercial OSes. Additionally, it's not clear to me at all that the conjectured 3 bits of randomness is self-refreshing, i.e., whether it is used up on the first sampling or whether more randomness is available after one waits a while (and how long?). Clock chips may have spec'd variance within a batch, and certainly the clocks may drift over time (at some spec'd rate), but the variance over time in the rate of drift for a particular chip may be very small. Certainly the manufacturer specs only provide bounds that go the wrong way for this application! -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 Wed Apr 24 19:03:31 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id TAA22182 for ; Wed, 24 Apr 1996 19:03:31 -0400 Received: from odin.ucsd.edu by www10.w3.org (5.0/NSCS-1.0S) id AA11147; Wed, 24 Apr 1996 19:03:26 +0500 Received: from work.ucsd.edu by odin.ucsd.edu; id AA12876 sendmail 8.73/UCSDPSEUDO.4-CS via SMTP Wed, 24 Apr 96 16:03:16 -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 QAA10413; Wed, 24 Apr 1996 16:03:11 -0700 (PDT) Message-Id: <199604242303.QAA10413@work.ucsd.edu> To: Tatu Ylonen Cc: dpkemp@missi.ncsc.mil (David P. Kemp), ietf-tls@w3.org Reply-To: Bennet Yee Subject: Re: Merged Transport Layer Protocol Development In-Reply-To: Your message of "Thu, 25 Apr 1996 01:06:22 +0300." <199604242206.BAA07216@pilari.ssh.fi> Date: Wed, 24 Apr 1996 16:03:09 -0700 From: Bennet Yee content-length: 3978 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Actually, using the pre-encrypted data mechanism to handle hardware-encrypted data is *not* appropriate. The problem is as follows: the ChangeCipherSpec message is defined to send the key for the pre-encrypted data. If we want to claim that the encryption hardware is more secure than the host handling that connection, we should not trust the host to properly encrypt the hardware encryption key for transfer to the client either. Certainly if the hardware key is encrypted with the TLS session key, the security of (the pre-encrypted portion of) the channel is only as good as the worse of the two keys. As for the comment about Moore's law, I don't think we should rely on it to mask our inefficiencies. We -should- worry about it when we decide on things like key lengths, rather (but that's a different topic.) Yes, the pre-encrypted data idea is oriented towards reducing the load on heavily loaded servers that need security, not their clients -- that's precisely the scenario that I had drawn in the first message. While this is not a _general_ point-to-point transport security issue, running TLS on web servers _is_ the main application. (People who want to use TLS for secure telnet is unlikely to care -- though the pre-encrypted data mechanism can benefit that as well when used with a slow stream cipher.) Regarding the idea of renegotiating for NULL encryption when sending pre-encrypted data, that is not a good idea. The idea of providing the pre-encryption mechanism (also applies to the on-the-fly compression found in SSLv3) is to hide the complexity from the client. Yes, if client programs are all smart and understand when the data stream changes from normally encrypted traffic to pre-encrypted-and-NULL-encrypted traffic, things would work, but the point of providing the TLS abstraction is to hide such complexities from the clients. After all, the clients could just as well do their own crypto. > 1) How much time does the PCTv2 pre-encryption handshake save over > the standard SSLv3 resume-session handshake?, and These are apples and oranges. Resume session provides a means to avoid the public key crypto overhead while obtaining fresh session keys. These session keys are used to private-key encrypt the traffic. Because of the way these keys are derived, this mechanism forces on-the-fly encryption and decryption. The pre-encryption mechanism assumes session keys are in place, regardless of whether they were derived from a complete handshake or from a resumed session. The pre-encryption mechanism aims to avoid the private-key encryption overhead for data that is (re)transmitted to many parties by permitting "backend" encryption at the server (change keys once in a while when machine is lightly loaded, etc). > 2) if the answer to 1 is greater than epsilon, what analysis has been > done to show that the pre-encryption handshake does not introduce > new vulnerabilities to the protocol? The same kind of analysis that is due any security protocol -- review by security researchers/practitioners. I don't know whether enough has been done yet -- personally, I've looked at it for only a few hours (classes to teach, grants to apply for :), and haven't looked at the protocol as a whole at all (there may be interactions between how pre-encryption is handled and other parts of STLP.) I don't see anything wrong with the idea of making Web security technologies more scalable. It does not reduce the security from existing practice, and rather than just acting on fear that a particular design may be erroneous (which I believe isn't), I would hope that we instead look at exactly how much more complicated does it make the protocol (which I believe is "not significantly") and weigh the risks against the benefits. -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 dansimon@microsoft.com Wed Apr 24 19:13:19 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id TAA22211 for ; Wed, 24 Apr 1996 19:13:18 -0400 Received: from tide19.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA11176; Wed, 24 Apr 1996 19:13:18 +0500 Received: by tide19.microsoft.com with Microsoft Exchange (IMC 4.0.838.5) id <01BB31F8.F4D571A0@tide19.microsoft.com>; Wed, 24 Apr 1996 16:13:21 -0700 Message-Id: From: Dan Simon To: "'ietf-tls@w3.org'" Subject: RE: Merged Transport Layer Protocol Development Date: Wed, 24 Apr 1996 16:13:16 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit content-length: 4409 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls More responses to David Kemp's comments inserted below.... >---------- >From: dpkemp@missi.ncsc.mil[SMTP:dpkemp@missi.ncsc.mil] > >Mr. Yee suggests that pre-encrypting images can eliminate server >overhead for bulk crypto, but I don't see how. If you have a large >pre-encrypted file to transmit over SSL, then just renegotiate a >NULL-WITH-NULL CipherSpec before sending the file, and resume the >previous CipherSpec when it's done. The only overhead is for two >handshake exchanges, which shouldn't be a serious burden on the >server. There are two problems with this method: 1) The MAC key must therefore be transmitted along with the new encryption key, and can therefore be no stronger than the previous encryption key; and 2) Once MACing has been turned off in the underlying connection, there is no guarantee that an adversary can't intervene, block subsequent "change cipher spec" messages, and start sending/receiving other information to/from the parties (in the clear) when transmission of the pre-encrypted data stream has been completed. The method proposed in PCT v2, and in the STLP document, is to use the connection's established MAC key to authenticate pre-encrypted data, but to use a MAC method which still allows most of the MAC computation to be done in advance. In particular, the data to be authenticated is hashed once, and this result is then hashed again with the MAC key prepended. This MAC method defends against all of the attacks against which HMAC is designed to defend, and has only the one (known) drawback that a collision in the underlying hash function directly produces a collision in the MAC function. It has the advantage, however, that the "interior" hash computation can be performed in advance. (Note that the MAC must be computed on the encrypted data, since the plaintext is not necessarily available, and the MAC value itself will not be encrypted. This changed order has no security impact, but makes MAC precomputation infinitely easier to implement securely.) In PCT v2, a special "key management" message is used to transmit an encryption key to be used to decrypt pre-encrypted data, which is then authenticated as described above. (Another "key management" message restores the previous encryption key.) In the STLP document, it was proposed that the "change cipher spec" message be used for the same purpose. If that solution is unacceptable, then a compromise approach might be to change the MAC function as described above, and to implement pre-encrypted data support at the application level for encryption and at the protocol level for message authentication. In other words, the encryption key would be transmitted as application data, the cipher spec would then be switched (using an unmodified "change cipher spec" message) to null encryption with normal message authentication, and the pre-encrypted data would be transmitted as if unencrypted, with the precomputed interior hash values for MAC computation used to compute MACs quickly on the fly. >On the other hand, creating a totally separate set of handshake >messages to support pre-encrypted data is just another potential >place for security holes to pop up. I admit to not having studied >the PCT 2.0 pre-encryption specs in detail, but before spending time >doing so I'd like to see answers to the following: > >1) How much time does the PCTv2 pre-encryption handshake save over >the standard SSLv3 resume-session handshake?, and The answer to this question depends, of course, on the cost in CPU time of performing encryption and hashing. A ballpark figure might be on the order of a second per megabyte of data. This cost virtually disappears if the data is pre-encrypted and pre-hashed; if a single encrypted stream is accessed thousands of times a day, then I would say that the savings begin to add up. >2) if the answer to 1 is greater than epsilon, what analysis has been >done to show that the pre-encryption handshake does not introduce >new vulnerabilities to the protocol? > The PCT v2 spec has been fairly extensively reviewed, both internally and externally. The STLP document is, of course, a very rough sketch rather than a full spec, and would obviously need to undergo a great deal more scrutiny before any conclusions are drawn about its security properties. Daniel Simon Cryptographer, Microsoft Corp. dansimon@microsoft.com > From dansimon@microsoft.com Wed Apr 24 20:03:43 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id UAA22910 for ; Wed, 24 Apr 1996 20:03:43 -0400 Received: from tide21.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA11358; Wed, 24 Apr 1996 20:03:42 +0500 Received: by tide21.microsoft.com with Microsoft Exchange (IMC 4.0.838.5) id <01BB3200.1EE8C260@tide21.microsoft.com>; Wed, 24 Apr 1996 17:04:38 -0700 Message-Id: From: Dan Simon To: "'ietf-tls@w3.org'" Subject: RE: Merged Transport Layer Protocol Development Date: Wed, 24 Apr 1996 17:03:43 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit content-length: 807 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls >From: Tatu Ylonen[SMTP:ylo@ssh.fi] > >I just wish to say that I also agree that special processing for >pre-encrypted data is a Bad Idea. A 90-MHz Pentium can encrypt fast >enought to completely fill an ethernet (the ethernet becomes the >limiting factor), and the processing speed is doubling every year. > >The overhead from encryption is negligible all but the most >high-volume servers connected to the Internet by something faster than >10Mbits/sec. (Unless you also do a lot of CPU-intensive processing >that competes for CPU.) My impression is that asymmetric decryptions of master keys require more than enough "CPU-intensive processing" to put CPU time at a premium in the typical high-volume secure server. Daniel Simon Cryptographer, Microsoft Corp. dansimon@microsoft.com > From ylo@ssh.fi Wed Apr 24 20:15:21 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id UAA22963 for ; Wed, 24 Apr 1996 20:15:20 -0400 Received: from muuri.ssh.fi (acr.innopoli.fi) by www10.w3.org (5.0/NSCS-1.0S) id AA11392; Wed, 24 Apr 1996 20:15:19 +0500 Received: from pilari.ssh.fi (pilari.ssh.fi [192.168.2.1]) by muuri.ssh.fi (8.7.5/8.7.3) with ESMTP id DAA21142; Thu, 25 Apr 1996 03:15:17 +0300 (EET DST) Received: (from ylo@localhost) by pilari.ssh.fi (8.7.5/8.7.3) id DAA10377; Thu, 25 Apr 1996 03:15:16 +0300 (EET DST) Date: Thu, 25 Apr 1996 03:15:16 +0300 (EET DST) Message-Id: <199604250015.DAA10377@pilari.ssh.fi> From: Tatu Ylonen To: Dan Simon Cc: "'ietf-tls@w3.org'" Subject: RE: Merged Transport Layer Protocol Development In-Reply-To: References: Organization: Helsinki University of Technology, Finland content-length: 370 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls > My impression is that asymmetric decryptions of master keys require more > than enough "CPU-intensive processing" to put CPU time at a premium in > the typical high-volume secure server. An RSA computation is on the order of 0.1 seconds on a typical server PC. That's not too bad, unless your application uses huge numbers of very short-lived connections. Tatu From daw@cs.berkeley.edu Wed Apr 24 22:02:13 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id WAA23515 for ; Wed, 24 Apr 1996 22:02:13 -0400 Received: from joseph.cs.berkeley.edu by www10.w3.org (5.0/NSCS-1.0S) id AA11704; Wed, 24 Apr 1996 22:02:11 +0500 Received: (from daw@localhost) by joseph.cs.berkeley.edu (8.6.12/8.6.9) id TAA00508; Wed, 24 Apr 1996 19:02:09 -0700 To: ietf-tls@w3.org Path: not-for-mail From: daw@cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-tls Subject: Re: Merged Transport Layer Protocol Development Date: 24 Apr 1996 19:02:02 -0700 Organization: ISAAC Group, UC Berkeley Lines: 28 Message-Id: <4lmmeq$fq@joseph.cs.berkeley.edu> References: <199604242216.PAA07915@work.ucsd.edu> content-length: 1198 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls In article <199604242216.PAA07915@work.ucsd.edu>, Bennet Yee wrote: > In message om>, Dan Simon writes: > > UNIX time was not removed so that challenges would be more random, but > > rather to preserve available randomness resources. UNIX time on a > > machine may reasonably be expected to contain, say, 3 bits of entropy, > > if not sampled too often. > > All modern Unix systems provide the time on the daytime port [...] > Furthermore, many machines use the Network Time Protocol [...] Good points, all of them. As Ian Goldberg & I have pointed out, there are still more ways the time can leak. For instance, Message-IDs often contain the time of day. (And you can usually force a targeted Unix machine to send you a Message-ID by sending it a message which will bounce.) This is pointed out in e.g. http://www.ddj.com/ddj/1996/1996.01/wagner.htm I think the clock skew between you & a target machine is not too hard to recover very accurately. I think it's dangerous to rely on there being any significant entropy in the time of day. Just my (conservative & paranoid) opinion, -- Dave Wagner From karlton@netscape.com Wed Apr 24 22:42:15 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id WAA23607 for ; Wed, 24 Apr 1996 22:42:14 -0400 Received: from ghoti.mcom.com (h-205-217-232-38.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA11767; Wed, 24 Apr 1996 22:42:13 +0500 Received: from ghoti (localhost [127.0.0.1]) by ghoti.mcom.com (940816.SGI.8.6.9/8.6.9) with SMTP id TAA16885; Wed, 24 Apr 1996 19:42:11 -0700 Sender: karlton@netscape.com Message-Id: <317EE682.794B@netscape.com> Date: Wed, 24 Apr 1996 19:42:10 -0700 From: Phil Karlton Organization: Netscape Communications X-Mailer: Mozilla 3.0b4 (X11; U; IRIX 5.3 IP22) Mime-Version: 1.0 To: David Wagner Cc: ietf-tls@w3.org Subject: Re: Merged Transport Layer Protocol Development References: <199604242216.PAA07915@work.ucsd.edu> <4lmmeq$fq@joseph.cs.berkeley.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 1668 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls > I think the clock skew between you & a target machine is not too hard to > recover very accurately. I think it's dangerous to rely on there being > any significant entropy in the time of day. The time of day is in the Random structure for SSL 3 for three reasons: 1) It reduces the probability that any particular Random will be reused. As long as sessions are not being established (or reestablished) more frequently than once a second, then there is a logical sequence number as part of the structure. 2) Keeping a reasonably accurate time-of-day clock on the client's and servers is important. For instance, typical certificates are only good for 6 months. If the user never sets the clock on the client or server machine, then even the checks for certificates being current will fail. Some error checking for egregiousl bad values can be done. 3) The value of the time-of-day should be made available through the API. For applications that need more protection from replay attacks, there would be the ability to make sure that the nonce's are relatively current. This may not be feasible for all applications at this point, but we should be able to make use of this as time progresses. 28 bytes of random (or nearly random) data should be be sufficient for establishing keys with 16 bytes of entropy. I strongly recommend that the time not be removed from the Random structure. PK -- Philip L. Karlton karlton@netscape.com Principal Curmudgeon http://home.netscape.com/people/karlton Netscape Communications They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin From ericm@lne.com Wed Apr 24 22:50:02 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id WAA23773 for ; Wed, 24 Apr 1996 22:50:01 -0400 Received: from slack.lne.com by www10.w3.org (5.0/NSCS-1.0S) id AA11792; Wed, 24 Apr 1996 22:49:49 +0500 Received: (from ericm@localhost) by slack.lne.com (8.7.1/1.0) id TAA30785; Wed, 24 Apr 1996 19:49:39 -0700 From: Eric Murray Message-Id: <199604250249.TAA30785@slack.lne.com> Subject: Re: Merged Transport Layer Protocol Development To: daw@cs.berkeley.edu (David Wagner) Date: Wed, 24 Apr 1996 19:49:37 -0700 (PDT) Cc: ietf-tls@w3.org In-Reply-To: <4lmmeq$fq@joseph.cs.berkeley.edu> from "David Wagner" at Apr 24, 96 07:02:02 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit content-length: 2187 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls David Wagner writes: > > In article <199604242216.PAA07915@work.ucsd.edu>, > Bennet Yee wrote: > > In message > om>, Dan Simon writes: > > > UNIX time was not removed so that challenges would be more random, but > > > rather to preserve available randomness resources. UNIX time on a > > > machine may reasonably be expected to contain, say, 3 bits of entropy, > > > if not sampled too often. > > > > All modern Unix systems provide the time on the daytime port [...] > > Furthermore, many machines use the Network Time Protocol [...] > > Good points, all of them. > > As Ian Goldberg & I have pointed out, there are still more ways the time > can leak. For instance, Message-IDs often contain the time of day. (And > you can usually force a targeted Unix machine to send you a Message-ID by > sending it a message which will bounce.) > > This is pointed out in e.g. > http://www.ddj.com/ddj/1996/1996.01/wagner.htm > > I think the clock skew between you & a target machine is not too hard to > recover very accurately. I think it's dangerous to rely on there being > any significant entropy in the time of day. On the other hand, it doesn't hurt to use it, if you already have enough unguessable truly random bits. Adding guessable bits to a series of unguessable ones doesn't make them any more guessable. But since it doesn't add anything, it shouldn't be there. Rather than arguing about including the (useless) time value in the {client,server}-random value, should we specify how random and unguessable the bits that go into them should be? That's what we really care about, rather than the method(s) that might be used to get those random bits. Those methods are varied and are liable to be non-portable. However specifying the right amount of unguessable randomness might become distracting from the main purpose of coming up with a TLS spec. Perhaps we can just say "pick good random numbers, see RFC 1750". -- 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 ericm@lne.com Wed Apr 24 23:23:22 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id XAA23878 for ; Wed, 24 Apr 1996 23:23:22 -0400 Received: from slack.lne.com by www10.w3.org (5.0/NSCS-1.0S) id AA11882; Wed, 24 Apr 1996 23:23:17 +0500 Received: (from ericm@localhost) by slack.lne.com (8.7.1/1.0) id UAA31092; Wed, 24 Apr 1996 20:23:09 -0700 From: Eric Murray Message-Id: <199604250323.UAA31092@slack.lne.com> Subject: Re: Merged Transport Layer Protocol Development To: dansimon@microsoft.com (Dan Simon) Date: Wed, 24 Apr 1996 20:23:09 -0700 (PDT) Cc: ietf-tls@w3.org In-Reply-To: from "Dan Simon" at Apr 24, 96 05:03:43 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit content-length: 2776 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Dan Simon writes: > > >From: Tatu Ylonen[SMTP:ylo@ssh.fi] > > > >I just wish to say that I also agree that special processing for > >pre-encrypted data is a Bad Idea. A 90-MHz Pentium can encrypt fast > >enought to completely fill an ethernet (the ethernet becomes the > >limiting factor), and the processing speed is doubling every year. > > > >The overhead from encryption is negligible all but the most > >high-volume servers connected to the Internet by something faster than > >10Mbits/sec. (Unless you also do a lot of CPU-intensive processing > >that competes for CPU.) > > My impression is that asymmetric decryptions of master keys require more > than enough "CPU-intensive processing" to put CPU time at a premium in > the typical high-volume secure server. We seem to have come to an impasse- Tatu's impression vs. Dans. I'd guess that both are correct for the situations they have in mind. My suggestion would be that the current spec (SSL3) has a method already, as someone else has proposed, to enable sending pre-encrypted data by changing the cipherspec to RSA_WITH_NULL_SHA or RSA_WITH_NULL_MD5 or even NULL_WITH_NULL_NULL and sending the pre-encrypted data unencrypted by the TLS layer. Yes, if the preencrypted data has been encrypted by something stronger than TLS offers, and the key is sent via a TLS session, then the TLS session becomes the weakest part of the link. I'm not sure that's really a big problem. First off, more than one proposal for TLS-type protocols have included triple-DES as a symmetric cipher choice. If I'm not mistaken, triple-DES is the strongest commonly-available symmetric cipher. So the preencrypted data key would, if one used the best possible TLS ciphertypes, be as secure as the preencrypted data itself. Secondly, the suggested MAC method to allow some pre-calculation of the MAC is not as secure as the Krawczyk method used in SSL3 (and I would presume STLP). So, I'm not sure that sending the pre-encrypted data's key via TLS is any weaker than the preencrypted data itself, and I do see a problem with using a weaker MAC method. On the other hand, SSL already has a method to deal with preencrypted data, although it's not as streamlined as some would like. My opinion would be that the cost of adding more to the protocol (time spent arguing about it here, plus time taken to comb over it looking for possible security holes) isn't worth the gains in this case. It's worth thinking about later as an addition to the TLS protocol, but I'd rather see this WG get out something basic that works soon instead of something complicated later. -- 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 tomw@netscape.com Thu Apr 25 01:58:29 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id BAA24248 for ; Thu, 25 Apr 1996 01:58:28 -0400 Received: from urchin.netscape.com (h-198-95-250-59.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA12188; Thu, 25 Apr 1996 01:58:27 +0500 Received: from ammodump (ammodump.mcom.com [205.217.232.97]) by urchin.netscape.com (8.6.12/8.6.9) with SMTP id WAA13720 for ; Wed, 24 Apr 1996 22:59:14 -0700 Sender: tomw@netscape.com Message-Id: <317F147A.237C@netscape.com> Date: Wed, 24 Apr 1996 22:58:18 -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: 1110 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Dan Simon wrote: > > UNIX time was not removed so that challenges would be more random, but > rather to preserve available randomness resources. UNIX time on a > machine may reasonably be expected to contain, say, 3 bits of entropy, > if not sampled too often. This may not sound like much, but when > you're trying to harvest entropy from a PC for psuedorandom generator > seeding, you need every bit you can scrounge. Publicizing this value > on a regular basis takes away its value as a contributor to this > process. On the other hand, given the ease (and frequency) with which > time is reset on many machines, its value as a source of pure > non-repeatability for challenges (as opposed to randomness) is, in my > view, negligible. In my view, it's a very bad idea to rely on the clock as a source of randomness. Just because some PCs can't keep time accurately is no reason to depend on it. Who knows, maybe in the future even PCs will be using NTP. -- Sure we spend a lot of money, but that doesn't mean | Tom Weinstein we *do* anything. -- Washington DC motto | tomw@netscape.com From tomw@netscape.com Thu Apr 25 02:21:17 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id CAA24328 for ; Thu, 25 Apr 1996 02:21:17 -0400 Received: from urchin.netscape.com (h-198-95-250-59.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA12243; Thu, 25 Apr 1996 02:21:15 +0500 Received: from ammodump (ammodump.mcom.com [205.217.232.97]) by urchin.netscape.com (8.6.12/8.6.9) with SMTP id XAA14080 for ; Wed, 24 Apr 1996 23:22:05 -0700 Sender: tomw@netscape.com Message-Id: <317F19D8.2F1C@netscape.com> Date: Wed, 24 Apr 1996 23:21:12 -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: Password Authentication (was RE: Merged Transport Layer Protocol Development) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 1915 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Dan Simon wrote: > > To me, the issue is not whether password authentication is weaker than > authentication by certified asymmetric key; most everyone would agree > that this is the case. Unfortunately, for reasons ranging from > established practice to portability issues to plain ignorance, many > people will likely continue to use passwords for authentication for > some time to come, whether protocol authors want them to or not. The > issue at hand is therefore whether password-based authentication must > continue to be as weak as the encryption available (which is often, as > we all know, woefully weak), or whether, by our protocol design > choices, we can make the security of password authentication as strong > as it can possibly be. > > Nobody advocates forcing people to use passwords (even if it were > possible to do so). The question is whether we can force them not to, > and what to do given that we can't. Anyone who doesn't trust > password-based security is always free not to support it; in fact, it > takes an explicit decision by both parties to share a password before > password authentication even becomes possible. People who make that > decision are, in my view, no different from those who accept 40-bit > encryption, or proprietary, relatively unstudied RC4 over > heavily-analyzed (triple-)DES; we cryptographers might prefer that > they choose otherwise, but we recognize that security must sometimes > yield to other practical priorities. I have to agree with Mr. Kemp. Passwords for purposes of authentication do not belong in a protocol that claims to provide cryptographic security. If you really want to use passwords, you can always do it in an application level protocol. What's wrong with public key cryptography? -- Sure we spend a lot of money, but that doesn't mean | Tom Weinstein we *do* anything. -- Washington DC motto | tomw@netscape.com From <@heap.ben.algroup.co.uk:ben@gonzo.ben.algroup.co.uk> Thu Apr 25 09:22:48 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id JAA26668 for ; Thu, 25 Apr 1996 09:22:47 -0400 Received: from arachnet.algroup.co.uk by www10.w3.org (5.0/NSCS-1.0S) id AA13203; Thu, 25 Apr 1996 09:22:44 +0500 Received: from heap.ben.algroup.co.uk by arachnet.algroup.co.uk id aa17388; 25 Apr 96 14:22 BST Received: from gonzo.ben.algroup.co.uk by heap.ben.algroup.co.uk id aa23241; 25 Apr 96 13:50 BST Subject: Re: issues with the charter (fwd) To: ietf-tls@w3.org Date: Thu, 25 Apr 1996 13:46:14 +0100 (BST) From: Ben Laurie Reply-To: ben@algroup.co.uk X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1285 Message-Id: <9604251346.aa21313@gonzo.ben.algroup.co.uk> X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Whoops ... looks like I forgot to cc: the original, and hence Paul's reply, to the list - so here it is: Paul Hoffman wrote: > Ben Laurie wrote: > >I've been following the discussion about UDP and, frankly, I'm puzzled. Surely > >the type of security that this WG is talking about involves handshaking. In > >this case there must surely be some concept of sequencing, or at least > >reliable > >transport, at the transport layer to support the handshake? If this is the > >case, then there seems little point in duplicating what TCP already does for > >us. If this is not the case, then we must be talking about some kind of > >one-way > >security/authentication in which case all the necessary data must be packed > >into a single packet. Surely that's going to be one very big packet? > > Er, good point here. I was thinking on the level of "what I want this to > do", not "will this protocol even support it". It would be nice to have > secure UDP, but if it means lots of SSL-like handshakes, maybe we have to > wait for secure IP. > > -- Ben Laurie Phone: +44 (181) 994 6435 Freelance Consultant and Fax: +44 (181) 994 6472 Technical Director Email: ben@algroup.co.uk A.L. Digital Ltd, URL: http://www.algroup.co.uk London, England. From bsy@work.ucsd.edu Thu Apr 25 11:10:45 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id LAA27283 for ; Thu, 25 Apr 1996 11:10:45 -0400 Received: from odin.ucsd.edu by www10.w3.org (5.0/NSCS-1.0S) id AA13647; Thu, 25 Apr 1996 11:10:42 +0500 Received: from work.ucsd.edu by odin.ucsd.edu; id AA17920 sendmail 8.73/UCSDPSEUDO.4-CS via SMTP Thu, 25 Apr 96 08:10:37 -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 IAA29498 for ; Thu, 25 Apr 1996 08:10:31 -0700 (PDT) Message-Id: <199604251510.IAA29498@work.ucsd.edu> To: ietf-tls@w3.org Reply-To: Bennet Yee Subject: time as a source of randomness Date: Thu, 25 Apr 1996 08:10:29 -0700 From: Bennet Yee content-length: 2221 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls I think we (myself included) were confusing two issues. (1) The use of a one-second resolution timestamp as a somewhat random nonce in a protocol (e.g., SSLv3), and (2) the amount of entropy available from a clock for use in crytographically secure pseudo-random number (CSPRNG) generator seeding. My mistake was in assuming the one-second resolution (as from SSLv3) also applied in estimating the available entropy. With PCs the architecture of which has been determine by the DOS traps' semantics, the hardware clock is going to have a resolution of 1/100th of a second, and this is the resolution with which a CSPRNG seeding function may measure. (Workstations vary, of course, but typically have at least that resolution.) I am still not assured, however, that the estimated 3 bits of entropy is self-refreshing; nor am I convinced that systems, whether Unix or Windows or whatever OS, wouldn't leak the (more precise) time value through other means anyway. Other values such as processor counters (Alpha's cycle counter, Pentium's processor statistics counters, etc) are likely to be a much richer source of entropy, since these values are much less likely to be revealed to a network-based adversary as part of normal operation. Phil argued that the time value's use in SSLv3 is not so much for a true nonce but just as a counter that is unlikely to repeat. This is a much weaker property on which to base a protocol: unlike nonces, such a counter is predictable. My rule of thumb is that security can not derive from a predictable counter in this way unless the source of the counter value somehow validates it (e.g., signs it -- and even then it's replayable), but I haven't studied how it's used in the original SSLv3 protocol carefully. Time to kill a few more trees. (Sorry about resending a dup msg earlier -- I had assumed that email that I send to the list would also be sent back to me since I am a member of the mailing list [which would also serve as an ack, much as Return-Receipt-To would.]) -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 dpkemp@missi.ncsc.mil Thu Apr 25 11:52:25 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id LAA27457 for ; Thu, 25 Apr 1996 11:52:25 -0400 Received: from guardian.guard.ncsc.mil by www10.w3.org (5.0/NSCS-1.0S) id AA13831; Thu, 25 Apr 1996 11:52:24 +0500 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id LAA26235 for ; Thu, 25 Apr 1996 11:52:39 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma026232; Thu Apr 25 11:52:18 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 LAA02966 for ; Thu, 25 Apr 1996 11:48:26 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id LAA18569; Thu, 25 Apr 1996 11:52:08 -0400 Date: Thu, 25 Apr 1996 11:52:08 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199604251552.LAA18569@argon.ncsc.mil> To: ietf-tls@w3.org Subject: RE: Merged Transport Layer Protocol Development X-Sun-Charset: US-ASCII content-length: 2435 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls From: Dan Simon Date: Wed, 24 Apr 1996 16:13:16 -0700 > There are two problems with this method: [negotiating NULL-WITH-NULL then resuming encryption - dpk] > > 1) The MAC key must therefore be transmitted along with the new > encryption key, and can therefore be no stronger than the previous > encryption key; and > > 2) Once MACing has been turned off in the underlying connection, there > is no guarantee that an adversary can't intervene, block subsequent > "change cipher spec" messages, and start sending/receiving other > information to/from the parties (in the clear) when transmission of the > pre-encrypted data stream has been completed. I don't understand these objections. The initial state of an SSL connection is NULL-WITH-NULL (no) security. The handshake proceeds from that state to a non-NULL CipherSuite in a manner that I believe to be immune to known protocol attacks. If that weren't the case, then the initial MAC key would be "no stronger than the previous encryption key", i.e. zero. The finished message (which authenticates all prior handshake messages) is an important component of preventing problem 2). If there is a protocol weakness in the SSL handshake that causes it to be subject to problems 1) and 2), then it affects all of SSL, not just using the handshake to accommodate pre-encrypted data. I am not aware of any such weakness. > >1) How much time does the PCTv2 pre-encryption handshake save over > >the standard SSLv3 resume-session handshake?, and > > The answer to this question depends, of course, on the cost in CPU time > of performing encryption and hashing. A ballpark figure might be on the > order of a second per megabyte of data. This cost virtually disappears > if the data is pre-encrypted and pre-hashed; if a single encrypted > stream is accessed thousands of times a day, then I would say that the > savings begin to add up. The cost of the handshake does not depend on the amount of data subsequently protected by it (i.e. the size of the pre-encrypted, pre-hashed file). The cost is fixed, and is incurred once each time the CipherSpec is renegotiated (at worst, twice for each pre-encrypted file; less if multiple pre-encrypted files are sent in a row). I believe the processor cost of a resume handshake to be fairly small; the 2 round trips might cause a slight communication delay but shouldn't affect the server load. From freier@netscape.com Thu Apr 25 13:23:59 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id NAA28714 for ; Thu, 25 Apr 1996 13:23:58 -0400 Received: from cynic.mcom.com (h-205-217-235-59.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA14275; Thu, 25 Apr 1996 13:23:57 +0500 Received: from cynic (localhost [127.0.0.1]) by cynic.mcom.com (950511.SGI.8.6.12.PATCH526/8.6.9) with SMTP id KAA05568; Thu, 25 Apr 1996 10:23:55 -0700 Sender: freier@netscape.com Message-Id: <317FB52A.102F@netscape.com> Date: Thu, 25 Apr 1996 10:23:54 -0700 From: Alan Freier Organization: Netscape Communications X-Mailer: Mozilla 3.0b3 (X11; U; IRIX 5.3 IP22) Mime-Version: 1.0 To: ietf-tls@w3.org Subject: Re: time as a source of randomness References: <199604251510.IAA29498@work.ucsd.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 1000 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls There seems to be divergence from the issue here. SSL 3.0 never intended time to be a source of randomness. In a more perfect world, those four bytes would be absolutely predictable. It is only the imperfections of the current OSs and networks that make it not so. During the development of the SSL 3.0 specification, it was observed that 28 bytes would be sufficient as a random value for the purpose at hand, and that is still believed that to be true. The extra four bytes, from SSL's point of view, are simply carried along as a convenience to its clients, though SSL purposely does not indicate what the client might do with the information. To the best of my knowledge, adding 4 predictable bytes to 28 (nearly) unpredictable bytes leaves you with 28 (nearly) unpredictable bytes. If someone believes that 28 bytes is not sufficient, then that would be an issue. I haven't heard anybody making such a claim. -- Alan O. Freier Corporate Cynic (415) 937-3638 (work) From dpkemp@missi.ncsc.mil Thu Apr 25 13:27:32 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id NAA28746 for ; Thu, 25 Apr 1996 13:27:31 -0400 Received: from guardian.guard.ncsc.mil by www10.w3.org (5.0/NSCS-1.0S) id AA14287; Thu, 25 Apr 1996 13:27:30 +0500 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id NAA26636 for ; Thu, 25 Apr 1996 13:27:46 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma026633; Thu Apr 25 13:27:25 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 NAA03303 for ; Thu, 25 Apr 1996 13:23:41 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id NAA18598; Thu, 25 Apr 1996 13:27:23 -0400 Date: Thu, 25 Apr 1996 13:27:23 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199604251727.NAA18598@argon.ncsc.mil> To: ietf-tls@w3.org Subject: Re: Password Authentication X-Sun-Charset: US-ASCII content-length: 2395 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls From: Dan Simon Date: Wed, 24 Apr 1996 12:50:49 -0700 >To me, the issue is not whether password authentication is weaker than >authentication by certified asymmetric key; most everyone would agree >that this is the case. Unfortunately, for reasons ranging from >established practice to portability issues to plain ignorance, many >people will likely continue to use passwords for authentication for >some time to come, whether protocol authors want them to or not. The >issue at hand is therefore whether password-based authentication must >continue to be as weak as the encryption available (which is often, as >we all know, woefully weak), or whether, by our protocol design >choices, we can make the security of password authentication as strong >as it can possibly be. No matter how weak the encryption is (40 bits :-), passwords are always going to be weaker. How many people do you know who pick 8 character passwords having even 24 bits of entropy? If you rely on shared secret passwords to establish encryption or MAC keys, the protocol design has done nothing to strengthen anything but the perception of security. On the other hand, if you use certificate authentication and 3DES encryption at the Transport layer, then it may be perfectly acceptable for many applications to use password authentication **at the application layer** for finer-grained access control. >Nobody advocates forcing people to use passwords (even if it were >possible to do so). The question is whether we can force them not to, >and what to do given that we can't. We can refuse to create an IETF-standard transport layer protocol that allows password authentication. If there is enough of a market, I'm sure some enterprising company would introduce non-standard extensions to allow 24 bit privacy, and another company would follow suit if they felt competitive pressure to do so. At that point, the IETF standard might be updated to accommodate the sorry state of existing practice. But I believe that it will soon be easier to generate and use certificates than it will be to pick, remember, and type passwords. "Build it, and they will come." There are obviously strongly-held opinions on both sides. I hope the working group can establish rough consensus on this issue and include the decision in the charter relatively quickly, to avoid prolonging the debate. From bsy@work.ucsd.edu Thu Apr 25 13:47:45 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id NAA29082 for ; Thu, 25 Apr 1996 13:47:45 -0400 Received: from odin.ucsd.edu by www10.w3.org (5.0/NSCS-1.0S) id AA14386; Thu, 25 Apr 1996 13:47:43 +0500 Received: from work.ucsd.edu by odin.ucsd.edu; id AA25845 sendmail 8.73/UCSDPSEUDO.4-CS via SMTP Thu, 25 Apr 96 10:47:37 -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 KAA10949; Thu, 25 Apr 1996 10:47:36 -0700 (PDT) Message-Id: <199604251747.KAA10949@work.ucsd.edu> To: dpkemp@missi.ncsc.mil (David P. Kemp) Cc: ietf-tls@w3.org Reply-To: Bennet Yee Subject: Re: Password Authentication In-Reply-To: Your message of "Thu, 25 Apr 1996 13:27:23 -0400." <199604251727.NAA18598@argon.ncsc.mil> Date: Thu, 25 Apr 1996 10:47:34 -0700 From: Bennet Yee content-length: 654 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls I agree with most of your points about passwords. However, the scenario that you draw about extensions would imply that we should think about mechanisms by which extensions to TLS may be made cleanly -- reserve some record type numbers that are vendor-specific, and mandate that the rest be not used except as officially sanctioned blah blah blah when/if TLS gets revised. If we don't do this, then we risk creating compatibility problems in the future. -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 dpkemp@missi.ncsc.mil Thu Apr 25 14:27:36 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id OAA29281 for ; Thu, 25 Apr 1996 14:27:35 -0400 Received: from guardian.guard.ncsc.mil by www10.w3.org (5.0/NSCS-1.0S) id AA14532; Thu, 25 Apr 1996 14:27:34 +0500 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id OAA26860; Thu, 25 Apr 1996 14:27:49 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma026857; Thu Apr 25 14:27:35 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 OAA03479; Thu, 25 Apr 1996 14:23:52 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id OAA18616; Thu, 25 Apr 1996 14:27:34 -0400 Date: Thu, 25 Apr 1996 14:27:34 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199604251827.OAA18616@argon.ncsc.mil> To: ietf-tls@w3.org, dansimon@microsoft.com Subject: RE: Merged Transport Layer Protocol Development X-Sun-Charset: US-ASCII content-length: 4036 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls From: Dan Simon Date: Wed, 24 Apr 1996 10:50:29 -0700 > The new PPTP protocol for tunnelling PPP over the Internet specifies a > TCP channel for control messages and IP for bulk data transmission. > I'm not familiar with how they specify managing the two channels > separately, but they presumably have something in mind. This complicates matters considerably for firewalls. FTP is "firewall-unfriendly" because it uses separate control and data channels, both of which are TCP connections. Allowing UDP would make the proxy's job even more difficult. Other than that, I don't have a philosophical objection to TLS-UDP. But the first draft should document existing practice, which is TCP only. A second or separate parallel draft could discuss UDP extensions, which would be the basis for implementations with which people could gain operational experience. > UNIX time was not removed so that challenges would be more random, but > rather to preserve available randomness resources. UNIX time on a > machine may reasonably be expected to contain, say, 3 bits of entropy, > if not sampled too often. This may not sound like much, but when > you're trying to harvest entropy from a PC for psuedorandom generator > seeding, you need every bit you can scrounge. Publicizing this value > on a regular basis takes away its value as a contributor to this > process. On the other hand, given the ease (and frequency) with which > time is reset on many machines, its value as a source of pure > non-repeatability for challenges (as opposed to randomness) is, in my > view, negligible. It's amazing how environment colors perception. I am used to an environment (Fortezza) with a true noise-based random number generator, so I didn't even consider the possibility of leaking time poisoning the random number generator for other uses where randomness really counts. Nonetheless, as others have pointed out, time leaks out in lots of other ways, and it's probably not a good idea to rely on it for even 3 bits of entropy. It doesn't hurt to include it, but it won't help if the clock is either transmitted or synchronized using NTP. http://home.netscape.com/eng/mozilla/2.01/relnotes/windows-2.01.html says: "... We have significantly increased the amount of random information from approximately 30 bits to approximately 300 bits. Netscape has greatly expanded the techniques and sources used to generate these amounts of random information, and the fixes have been reviewed and validated by several weeks of intensive testing on the Internet." Based on this statement, it would appear possible to scrounge up a reasonable amount of entropy, even on a single-user PC, without resorting to using the clock. Certainly it is easy to reset the clock, but in most circumstances people want it to bear some relation to real time (unless they are trying to circumvent time-based software licensing restrictions :-). In the normal environment, where a certificate may be valid for one or more years and users aren't fooling around, the clock is useful as a source of non-repeatability. Philip Karlton mentioned two other reasons for including time in the nonces - rough clock checks for certificate validity periods, and checking for nonce freshness. This may be useful for debugging purposes if nothing else - ("hey dummy, your machine thinks it's Jan 2, 2038 - no wonder it thinks my cert is expired"). >> 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 >> :-) > > If a key is used long enough for a 32-bit sequence number to wrap, then > it should be discarded and a new one renegotiated. This point is made > explicitly in the PCT specs. I'm convinced. I withdraw the objection. From hallam@w3.org Thu Apr 25 14:38:43 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id OAA29475 for ; Thu, 25 Apr 1996 14:38:43 -0400 Received: from zorch.w3.org by www10.w3.org (5.0/NSCS-1.0S) id AA14593; Thu, 25 Apr 1996 14:38:41 +0500 Received: from localhost by zorch.w3.org; (5.65/1.1.8.2/07Jul95-1014AM) id AA00749; Thu, 25 Apr 1996 14:38:39 -0400 Sender: hallam@zorch.w3.org Message-Id: <317FC6AF.41C6@w3.org> Date: Thu, 25 Apr 1996 14:38:39 -0400 From: "Phillip M. Hallam-Baker" X-Mailer: Mozilla 2.0 (X11; I; OSF1 V3.2 alpha) Mime-Version: 1.0 To: ietf-tls@w3.org Subject: Passwords an security. X-Url: http://lists.w3.org/Archives/Public/ietf-tls/msg00080.html Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 689 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls There have been a number of posts to the list that cause me some concern. In particular there appears to be a possible confusion as to the cryptographic security of password based systems. Passwords are a key management issue. The various human factors problems with passwords are well known but they are convenient and people use them. There are cryptographically secure methods of implementing both symmetric and asymmetric auhentication systems. Asymmetric key offers more flexibility but at lower performance. Most useful systems involve a hybrid. S-HTTP uses asymmetric key exchange to establish a shared secret which can then be used for future transimission. Phill Hallam-Baker From tomw@netscape.com Thu Apr 25 16:34:04 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id QAA02501 for ; Thu, 25 Apr 1996 16:34:04 -0400 Received: from urchin.netscape.com (h-198-95-250-59.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA15369; Thu, 25 Apr 1996 16:34:02 +0500 Received: from ammodump (ammodump.mcom.com [205.217.232.97]) by urchin.netscape.com (8.6.12/8.6.9) with SMTP id NAA02057; Thu, 25 Apr 1996 13:34:37 -0700 Sender: tomw@netscape.com Message-Id: <317FE19C.41C6@netscape.com> Date: Thu, 25 Apr 1996 13:33:32 -0700 From: Tom Weinstein Organization: Netscape Communications, Inc. X-Mailer: Mozilla 3.0b4 (X11; U; IRIX 5.3 IP22) Mime-Version: 1.0 To: "Phillip M. Hallam-Baker" Cc: ietf-tls@w3.org Subject: Re: Passwords an security. References: <317FC6AF.41C6@w3.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 901 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Phillip M. Hallam-Baker wrote: > > There have been a number of posts to the list that cause me some > concern. In particular there appears to be a possible confusion as to > the cryptographic security of password based systems. Passwords are a > key management issue. The various human factors problems with > passwords are well known but they are convenient and people use them. > > There are cryptographically secure methods of implementing both > symmetric and asymmetric auhentication systems. Asymmetric key offers > more flexibility but at lower performance. Most useful systems involve > a hybrid. S-HTTP uses asymmetric key exchange to establish a shared > secret which can then be used for future transimission. Which is exactly what SSL does. -- Sure we spend a lot of money, but that doesn't mean | Tom Weinstein we *do* anything. -- Washington DC motto | tomw@netscape.com From dansimon@microsoft.com Thu Apr 25 16:42:20 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id QAA02816 for ; Thu, 25 Apr 1996 16:42:20 -0400 Received: from abash1.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA15437; Thu, 25 Apr 1996 16:42:19 +0500 Received: by abash1.microsoft.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB32AD.0DCA18A0@abash1.microsoft.com>; Thu, 25 Apr 1996 13:42:32 -0700 Message-Id: From: Dan Simon To: "'Eric Murray'" Cc: "'ietf-tls@w3.org'" Subject: RE: Merged Transport Layer Protocol Development Date: Thu, 25 Apr 1996 13:42:15 -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: 3888 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls > >From: Eric Murray[SMTP:ericm@lne.com] > >My suggestion would be that the current spec (SSL3) has >a method already, as someone else has proposed, to >enable sending pre-encrypted data by changing the cipherspec >to RSA_WITH_NULL_SHA or RSA_WITH_NULL_MD5 or >even NULL_WITH_NULL_NULL and sending the pre-encrypted >data unencrypted by the TLS layer. If this solution (NULL_SHA or NULL_MD5) is used, then the MAC must be computed (as I mentioned) on the ciphertext rather than the plaintext, since the cleartext will not be available for MACing. And if pre-MACing is to be made possible, then the MAC method must be changed from HMAC to the one I described. >Yes, if the preencrypted data has been encrypted by something >stronger than TLS offers, and the key is sent via a TLS session, then >the TLS session becomes the weakest part of the link. I'm not >sure that's really a big problem. First off, more than one >proposal for TLS-type protocols have included triple-DES >as a symmetric cipher choice. If I'm not mistaken, triple-DES >is the strongest commonly-available symmetric cipher. So the >preencrypted data key would, if one used the best possible TLS >ciphertypes, be as secure as the preencrypted data itself. >Secondly, the suggested MAC method to allow some pre-calculation >of the MAC is not as secure as the Krawczyk method used in SSL3 >(and I would presume STLP). Interestingly enough, the authors of SSL seem to disagree; the most sensitive MAC in their entire protocol (the "handshake hash") is computed with the MAC key appended to the *end* of the authenticated data in the interior hash invocation, rather than prepended at the beginning, as in HMAC. This alteration renders the MAC method virtually indistinguishable, cryptographically speaking, from the one I proposed; in particular, if the underlying hash function is not collision-intractable, then this handshake hash, as well, will be vulnerable to collision attacks. The reason for their modification of the MAC method in this case is obvious: to avoid having to keep all the handshake messages around until the MAC key is exchanged. The overhead would have been minor (compared to the cost of repeatedly encrypting huge data streams), but it was enough to prompt the "weakening" of the MAC method in this case. Personally, I agree with this decision, because I believe the modified MAC method to be quite sufficiently secure--much, *much* more so than, say, the effectively 40-bit-key-based MACs that would typically result if pre-MAC keys had to be sent at the application layer, as suggested by some opponents of explicit support for pre-encrypted data. >So, I'm not sure that sending the pre-encrypted data's key >via TLS is any weaker than the preencrypted data itself, and I do >see a problem with using a weaker MAC method. On the other hand, SSL >already has a method to deal with preencrypted >data, although it's not as streamlined as some would like. >My opinion would be that the cost of adding more to the protocol >(time spent arguing about it here, plus time taken to comb over >it looking for possible security holes) isn't worth the gains in >this case. It's worth thinking about later as an addition to >the TLS protocol, but I'd rather see this WG get out something basic >that works soon instead of something complicated later. > I'm confused. What is this method that SSL "already" has? As far as I can tell, what people have been proposing is that the security of the channel be turned off entirely to make way for pre-encrypted data (how the security properties are to be turned back on again, or how to protect the remainder of the connection from spoofing if they're not, is beyond me). Is this really more secure than the modification I proposed to the MAC function? Daniel Simon Cryptographer, Microsoft Corp. dansimon@microsoft.com > > > From dansimon@microsoft.com Thu Apr 25 16:44:30 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id QAA03337 for ; Thu, 25 Apr 1996 16:44:29 -0400 Received: from tide21.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA15474; Thu, 25 Apr 1996 16:44:27 +0500 Received: by tide21.microsoft.com with Microsoft Exchange (IMC 4.0.838.5) id <01BB32AD.120F6370@tide21.microsoft.com>; Thu, 25 Apr 1996 13:42:39 -0700 Message-Id: From: Dan Simon To: "'ietf-tls@w3.org'" , "'dpkemp@missi.ncsc.mil'" Subject: RE: Merged Transport Layer Protocol Development Date: Thu, 25 Apr 1996 13:42:30 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit content-length: 2095 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls > >From: dpkemp@missi.ncsc.mil[SMTP:dpkemp@missi.ncsc.mil] >From: Dan Simon >Date: Wed, 24 Apr 1996 16:13:16 -0700 > >> >1) How much time does the PCTv2 pre-encryption handshake save over >> >the standard SSLv3 resume-session handshake?, and >> >> The answer to this question depends, of course, on the cost in CPU time >> of performing encryption and hashing. A ballpark figure might be on the >> order of a second per megabyte of data. This cost virtually disappears >> if the data is pre-encrypted and pre-hashed; if a single encrypted >> stream is accessed thousands of times a day, then I would say that the >> savings begin to add up. > >The cost of the handshake does not depend on the amount of data >subsequently protected by it (i.e. the size of the pre-encrypted, >pre-hashed file). The cost is fixed, and is incurred once each time >the CipherSpec is renegotiated (at worst, twice for each pre-encrypted >file; less if multiple pre-encrypted files are sent in a row). >I believe the processor cost of a resume handshake to be fairly >small; the 2 round trips might cause a slight communication delay but >shouldn't affect the server load. What is apparently being proposed here is that pre-encrypted data be handled through a new handshake. If this is to be done, then the handshake itself must be modified to allow transmission of specific, fixed encryption and MAC keys, as opposed to the normal derivation process, which produces keys dependent on random challenges and the like. (The adapatation of the "change cipher spec" message in the STLP document is just such a modification.) Obviously, the addition of another public-key operation to the server's load should be avoided if possible; the natural solution is therefore to deliver the keys used for pre-encryption using keys exchanged and derived through a normal handshake. Hence the method used in PCT v2, and in the STLP document. Unless I've misunderstood the proposal, it sounds like we agree.... Daniel Simon Cryptographer, Microsoft Corp. dansimon@microsoft.com From dansimon@microsoft.com Thu Apr 25 16:44:49 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id QAA03390 for ; Thu, 25 Apr 1996 16:44:48 -0400 Received: from tide21.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA15482; Thu, 25 Apr 1996 16:44:47 +0500 Received: by tide21.microsoft.com with Microsoft Exchange (IMC 4.0.838.5) id <01BB32AD.191C0BA0@tide21.microsoft.com>; Thu, 25 Apr 1996 13:42:51 -0700 Message-Id: From: Dan Simon To: "'ietf-tls@w3.org'" , "'Tom Weinstein'" Subject: RE: Password Authentication (was RE: Merged Transport Layer Protocol Development) Date: Thu, 25 Apr 1996 13:42:41 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit content-length: 2618 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls > >From: Tom Weinstein[SMTP:tomw@netscape.com] > >I have to agree with Mr. Kemp. Passwords for purposes of >authentication >do not belong in a protocol that claims to provide cryptographic >security. If you really want to use passwords, you can always do it in >an application level protocol. > >What's wrong with public key cryptography? > Personally, I love public-key cryptography. Unfortunately, many people are not ready to convert to it yet, for at least two reasons I can think of offhand: there are entire infrastructures out there based on passwords, and people are loath to abandon them for a new technology that has had much less time to "settle"; and the technology for transporting asymmetric private keys to arbitrary trusted machines safely and conveniently is not yet widely available. Now, if I believed that the force of my eloquence could quickly convince them all to follow us cryptographers into a magnificent new era of public-key cryptography, then I would forget about trying to stick passwords into this working group's protocol. But I can't. And that means that passwords will continue to be widely used *regardless* of what we do. Moreover, a large fraction of those passwords will, for reasons we're all familiar with, be sent (or used to compute authentication responses sent) over connections only protected by 40-bit encryption keys. Passwords used in that manner are subject to offline brute-force attacks, first on the 40-bit encryption, then second (if necessary) on the password-based response. On the other hand, if we incorporate password authentication into the protocol, then we can protect those passwords by basing the challenge-response protocol on both the password and the automatically-strong MAC key exchanged during the handshake. This will protect the password from offline attacks, making even a poorly chosen password a useful security tool (assuming that it's kept secret, and that the server doesn't permit unlimited online trial-and-error attacks). That's still not as secure as public-key cryptography, of course. But it's better than what password users will have otherwise. And the cost to people who *don't* want to support or implement passwords is *zero*. No extra code, no extra administration, no extra security risk. Only the vague feeling of unease over somebody somewhere else getting a chance to make a security decision that they (and I, to some extent) disagree with. Now, what's wrong with *allowing* password authentication into the protocol? Daniel Simon Cryptographer, Microsoft Corp. dansimon@microsoft.com > > From mvanheyn@pellet.spry.com Thu Apr 25 17:35:12 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id RAA06426 for ; Thu, 25 Apr 1996 17:35:11 -0400 Received: from homer.spry.com by www10.w3.org (5.0/NSCS-1.0S) id AA15851; Thu, 25 Apr 1996 17:35:09 +0500 Received: from pellet.spry.com (pellet [198.185.1.189]) by homer.spry.com (8.6.9/8.6.9) with ESMTP id OAA09079; Thu, 25 Apr 1996 14:36:02 -0700 X-Mailer: exmh version 1.6.4 10/10/95 From: marcvh@spry.com (Marc VanHeyningen) To: Tom Weinstein Cc: ietf-tls@w3.org Subject: Re: Password Authentication (was RE: Merged Transport Layer Protocol Development) In-Reply-To: Your message of "Wed, 24 Apr 1996 23:21:12 PDT." <317F19D8.2F1C@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Apr 1996 14:31:06 -0700 Message-Id: <11351.830467866@pellet.spry.com> Sender: mvanheyn@pellet.spry.com content-length: 702 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls > What's wrong with public key cryptography? A great deal, but I'm sure you already know most of it. It's big, it's slow, it's expensive to license (for a few more years anyway), it requires an infrastructure that is not in place (partially due to licensing issues of the underlying technology), it presents usability issues (you can type your password into any machine anywhere, but have to somehow carry your private key around with you) and on and on. Public key is also the "wave of the future." When "the future" will be remains to be seen, despite repeated assurances of RSN. It's a great technology, but mandating use of it and nothing else seems rather presumptuous and arrogant. - Marc From dpkemp@missi.ncsc.mil Thu Apr 25 17:36:18 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id RAA06483 for ; Thu, 25 Apr 1996 17:36:17 -0400 Received: from guardian.guard.ncsc.mil by www10.w3.org (5.0/NSCS-1.0S) id AA15858; Thu, 25 Apr 1996 17:36:16 +0500 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id RAA27688 for ; Thu, 25 Apr 1996 17:36:31 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma027686; Thu Apr 25 17:36:15 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 RAA04098 for ; Thu, 25 Apr 1996 17:32:27 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id RAA18663; Thu, 25 Apr 1996 17:36:08 -0400 Date: Thu, 25 Apr 1996 17:36:08 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199604252136.RAA18663@argon.ncsc.mil> To: ietf-tls@w3.org Subject: RE: Password Authentication X-Sun-Charset: US-ASCII content-length: 1236 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls > From: Dan Simon > Date: Thu, 25 Apr 1996 13:42:41 -0700 > > On the other hand, if we incorporate password authentication into the > protocol, then we can protect those passwords by basing the > challenge-response protocol on both the password and the > automatically-strong MAC key exchanged during the handshake. This will > protect the password from offline attacks, making even a poorly chosen > password a useful security tool (assuming that it's kept secret, and > that the server doesn't permit unlimited online trial-and-error > attacks). OK, the following is just a request for information; a reality check for myself to see if I'm missing something fundamental here. I have the uncomfortable feeling that we are talking past one another rather than communicating. Consider the following thought experiment: * PCT 2.0 protocol, using password authentication, where the password can be only a 4 digit number (10,000 possibilities), and no public/private key pairs at the two endpoints * 2 Princeton students with a copy of a PCT session sniffed off the wire (no active attacks allowed) Can they, or can they not break the session in a minute or so by exhausting over the password space? From bsy@work.ucsd.edu Thu Apr 25 17:49:22 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id RAA07770 for ; Thu, 25 Apr 1996 17:49:17 -0400 Received: from odin.ucsd.edu by www10.w3.org (5.0/NSCS-1.0S) id AA16024; Thu, 25 Apr 1996 17:49:15 +0500 Received: from work.ucsd.edu by odin.ucsd.edu; id AA09535 sendmail 8.73/UCSDPSEUDO.4-CS via SMTP Thu, 25 Apr 96 14:49:08 -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 OAA17287; Thu, 25 Apr 1996 14:49:06 -0700 (PDT) Message-Id: <199604252149.OAA17287@work.ucsd.edu> To: dpkemp@missi.ncsc.mil (David P. Kemp) Cc: ietf-tls@w3.org Reply-To: Bennet Yee Subject: Re: Password Authentication In-Reply-To: Your message of "Thu, 25 Apr 1996 17:36:08 -0400." <199604252136.RAA18663@argon.ncsc.mil> Date: Thu, 25 Apr 1996 14:49:04 -0700 From: Bennet Yee content-length: 884 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls I haven't looked at PCTv2 recently, so a caveat. However, if you just think about how SSL and PCT work wrt exchanging a master key and hashing down to read/write keys that are 40-bits, one could imagine the passwords be protected by a >>40-bit key (probably not the master key directly, but perhaps something else derived from it). Network eavesdroppers that wish to perform an exhaustive search of the space of passwords must also determine this other key, which is difficult. This may not be a kosher way to do things wrt export, however, since one could imagine that secret messages are transmitted in this way (the password is the message) which are protected by >40-bit crypto. -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 daw@cs.berkeley.edu Thu Apr 25 18:39:25 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id SAA08605 for ; Thu, 25 Apr 1996 18:39:25 -0400 Received: from joseph.cs.berkeley.edu by www10.w3.org (5.0/NSCS-1.0S) id AA16299; Thu, 25 Apr 1996 18:39:23 +0500 Received: (from daw@localhost) by joseph.cs.berkeley.edu (8.6.12/8.6.9) id PAA00611; Thu, 25 Apr 1996 15:39:21 -0700 To: ietf-tls@w3.org Path: not-for-mail From: daw@cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-tls Subject: Re: Merged Transport Layer Protocol Development Date: 25 Apr 1996 15:39:09 -0700 Organization: ISAAC Group, UC Berkeley Lines: 12 Message-Id: <4louud$j1@joseph.cs.berkeley.edu> References: <4lmmeq$fq@joseph.cs.berkeley.edu> <199604250249.TAA30785@slack.lne.com> content-length: 406 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls In article <199604250249.TAA30785@slack.lne.com>, Eric Murray wrote: > On the other hand, it doesn't hurt to use it, if you already > have enough unguessable truly random bits. Fair enough. I was just trying to address the (implicit) claim that Unix time is secret, and that there is some value in making sure that SSL/PCT/... don't reveal it. It was just a nitpick. I'll shut up now. From dansimon@microsoft.com Thu Apr 25 19:19:10 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id TAA10224 for ; Thu, 25 Apr 1996 19:19:10 -0400 Received: from abash1.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA16558; Thu, 25 Apr 1996 19:19:08 +0500 Received: by abash1.microsoft.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB32C2.F7C026B0@abash1.microsoft.com>; Thu, 25 Apr 1996 16:19:24 -0700 Message-Id: From: Dan Simon To: "'ietf-tls@w3.org'" , "'dpkemp@missi.ncsc.mil'" Subject: RE: Password Authentication Date: Thu, 25 Apr 1996 16:19:06 -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: 2687 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls >From: dpkemp@missi.ncsc.mil[SMTP:dpkemp@missi.ncsc.mil] > >Consider the following thought experiment: > >* PCT 2.0 protocol, using password authentication, where the password > can be only a 4 digit number (10,000 possibilities), and no > public/private key pairs at the two endpoints > >* 2 Princeton students with a copy of a PCT session sniffed off > the wire (no active attacks allowed) > >Can they, or can they not break the session in a minute or so by >exhausting over the password space? > PCT 2.0 does not permit this kind of authentication. Password-based authentication is only permitted for either the client or the server (*not* both), in conjunction with a public-key-based key exchange. Moreover, a password-based authentication response may not be sent unless the accompanying key exchange either uses the other party's certified public key or has already been incorporated into the other party's (certified) digital signature-based authentication response. (These conditions ensure that only the correct "other party" knows the master key used in the password-based authentication response.) The response is essentially a cryptographic hash of the responder's identity and password, the challenger's (and responder's) challenge, and a (long) shared MAC key derived from the exchanged master key in the normal way. A typical application would be improving the security of the type of password-based client authentication scheme in wide use today: a server with, say, a certified RSA public key accepting secure server-authenticated connections from clients, then requesting a password (or password-based challenge response) over the connection to authenticate the client. If instead the client authenticated based on a shared password and the MAC key as described above, even 4-digit passwords would be secure against offline attacks, and even in connections using only 40-bit encryption keys (assuming that MAC keys can be longer). And to the best of my knowledge, there are no export problems with such a scheme, since the keyed hash does not allow (as far as I can tell) recovery of the input secret (password), only verification of its correctness. However, since this method involves the MAC key, which should not be available to the application (especially if the protocol implementation is supposed to be exportable), this type of authentication must be defined at the protocol level. The STLP document proposes a very similar password-based authentication option. I believe it would be a useful feature to have in any protocol that emanates from this working group. Daniel Simon Cryptographer, Microsoft Corp. dansimon@microsoft.com From timd@consensus.com Thu Apr 25 22:50:10 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id WAA12242 for ; Thu, 25 Apr 1996 22:50:10 -0400 Received: from dns2.noc.best.net by www10.w3.org (5.0/NSCS-1.0S) id AA17156; Thu, 25 Apr 1996 22:50:04 +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 TAA16100; Thu, 25 Apr 1996 19:49:59 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Apr 1996 19:51:44 -0700 To: ietf-tls (Transport Layer Security WG) From: timd@consensus.com (Tim Dierks) Subject: Pre-encrypted data content-length: 1592 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls In the recent discussion of the STLP "strawman", several issues have come up; here are my thoughts on a few. For what it's worth, I'm in the middle of implementing SSL 3.0 right now. - Pre-encrypted data: I don't think pre-encrypted data is a good idea for the following reasons: 1) It violates the layer abstraction of the protocol as a transport; you've got a server feeding pre-encrypted data into the layer, and the client pulling decrypted data out of it. This seems like a fundamental complication of the model, and just feels wrong. 2) It's vulnerable to traffic analysis. Since any particular piece of pre-encrypted data, when transmitted, will have the same representation on the wire, I can determine what data people are accessing by watching their transactions and correlating the results. 3) It offers minimal benefit. I don't see how it can offer any security benefit, since the information on how to decrypt the data has to be available to the client anyway. I think the performance benefits are minimal; some stream ciphers (such as RC4) are very fast, and if that's too much to pay, or if the MACing is too expensive, I think the right thing to do is to allow that to be driven by better implementations or improved algorithms. For the hypothetical servers which are supplying a large quantity of secure data, it doesn't seem inappropriate to require them to make an investment in hardware encryption support to deliver high performance. - Tim Dierks Tim Dierks -- timd@consensus.com -- www.consensus.com Head of Thing-u-ma-jig Engineering, Consensus Development From timd@consensus.com Thu Apr 25 22:50:12 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id WAA12248 for ; Thu, 25 Apr 1996 22:50:11 -0400 Received: from dns2.noc.best.net by www10.w3.org (5.0/NSCS-1.0S) id AA17157; Thu, 25 Apr 1996 22:50: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 TAA16109; Thu, 25 Apr 1996 19:50:02 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Apr 1996 19:51:47 -0700 To: ietf-tls (Transport Layer Security WG) From: timd@consensus.com (Tim Dierks) Subject: Unreliable transport content-length: 1138 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls In the recent discussion of the STLP "strawman", several issues have come up; here are my thoughts on a few. For what it's worth, I'm in the middle of implementing SSL 3.0 right now. - UDP and other unreliable transports: I don't think support for an unreliable protocol is appropriate for this effort. The current protocols (SSL & PCT) both provide protection against an opponent blocking traffic; this can be detected. In SSL 3.0, truncation attacks can be detected. Using an unreliable underlying transport makes it impossible to provide protection against this without essentially creating a stream transport on top of it. I think the standard we create should provide a certain set of security features which are provided by all implementations of the standard, and that protection against these "interruption" attacks should be a part of it. However, we should think about an unreliable transport standard which would leverage its cipher negotiation and authentication off of the stream protocol. - Tim Dierks Tim Dierks -- timd@consensus.com -- www.consensus.com Head of Thing-u-ma-jig Engineering, Consensus Development From timd@consensus.com Thu Apr 25 22:50:21 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id WAA12266 for ; Thu, 25 Apr 1996 22:50:21 -0400 Received: from dns2.noc.best.net by www10.w3.org (5.0/NSCS-1.0S) id AA17158; Thu, 25 Apr 1996 22:50:10 +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 TAA16132; Thu, 25 Apr 1996 19:50:06 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Apr 1996 19:51:51 -0700 To: ietf-tls (Transport Layer Security WG) From: timd@consensus.com (Tim Dierks) Subject: Password authentication content-length: 2988 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls In the recent discussion of the STLP "strawman", several issues have come up; here are my thoughts on a few. For what it's worth, I'm in the middle of implementing SSL 3.0 right now. - Password authentication: I think password authentication of clients may be an acceptable part of the standard. If the market wants to use passwords instead of certificates, they're going to do so. The alternatives appear to be either negotiating an unauthenticated session and having the application layer do the password authentication or allowing the transport layer to deliver the password as a part of the negotiation. I think that allowing the latter is acceptable for the following reasons: 1) It allows a standardized method of communicating passwords; this moves widely divergant code out of a variety of dependant protocols and centralizes it. 2) It allows applications which use the secure transport layer to generalize their authentication; they don't need to special case password authorization on top of an unauthenticated session. 3) It allows us to standardize a more secure method of password communication; this will avoid applications creating methods which require the password to be sent over the wire and stored in RAM (even if it is sent over a secure link, it will be delivered into the application layer in plaintext). 4) It need not impact security. A password-authenticated session can still be completely private (a network snooper or a man in the middle should have no more, and possibly less, chance of access to the contents of a password-authenticated session when compared to an unauthenticated session). However, I think password authentication should be an option only available to the client side of the session. (If the end result protocol is as asymmetric as current ones are.) Just to be clear, I'm discussing password authentication; I do not recommend using the password as a part of the negotiation of the encryption keys or IVs. Furthermore, the password should be protected by a salt and transmitted after the transport security has become active (after a change_cipher_spec message in SSL.) One possible solution would be to append two fields to SSL's finished message when sent from a client to a server: the user name and a password field, where the password field is a MAC of the actual password: hash(MAC_write_secret + pad_2 + hash(MAC_write_secret + pad_1 + hash(user name + password))) The server would store pairs; this provides for a salt against the password storage on the server. The server can calculate the same MAC on its side and compare them. This would - Provide a password in a standard fashion - Protect the password with a secure transport - Protect the password by only supplying a MAC of the attempted password - Not add another round-trip to the negotiation - Tim Dierks Tim Dierks - Software Haruspex - tim@dierks.org Hastening the heat-death of the universe since 1968. From rspoore@ralph-s-poore.com Fri Apr 26 01:39:29 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id BAA16422 for ; Fri, 26 Apr 1996 01:39:29 -0400 Received: from defiant.flash.net by www10.w3.org (5.0/NSCS-1.0S) id AA17735; Fri, 26 Apr 1996 01:39:26 +0500 Received: from p3-16.flash.net (p3-16.flash.net [206.190.63.16]) by defiant.flash.net (8.6.12/8.6.9) with SMTP id AAA18848; Fri, 26 Apr 1996 00:38:57 -0500 Date: Fri, 26 Apr 1996 00:38:57 -0500 Message-Id: <199604260538.AAA18848@defiant.flash.net> X-Sender: rspoore@ralph-s-poore.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Tatu Ylonen From: Ralph Spencer Poore Subject: Re: Merged Transport Layer Protocol Development Cc: ietf-tls@w3.org content-length: 1151 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls At 01:06 AM 4/25/96 +0300, you wrote: >I just wish to say that I also agree that special processing for >pre-encrypted data is a Bad Idea. A 90-MHz Pentium can encrypt fast >enought to completely fill an ethernet (the ethernet becomes the >limiting factor), and the processing speed is doubling every year. > >The overhead from encryption is negligible all but the most >high-volume servers connected to the Internet by something faster than >10Mbits/sec. (Unless you also do a lot of CPU-intensive processing >that competes for CPU.) > >I don't think the complications from special handling are justified. > >As for pre-encryption with strong hardware algorithms, it does no harm >to double-encrypt. > > Tatu > I agree it does no harm to double-encrypt (presuming the result isn't an import/export issue) and wasn't intentionally suggesting support for special handling of pre-encrypted data. The ability to use renegotiation with NULL-WITH-NULL CipherSpec before sending the file and resuming with the previous CipherSpec when it's done seems a small price if double-encryption were undesired. Ralph Spencer Poore rspoore@ralph-s-poore.com From dpkemp@missi.ncsc.mil Fri Apr 26 08:49:51 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id IAA21461 for ; Fri, 26 Apr 1996 08:49:51 -0400 Received: from guardian.guard.ncsc.mil by www10.w3.org (5.0/NSCS-1.0S) id AA18682; Fri, 26 Apr 1996 08:49:50 +0500 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id IAA29027 for ; Fri, 26 Apr 1996 08:50:06 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma029022; Fri Apr 26 08:49:48 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 IAA05088 for ; Fri, 26 Apr 1996 08:46:01 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id IAA19044; Fri, 26 Apr 1996 08:49:42 -0400 Date: Fri, 26 Apr 1996 08:49:42 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199604261249.IAA19044@argon.ncsc.mil> To: ietf-tls@w3.org Subject: RE: Password Authentication X-Sun-Charset: US-ASCII content-length: 931 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls From: Dan Simon Date: Thu, 25 Apr 1996 16:19:06 -0700 > PCT 2.0 does not permit this kind of authentication. Password-based > authentication is only permitted for either the client or the server > (*not* both), in conjunction with a public-key-based key exchange. Thank you for explaining this. Next time I will read the spec more thoroughly before commenting. Using passwords in this manner sounds like a useful capability for the TLS protocol to support. From: Bennet Yee Date: Wed, 24 Apr 1996 16:03:09 -0700 > The idea of providing > the pre-encryption mechanism (also applies to the on-the-fly > compression found in SSLv3) is to hide the complexity from the > client. Yes, client non-transparency is a big disadvantage of negotiating NULL protection for pre-encrypted data. That is justification enough for giving the PCT pre-encryption proposal some serious scrutiny. From rodney@sabletech.com Fri Apr 26 09:50:37 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id JAA21696 for ; Fri, 26 Apr 1996 09:50:37 -0400 Received: from wizard.pn.com by www10.w3.org (5.0/NSCS-1.0S) id AA18855; Fri, 26 Apr 1996 09:50:36 +0500 Received: from ferguson ([199.249.254.9]) by wizard.pn.com (8.6.12) with SMTP id JAA22292 for ; Fri, 26 Apr 1996 09:50:28 -0400 Message-Id: <199604261350.JAA22292@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: Fri, 26 Apr 1996 09:50:06 -0400 To: ietf-tls@w3.org From: Rodney Thayer Subject: what is current practice? (ssl2/etc.) content-length: 1403 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls since when is ssl3 "current standard practice"? last I checked SSL2 was current practice. I do not think it is at all reasonable to use either PCT or SSL3 as some sort of "current standard practice". I *wholly* agree that PCT and SSL3 and in fact other mutatations of one or the other or both or something completely different are *completely* valid proposals. >Resent-Date: Tue, 23 Apr 1996 11:01:38 -0400 >Resent-Message-Id: <199604231501.LAA09125@www19.w3.org> >X-Sender: treese@OpenMarket.com >Date: Tue, 23 Apr 1996 10:53:00 -0400 >To: ietf-tls@w3.org >From: Win Treese >Subject: what's going on >X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls >Resent-From: ietf-tls@w3.org >X-Mailing-List: archive/latest/44 >X-Loop: ietf-tls@w3.org >Sender: ietf-tls-request@w3.org >Resent-Sender: ietf-tls-request@w3.org > > ... parts of message deleted for brevity... > there is great value in standardizing existing practice rather >than trying to invent something from whole cloth. 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 tomw@netscape.com Fri Apr 26 14:25:24 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id OAA28217 for ; Fri, 26 Apr 1996 14:25:23 -0400 Received: from urchin.netscape.com (h-198-95-250-59.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA20305; Fri, 26 Apr 1996 14:25:22 +0500 Received: from ammodump (ammodump.mcom.com [205.217.232.97]) by urchin.netscape.com (8.6.12/8.6.9) with SMTP id LAA07890; Fri, 26 Apr 1996 11:25:58 -0700 Sender: tomw@netscape.com Message-Id: <318114FC.167E@netscape.com> Date: Fri, 26 Apr 1996 11:25:00 -0700 From: Tom Weinstein Organization: Netscape Communications, Inc. X-Mailer: Mozilla 3.0b4 (X11; U; IRIX 5.3 IP22) Mime-Version: 1.0 To: Rodney Thayer Cc: ietf-tls@w3.org Subject: Re: what is current practice? (ssl2/etc.) References: <199604261350.JAA22292@wizard.pn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 869 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Rodney Thayer wrote: > > since when is ssl3 "current standard practice"? last I checked SSL2 > was current practice. I do not think it is at all reasonable to use > either PCT or SSL3 as some sort of "current standard practice". > > I *wholly* agree that PCT and SSL3 and in fact other mutatations of > one or the other or both or something completely different are > *completely* valid proposals. You're right that ssl2 is more of a "current standard practice". However, ssl3 is already shipping in the latest Netscape client and server betas. There are 5 implementations that have been shown to interoperate (although they're all still being debugged). And there's a sample impelementation that's being worked on. -- Sure we spend a lot of money, but that doesn't mean | Tom Weinstein we *do* anything. -- Washington DC motto | tomw@netscape.com From dansimon@microsoft.com Fri Apr 26 14:38:05 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id OAA29072 for ; Fri, 26 Apr 1996 14:38:04 -0400 Received: from abash1.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA20410; Fri, 26 Apr 1996 14:37:58 +0500 Received: by abash1.microsoft.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB3364.DA41C470@abash1.microsoft.com>; Fri, 26 Apr 1996 11:38:13 -0700 Message-Id: From: Dan Simon To: "'ietf-tls (Transport Layer Security WG)'" , "'timd@consensus.com'" Subject: RE: Unreliable transport Date: Fri, 26 Apr 1996 11:37:45 -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: 1295 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls > >From: timd@consensus.com[SMTP:timd@consensus.com] > >- UDP and other unreliable transports: I don't think support for an >unreliable protocol is appropriate for this effort. The current >protocols >(SSL & PCT) both provide protection against an opponent blocking >traffic; >this can be detected. In SSL 3.0, truncation attacks can be detected. >Using >an unreliable underlying transport makes it impossible to provide >protection against this without essentially creating a stream transport >on >top of it. I think the standard we create should provide a certain set >of >security features which are provided by all implementations of the >standard, and that protection against these "interruption" attacks >should >be a part of it. > >However, we should think about an unreliable transport standard which >would >leverage its cipher negotiation and authentication off of the stream >protocol. This is exactly what I have in mind when I talk about "datagram support"--not a substitute for IPSEC, but merely a defined format for independently decryptable datagrams, so that key management can be unified in situations where both a reliable transport and an unreliable one are being used in parallel. Daniel Simon Cryptographer, Microsoft Corp. dansimon@microsoft.com > > > > From dansimon@microsoft.com Fri Apr 26 15:11:37 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id PAA29985 for ; Fri, 26 Apr 1996 15:11:36 -0400 Received: from tide21.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA20652; Fri, 26 Apr 1996 15:11:35 +0500 Received: by tide21.microsoft.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB3369.7CD07700@tide21.microsoft.com>; Fri, 26 Apr 1996 12:11:24 -0700 Message-Id: From: Dan Simon To: "'ietf-tls (Transport Layer Security WG)'" , "'timd@consensus.com'" Subject: RE: Pre-encrypted data Date: Fri, 26 Apr 1996 12:11:10 -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: 2637 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls >From: timd@consensus.com[SMTP:timd@consensus.com] > >- Pre-encrypted data: I don't think pre-encrypted data is a good idea >for >the following reasons: > 1) It violates the layer abstraction of the protocol as a transport; >you've got a server feeding pre-encrypted data into the layer, and the >client pulling decrypted data out of it. This seems like a fundamental >complication of the model, and just feels wrong. > 2) It's vulnerable to traffic analysis. Since any particular piece of >pre-encrypted data, when transmitted, will have the same representation >on >the wire, I can determine what data people are accessing by watching >their >transactions and correlating the results. There is no question that pre-encryption of data is ugly, both aesthetically and cryptographically speaking. It does indeed tend to violate layering boundaries, and the mere act of handing out the same key to many recipients smacks of bad cryptographic hygiene. (On the other hand, handing out the same data, pre-encrypted or not, to many recipients is unlikely to do wonders for its confidentiality in any event.) The question is whether some people would be willing to accept these penalties in order to reduce server CPU loads. My understanding is that the number one complaint of secure server operators is the enormous CPU drain (and consequently huge throughput reduction) caused by the public-key operations associated with transport-layer protocols. There is little that can be done about this problem, but for servers that send out large data streams, pre-encryption would at least avoid exacerbating it. Consider, for instance, a server with a mixed clientele requesting both large data streams and small ones. Using the figures that Tatu Yllonen and I were batting around, a megabyte of data requires about a second of CPU time on a Pentium to process--about the same as ten RSA decryptions. Hence every megabyte of (non-pre-encrypted) data sent reduces by about ten the number of "low-volume" clients who may connect to the server during that transmission. This seems to me like a performance problem that many servers would be willing to pay a substantial price to alleviate. It would be nice if we could simply delay this decision until after the working group has produced an initial protocol; unfortunately, if pre-encrypted data is *ever* to be supported, then a MAC method must be chosen *now* which makes the later specification of a pre-encryption feature possible. I strongly recommend that this, at the very least, be done. Daniel Simon Cryptographer, Microsoft Corp. dansimon@microsoft.com > > > > From tomw@netscape.com Fri Apr 26 19:03:38 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id TAA07209 for ; Fri, 26 Apr 1996 19:03:33 -0400 Received: from urchin.netscape.com (h-198-95-250-59.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA21812; Fri, 26 Apr 1996 19:03:32 +0500 Received: from ammodump (ammodump.mcom.com [205.217.232.97]) by urchin.netscape.com (8.6.12/8.6.9) with SMTP id QAA18217; Fri, 26 Apr 1996 16:03:55 -0700 Sender: tomw@netscape.com Message-Id: <31815622.2781@netscape.com> Date: Fri, 26 Apr 1996 16:02:58 -0700 From: Tom Weinstein Organization: Netscape Communications, Inc. X-Mailer: Mozilla 3.0b4 (X11; U; IRIX 5.3 IP22) Mime-Version: 1.0 To: Dan Simon Cc: "'Eric Murray'" , "'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: 1899 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Dan Simon wrote: > >> From: Eric Murray[SMTP:ericm@lne.com] >> >> Yes, if the preencrypted data has been encrypted by something >> stronger than TLS offers, and the key is sent via a TLS session, >> then the TLS session becomes the weakest part of the link. I'm >> not sure that's really a big problem. First off, more than one >> proposal for TLS-type protocols have included triple-DES >> as a symmetric cipher choice. If I'm not mistaken, triple-DES >> is the strongest commonly-available symmetric cipher. So the >> preencrypted data key would, if one used the best possible TLS >> ciphertypes, be as secure as the preencrypted data itself. >> Secondly, the suggested MAC method to allow some pre-calculation >> of the MAC is not as secure as the Krawczyk method used in SSL3 >> (and I would presume STLP). > > Interestingly enough, the authors of SSL seem to disagree; the most > sensitive MAC in their entire protocol (the "handshake hash") is > computed with the MAC key appended to the *end* of the authenticated > data in the interior hash invocation, rather than prepended at the > beginning, as in HMAC. This alteration renders the MAC method > virtually indistinguishable, cryptographically speaking, from the > one I proposed; in particular, if the underlying hash function is > not collision-intractable, then this handshake hash, as well, will > be vulnerable to collision attacks. The key difference between the SSL3 handshake hashes and your proposed MAC is that the SSL3 handshake hashes use two redundant MACs alternating MD5 and SHA. In order to construct a hash collision you must have two messages that collide in both MD5 and SHA simultaneously. I contend that this makes the SSL3 handshake hashes collision-intractable. -- Sure we spend a lot of money, but that doesn't mean | Tom Weinstein we *do* anything. -- Washington DC motto | tomw@netscape.com From tomste@microsoft.com Fri Apr 26 22:13:19 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id WAA09206 for ; Fri, 26 Apr 1996 22:13:18 -0400 Received: from tide21.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA22545; Fri, 26 Apr 1996 22:13:16 +0500 Received: by tide21.microsoft.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB33A4.751BCD30@tide21.microsoft.com>; Fri, 26 Apr 1996 19:13:31 -0700 Message-Id: From: Tom Stephens To: "'Rodney Thayer'" Cc: "'pcttalk@ftp.com'" , "'ietf-tls@w3.org'" Subject: RE: which to implement? Date: Fri, 26 Apr 1996 19:13:15 -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: 2917 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls >SSLv3 and PCTv2 are both PAPER protocols. We're living with SSLv2 and >PCTv1 in real code, and we all agree that's not good enough. The >purpose of this TLS working group is to come up with something more >secure and more open, but I agree with Win and Taher that we need to be >in Final Draft form by July to have an IETF standard in 1996. This is >critical to all of us so that we don't have to even think about what we >implement. "STLP" should be the Internet standard - so let's get serious about what's in it, so we can all get on with the code. >Do any of you want to sit down together for a day and work up an STLP >draft to present to the whole working group before the IETF meeting in >June? There's some great discussion going on the list, but maybe a >face-to-face meeting with anyone who is really interested could >accelerate the process. Any takers? I would be happy to schedule and arrange for such a meeting if people are amenable. Tom Stephens Program Manager Microsoft Corporation >---------- >From: Rodney Thayer[SMTP:rodney@sabletech.com] >Sent: Wednesday, April 24, 1996 3:12 AM >To: Sean Dalby >Cc: pcttalk@ftp.com; rodney@sabletech.com >Subject: which to implement? > >netscape in the ssl3 spec claims it is going to deprecate ssl2 > >yet ssl2 has a significant installed base and I'm not convinced it will >go >away the moment shows up, regardless of what the >something >else is. > >now there's the IETF activity too. > >and there's an other Microsoft protocol (can't remember it's name at >the moment) > >and there's SHTTP which apparently has not yet disappeared -- although >since >you can't buy any browsers that support it maybe it's not really here >yet. > >of course all this could become instantly irrelevant if for example >Master >Card started giving away free netscape plug-in's with their own >encryption >scheme. > >this all makes for a tough call on what to implement. my personal >conclusion, >today, is: > > 1. reconsider decision continuously > 2. do not implement ssl2 as netscape is going to desupport it soon > 3. do not implement non-existant protocols (meaning SSL3, today.) > 4. use a protocol known to be implement by others > >so today's answer ends up being PCT. I really would rather do >something >with a genuine IETF process behind it but there is no such protocol >today. >Yes yes there is now an active process, and that's *GOOD*, but there >ain't >no code today. > >just my opinion... > >At 03:04 PM 4/16/96 -0600, you wrote: > ... > > 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 Sat Apr 27 09:22:18 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id JAA13113 for ; Sat, 27 Apr 1996 09:22:17 -0400 Received: from wizard.pn.com by www10.w3.org (5.0/NSCS-1.0S) id AA23641; Sat, 27 Apr 1996 09:22:15 +0500 Received: from ferguson ([199.249.254.9]) by wizard.pn.com (8.6.12) with SMTP id JAA13949 for ; Sat, 27 Apr 1996 09:22:12 -0400 Message-Id: <199604271322.JAA13949@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: Sat, 27 Apr 1996 09:21:51 -0400 To: ietf-tls@w3.org From: Rodney Thayer Subject: Schedule at June IETF Montreal content-length: 444 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls has it been decided/debated/considered when this wg will meet in Montreal? 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 dansimon@microsoft.com Mon Apr 29 14:35:58 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id OAA28224 for ; Mon, 29 Apr 1996 14:35:57 -0400 Received: from tide19.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA00133; Mon, 29 Apr 1996 14:35:57 +0500 Received: by tide19.microsoft.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB35B8.D7D73340@tide19.microsoft.com>; Mon, 29 Apr 1996 10:44:29 -0700 Message-Id: From: Dan Simon To: "'Tom Weinstein'" Cc: "'ietf-tls@w3.org'" Subject: RE: Merged Transport Layer Protocol Development Date: Mon, 29 Apr 1996 10:42:43 -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: 2923 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls >From: Tom Weinstein[SMTP:tomw@netscape.com] > >Dan Simon wrote: >> >> Interestingly enough, the authors of SSL seem to disagree; the most >> sensitive MAC in their entire protocol (the "handshake hash") is >> computed with the MAC key appended to the *end* of the authenticated >> data in the interior hash invocation, rather than prepended at the >> beginning, as in HMAC. This alteration renders the MAC method >> virtually indistinguishable, cryptographically speaking, from the >> one I proposed; in particular, if the underlying hash function is >> not collision-intractable, then this handshake hash, as well, will >> be vulnerable to collision attacks. > >The key difference between the SSL3 handshake hashes and your proposed >MAC is that the SSL3 handshake hashes use two redundant MACs >alternating MD5 and SHA. In order to construct a hash collision you >must have two messages that collide in both MD5 and SHA simultaneously. >I contend that this makes the SSL3 handshake hashes >collision-intractable. Well, I expect that the combination of MD5 and SHA is in some sense *more* collision-intractable than either one used separately, but that is simply an argument for using both in general message authentication, not an argument for "weakening" the MAC method used in the handshake hash. The point is that the collision-intractability of the underlying hash function is, in practice, a necessary condition for the security of *any* of the proposed MAC methods, including HMAC. If you don't believe that, say, SHA is collision-intractable, then you shouldn't use it as the (sole) basis for any of the known hash-based MAC methods. (That is why I brought up the question earlier of whether MD5 should be listed as a hash function choice at all, given recent questions that have arisen about its collision-intractability.) On the other hand, if you *do* believe that SHA is collision-intractable, then the MAC method used in PCT, or for the SSL v3.0 handshake hash, is quite sufficient. (One could, it is true, consider a more subtle definition of collision-intractability which, if met, would make a hash function acceptable for HMAC but not for the MAC method used in PCT; however, most of us would probably agree that discovery of an efficient collision-finding algorithm for a cryptographic hash function would be sufficient reason to reject it for use in either MAC method.) In short, I see absolutely no reason for treating the "handshake hash" any differently from other MACs; both must be secure under the normal definition of a MAC. And the MAC method used in the SSL v3.0 "handshake hash" has that property, as long as the underlying hash function (whether MD5, SHA or a combination thereof) is collision-intractable. The same can be said of the method used for general message authentication in PCT. Daniel Simon Cryptographer, Microsoft Corp. dansimon@microsoft.com > > > From ericm@lne.com Mon Apr 29 23:46:48 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id XAA00827 for ; Mon, 29 Apr 1996 23:46:47 -0400 Received: from slack.lne.com by www10.w3.org (5.0/NSCS-1.0S) id AA01971; Mon, 29 Apr 1996 23:46:45 +0500 Received: (from ericm@localhost) by slack.lne.com (8.7.1/1.0) id UAA04015; Mon, 29 Apr 1996 20:45:31 -0700 From: Eric Murray Message-Id: <199604300345.UAA04015@slack.lne.com> Subject: Re: Password Authentication To: bsy@cs.ucsd.edu Date: Mon, 29 Apr 1996 20:45:29 -0700 (PDT) Cc: dpkemp@missi.ncsc.mil, ietf-tls@w3.org In-Reply-To: <199604251747.KAA10949@work.ucsd.edu> from "Bennet Yee" at Apr 25, 96 10:47:34 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit content-length: 1620 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Bennet Yee writes: > > I agree with most of your points about passwords. However, the scenario > that you draw about extensions would imply that we should think about > mechanisms by which extensions to TLS may be made cleanly -- reserve some > record type numbers that are vendor-specific, and mandate that the rest > be not used except as officially sanctioned blah blah blah when/if TLS > gets revised. If we don't do this, then we risk creating compatibility > problems in the future. While I agree that an extension mechanisim might be useful, I think there's more utility in keeping the standard simple to understand and implement. An extension mechanisim that allowed vendor-specific extensions would probably require yet another negotiation, if you don't want to repeat the HTML problem of conflicting vendor-added features- i.e. "do I write my TLS to talk to Microscape's TLS extentions, or Netsoft's?"). Adding another negotiation would increase the complexity of the TLS standard. Look at the RFCs, it's the simple standards that have been successful and widely deployed, while there are many super-flexible but complicated standards that have few implementations. I think it would be better to create one simple TLS standard, then add on additional standards or IANA registration schemes for things like password-exchamge protocols, additional CipherSuites, support for pre-encrypted data, etc. rather than trying to do everything now. -- 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 jsw@netscape.com Tue Apr 30 02:22:00 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id CAA01174 for ; Tue, 30 Apr 1996 02:22:00 -0400 Received: from urchin.netscape.com (h-198-95-250-59.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA02282; Tue, 30 Apr 1996 02:22:00 +0500 Received: from tofuhut.mcom.com (tofuhut.mcom.com [205.217.232.95]) by urchin.netscape.com (8.6.12/8.6.9) with SMTP id XAA24310; Mon, 29 Apr 1996 23:22:36 -0700 Message-Id: <3185B0BD.1018@netscape.com> Date: Mon, 29 Apr 1996 23:18:37 -0700 From: Jeff Weinstein Reply-To: jsw@netscape.com Organization: Netscape Communications Corp. X-Mailer: Mozilla 3.0b3Gold (Win95; I) Mime-Version: 1.0 To: Dan Simon Cc: ietf-tls Subject: Re: Merged Transport Layer Protocol Development References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 1027 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Dan Simon wrote: > In short, I see absolutely no reason for treating the "handshake hash" > any differently from other MACs; both must be secure under the normal > definition of a MAC. And the MAC method used in the SSL v3.0 "handshake > hash" has that property, as long as the underlying hash function > (whether MD5, SHA or a combination thereof) is collision-intractable. > The same can be said of the method used for general message > authentication in PCT. I think you misunderstand the purpose of using both MD5 and SHA for the handshake hash. If SHA were compromised we could just deprecate all cipher suites that included SHA, without having to immediately change the base protocol, since the handshake hash includes MD5 as well. If the handshake hash were just SHA, then we would have to change the protocol if it fell. --Jeff -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw@netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine. From dansimon@microsoft.com Tue Apr 30 14:28:28 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id OAA06699 for ; Tue, 30 Apr 1996 14:28:27 -0400 Received: from tide21.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA04457; Tue, 30 Apr 1996 14:28:24 +0500 Received: by tide21.microsoft.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB3687.56CF9470@tide21.microsoft.com>; Tue, 30 Apr 1996 11:22:38 -0700 Message-Id: From: Dan Simon To: "'jsw@netscape.com'" Cc: "'ietf-tls'" Subject: RE: Merged Transport Layer Protocol Development Date: Tue, 30 Apr 1996 11:22: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: 1893 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls > >From: Jeff Weinstein[SMTP:jsw@netscape.com] >Dan Simon wrote: >> In short, I see absolutely no reason for treating the "handshake hash" >> any differently from other MACs; both must be secure under the normal >> definition of a MAC. And the MAC method used in the SSL v3.0 "handshake >> hash" has that property, as long as the underlying hash function >> (whether MD5, SHA or a combination thereof) is collision-intractable. >> The same can be said of the method used for general message >> authentication in PCT. > > I think you misunderstand the purpose of using both MD5 and SHA for >the handshake hash. If SHA were compromised we could just deprecate >all cipher suites that included SHA, without having to immediately >change the base protocol, since the handshake hash includes MD5 as >well. If the handshake hash were just SHA, then we would have to >change >the protocol if it fell. On the other hand, if *both* MD5 and SHA were to be broken, then the protocol itself *would* have to be changed (in fact, even if only one of them falls, then the protocol *should* be changed anyway, by the above logic, to maintain this "extra security" claimed for the handshake hash). But if the handshake hash were treated like any other MAC, then *all* problems caused by hash functions dying an unnatural death could be handled simply by adjusting the set of valid cipher suites (or better yet, by deleting an individual hash function code, once the "cipher suites" are divided up--as they should be--into separate codes for ciphers, hash functions, etc.). And as long as hash functions can be expunged from the protocol once they are found not to be collision-intractable, the MAC method used in PCT would be a perfectly satisfactory one for all MACs in the protocol, including the handshake hash. Daniel Simon Cryptographer, Microsoft Corp. dansimon@microsoft.com > From treese@openmarket.com Mon May 6 22:43:23 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id WAA12600 for ; Mon, 6 May 1996 22:43:23 -0400 Received: from relay.openmarket.com by www10.w3.org (5.0/NSCS-1.0S) id AA09405; Mon, 6 May 1996 22:43:21 +0500 Received: from cirocco.openmarket.com (cirocco.openmarket.com [199.170.183.9]) by relay.openmarket.com (8.6.10/8.6.6) with ESMTP id WAA10837; Mon, 6 May 1996 22:43:20 -0400 Received: from OpenMarket.com (localhost [127.0.0.1]) by cirocco.openmarket.com (8.6.9/8.6.6) with ESMTP id WAA17230; Mon, 6 May 1996 22:43:19 -0400 Message-Id: <199605070243.WAA17230@cirocco.openmarket.com> To: jis@mit.edu Cc: ietf-tls@w3.org Subject: proposed charter for TLS working group Date: Mon, 06 May 1996 22:43:18 -0400 From: Win Treese content-length: 2196 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Jeff, Here is the proposed charter for the IETF TLS working group. 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 hosts on the Internet above the transport 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 jis@mit.edu Tue May 7 14:39:05 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id OAA23073 for ; Tue, 7 May 1996 14:39:05 -0400 Received: from big-screw (BIG-SCREW.MIT.EDU) by www10.w3.org (5.0/NSCS-1.0S) id AA14055; Tue, 7 May 1996 14:39:03 +0500 Received: by big-screw id AA26330; Tue, 7 May 96 14:38:32 -0400 Sender: jis@mit.edu Message-Id: <318F9878.41C6@mit.edu> Date: Tue, 07 May 1996 14:37:44 -0400 From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology X-Mailer: Mozilla 2.01 (X11; I; IRIX 5.2 IP22) Mime-Version: 1.0 To: Win Treese Cc: ietf-tls@w3.org Subject: Re: proposed charter for TLS working group References: <199605070243.WAA17230@cirocco.openmarket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 83 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls It looks good. I'll ship it off the IESG and IAB. -Jeff From ChristopherA@consensus.com Tue May 7 15:19:13 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id PAA25172 for ; Tue, 7 May 1996 15:19:13 -0400 Received: from consensus.com (mail.consensus.com) by www10.w3.org (5.0/NSCS-1.0S) id AA14351; Tue, 7 May 1996 15:19:11 +0500 Received: from [157.22.240.12] by consensus.com with ESMTP (Apple Internet Mail Server 1.1); Tue, 7 May 1996 11:18:58 -0800 Message-Id: In-Reply-To: <199605070243.WAA17230@cirocco.openmarket.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Organization: Consensus Development Corporation Date: Tue, 7 May 1996 12:18:41 -0700 To: Win Treese , jis@mit.edu From: Christopher Allen Subject: Re: proposed charter for TLS working group Cc: ietf-tls@w3.org content-length: 1764 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls At 7:43 PM -0700 5/6/96, Win Treese wrote: >Goals and Milestones > >April 96 Agreement on charter and issues in current draft. I think this date is fine for "agreement on charter" -- but I don't like "agreement on issues in current draft". If you are speaking of the technical draft, I don't think we've agreed that any of the strawmen so far should go further. The MicroSoft strawman is full of possible holes and has some falacies in it's basic overview of intentions (at least 4 of the items claimed to be "fixed" over SSL 3.0 are false statements). At this point, only SSL 3.0 is actually well underway with a number of implementations available now and others coming in the next month or so. >July 96 Final draft for Secure Transport Layer Protocol ("STLP") I think this is far too soon to expect a final draft of STLP, given a lack of agreement on the strawman, nor a commitment from MicroSoft to support a STLP derived from SSL 3.0. I think some of the issues they brought up (for instance pre-encrypted data, password authentication, etc.) could be brought into an SSL style framework (call it SSL 3.1) that would be a first step toward being officially STLP. >Nov 96 Working group "Last Call" In spite of my problem with the July date for the final draft, I do think it is possible to have the working group last call by November. >Dec 96 Offer to IESG for IETF "Last Call" ------------------------------------------------------------------------ ..Christopher Allen Consensus Development Corporation.. .. 1563 Solano Avenue #355.. .. Berkeley, CA 94707-2116.. .. o510/559-1500 f510/559-1505.. From elgamal@netscape.com Tue May 7 16:32:59 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id QAA25785 for ; Tue, 7 May 1996 16:32:58 -0400 Received: from urchin.netscape.com (h-198-95-250-59.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA14780; Tue, 7 May 1996 16:32:57 +0500 Received: from kingtut.mcom.com (h205-217-251-215.mcom.com [205.217.251.215]) by urchin.netscape.com (8.6.12/8.6.9) with SMTP id NAA19583; Tue, 7 May 1996 13:33:31 -0700 Message-Id: <318FB455.12B7@netscape.com> Date: Tue, 07 May 1996 13:36:37 -0700 From: Taher Elgamal X-Mailer: Mozilla 2.01Gold (Win95; I) Mime-Version: 1.0 To: "Jeffrey I. Schiller" Cc: Win Treese , ietf-tls@w3.org Subject: Re: proposed charter for TLS working group References: <199605070243.WAA17230@cirocco.openmarket.com> <318F9878.41C6@mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 365 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Jeffrey I. Schiller wrote: > > It looks good. I'll ship it off the IESG and IAB. > > -Jeff My only issue is that the name STLP has been assigned to an intermediate proposal -- may be we should choose another name. -- Taher Elgamal elgamal@netscape.com Chief Scientist, Netscape Communications (T) 415 937 2898, (F) 415 428 4054 From tomste@microsoft.com Tue May 7 17:30:51 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id RAA26452 for ; Tue, 7 May 1996 17:30:50 -0400 Received: from tide21.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA15122; Tue, 7 May 1996 17:30:38 +0500 Received: by tide21.microsoft.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB3C21.D1051860@tide21.microsoft.com>; Tue, 7 May 1996 14:31:02 -0700 Message-Id: From: Tom Stephens To: "'Win Treese'" , "'jis@mit.edu'" , "'Christopher Allen'" Cc: "'ietf-tls@w3.org'" Subject: RE: proposed charter for TLS working group Date: Tue, 7 May 1996 14:30:16 -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: 3087 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Christopher, Microsoft is fully committed to STLP. A primary goal for Microsoft has always been the adoption of an open, non-proprietary protocol under IETF change control. Another goal has been to ensure that this new protocol take into account the needs of not just one group, but rather the needs of the of as many ISV's and users as possible. That is why we took SSL 3.0 as the basis for the STLP strawman document and added PCT 2.0 deltas. Beyond that, we have no pre-conditions for the adoption of a protocol. Two weeks ago I posted to this alias an invitation for all interested parties to meet and develop a draft which could be presented to this working group at Montreal. I make that proposal again. Would you be willing to be in the San Francisco Bay Area during the week of 5/27 ( time and location can be announced this week) and resolve the issues you and the others on this alias have raised? This would seem to be the fastest, most efficient way of meeting the aggressive timeline that has been proposed. Tom Stephens >---------- >From: Christopher Allen[SMTP:ChristopherA@consensus.com] >Sent: Tuesday, May 07, 1996 12:18 PM >To: Win Treese; jis@mit.edu >Cc: ietf-tls@w3.org >Subject: Re: proposed charter for TLS working group > >At 7:43 PM -0700 5/6/96, Win Treese wrote: >>Goals and Milestones >> >>April 96 Agreement on charter and issues in current draft. > >I think this date is fine for "agreement on charter" -- but I don't >like >"agreement on issues in current draft". If you are speaking of the >technical draft, I don't think we've agreed that any of the strawmen so >far >should go further. The MicroSoft strawman is full of possible holes and >has >some falacies in it's basic overview of intentions (at least 4 of the >items >claimed to be "fixed" over SSL 3.0 are false statements). At this >point, >only SSL 3.0 is actually well underway with a number of implementations >available now and others coming in the next month or so. > >>July 96 Final draft for Secure Transport Layer Protocol ("STLP") > >I think this is far too soon to expect a final draft of STLP, given a >lack >of agreement on the strawman, nor a commitment from MicroSoft to >support a >STLP derived from SSL 3.0. I think some of the issues they brought up >(for >instance pre-encrypted data, password authentication, etc.) could be >brought into an SSL style framework (call it SSL 3.1) that would be a >first step toward being officially STLP. > >>Nov 96 Working group "Last Call" > >In spite of my problem with the July date for the final draft, I do >think >it is possible to have the working group last call by November. > >>Dec 96 Offer to IESG for IETF "Last Call" > > >------------------------------------------------------------------------ > >..Christopher Allen Consensus Development >Corporation.. >.. 1563 Solano Avenue >#355.. >.. Berkeley, CA >94707-2116.. >.. o510/559-1500 >f510/559-1505.. > > > From ChristopherA@consensus.com Tue May 7 17:59:12 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id RAA26958 for ; Tue, 7 May 1996 17:59:12 -0400 Received: from consensus.com (mail.consensus.com) by www10.w3.org (5.0/NSCS-1.0S) id AA15303; Tue, 7 May 1996 17:59:10 +0500 Received: from [157.22.240.12] by consensus.com with ESMTP (Apple Internet Mail Server 1.1); Tue, 7 May 1996 13:59:06 -0800 X-Sender: ChristopherA@consensus.com (Unverified) Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Organization: Consensus Development Corporation Date: Tue, 7 May 1996 14:41:19 -0700 To: Tom Stephens , "'Win Treese'" , "'jis@mit.edu'" From: Christopher Allen Subject: RE: proposed charter for TLS working group Cc: "'ietf-tls@w3.org'" content-length: 951 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls At 2:30 PM -0700 5/7/96, Tom Stephens wrote: >Would you be >willing to be in the San Francisco Bay Area during the week of 5/27 ( >time and location can be announced this week) and resolve the issues you >and the others on this alias have raised? I would be glad to meet with you sometime that week, though it will take a little coordination to take care of the "and others" part. I'll forward your request around and see if I can't get a commitment from everyone. >This would seem to be the >fastest, most efficient way of meeting the aggressive timeline that has >been proposed. ------------------------------------------------------------------------ ..Christopher Allen Consensus Development Corporation.. .. 1563 Solano Avenue #355.. .. Berkeley, CA 94707-2116.. .. o510/559-1500 f510/559-1505.. From tomste@microsoft.com Tue May 7 18:12:43 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id SAA27421 for ; Tue, 7 May 1996 18:12:42 -0400 Received: from abash1.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA15412; Tue, 7 May 1996 18:12:42 +0500 Received: by abash1.microsoft.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB3C27.94613410@abash1.microsoft.com>; Tue, 7 May 1996 15:12:17 -0700 Message-Id: From: Tom Stephens To: "'Win Treese'" , "'jis@mit.edu'" , "'Christopher Allen'" Cc: "'ietf-tls@w3.org'" Subject: RE: proposed charter for TLS working group Date: Tue, 7 May 1996 15:12:15 -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: 1369 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Great. I will attempt to find a meeting location in the South Bay we can use. I will also try to see how many people I can get to attend as well. >---------- >From: Christopher Allen[SMTP:ChristopherA@consensus.com] >Sent: Tuesday, May 07, 1996 2:41 PM >To: Tom Stephens; 'Win Treese'; 'jis@mit.edu' >Cc: 'ietf-tls@w3.org' >Subject: RE: proposed charter for TLS working group > >At 2:30 PM -0700 5/7/96, Tom Stephens wrote: >>Would you be >>willing to be in the San Francisco Bay Area during the week of 5/27 ( >>time and location can be announced this week) and resolve the issues you >>and the others on this alias have raised? > >I would be glad to meet with you sometime that week, though it will >take a >little coordination to take care of the "and others" part. I'll forward >your request around and see if I can't get a commitment from everyone. > >>This would seem to be the >>fastest, most efficient way of meeting the aggressive timeline that has >>been proposed. > >------------------------------------------------------------------------ > >..Christopher Allen Consensus Development >Corporation.. >.. 1563 Solano Avenue >#355.. >.. Berkeley, CA >94707-2116.. >.. o510/559-1500 >f510/559-1505.. > > > From ericm@lne.com Tue May 7 18:43:54 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id SAA28054 for ; Tue, 7 May 1996 18:43:54 -0400 Received: from slack.lne.com by www10.w3.org (5.0/NSCS-1.0S) id AA15588; Tue, 7 May 1996 18:43:49 +0500 Received: (from ericm@localhost) by slack.lne.com (8.7.1/1.0) id PAA17720; Tue, 7 May 1996 15:38:33 -0700 From: Eric Murray Message-Id: <199605072238.PAA17720@slack.lne.com> Subject: Re: proposed charter for TLS working group To: tomste@microsoft.com (Tom Stephens) Date: Tue, 7 May 1996 15:38:33 -0700 (PDT) Cc: ietf-tls@w3.org In-Reply-To: from "Tom Stephens" at May 7, 96 02:30:16 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit content-length: 1814 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Tom Stephens writes: > > Christopher, > > Microsoft is fully committed to STLP. By 'STLP' do you mean "Microsoft's proposal" or "the eventual standard that the TLS working group produces"? "STLP" has become overloaded- some people take it mean Microsoft's "strawman", others are using it as the name of the standard that this group is discussing. I'd like to suggest that we use a diferent name for the standard that the working group is supposed to produce. I have been calling it "TLS", I would like to propose that we call it that. Using a name that is not owned by any corporate entity should reduce the amount of political manouvering that is going on. > Two weeks ago I posted to this alias an invitation for all interested > parties to meet and develop a draft which could be presented to this > working group at Montreal. I make that proposal again. Would you be > willing to be in the San Francisco Bay Area during the week of 5/27 ( > time and location can be announced this week) and resolve the issues you > and the others on this alias have raised? This would seem to be the > fastest, most efficient way of meeting the aggressive timeline that has > been proposed. While I applaud your willingness to meet and to accomplish things, I'm not sure that calling a meeting like this doesn't voliate the spirit of the IETF. Only a few of the people who have an interest in the working-group would be able to attend. I think it would be more in keeping with the spirit of the IETF to do as much as possible via the mailing list, where all can participate. Having said that, if there's a meeting in the bay area I won't miss 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 Tue May 7 19:25:45 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id TAA28585 for ; Tue, 7 May 1996 19:25:45 -0400 Received: from abash1.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA15850; Tue, 7 May 1996 19:25:44 +0500 Received: by abash1.microsoft.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB3C31.CD2E0570@abash1.microsoft.com>; Tue, 7 May 1996 16:25:27 -0700 Message-Id: From: Tom Stephens To: "'Eric Murray'" Cc: "'ietf-tls@w3.org'" Subject: RE: proposed charter for TLS working group Date: Tue, 7 May 1996 16:24:37 -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: 2625 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls In my response I was referring to an eventual TLS working group draft standard and not the MS strawman document. As for TLS vs. STLP, I could support either or neither...whatever works best for the group. In regards to the meeting, I understand your concern. The meeting minutes and any documents coming out of the meeting should be posted to this alias for entire working group to review. As I understand procedures, nothing coming out of this meeting will have a higher or lesser status than any other proposals submitted for the consideration of the working group. >---------- >From: Eric Murray[SMTP:ericm@lne.com] >Sent: Tuesday, May 07, 1996 3:38 PM >To: Tom Stephens >Cc: ietf-tls@w3.org >Subject: Re: proposed charter for TLS working group > >Tom Stephens writes: >> >> Christopher, >> >> Microsoft is fully committed to STLP. > >By 'STLP' do you mean "Microsoft's proposal" or "the eventual >standard that the TLS working group produces"? > >"STLP" has become overloaded- some people take it mean Microsoft's >"strawman", others are using it as the name of the standard >that this group is discussing. > >I'd like to suggest that we use a different name for the standard >that the working group is supposed to produce. I have been >calling it "TLS", I would like to propose that we call it that. >Using a name that is not owned by any corporate entity should >reduce the amount of political maneuvering that is going on. > >> Two weeks ago I posted to this alias an invitation for all interested >> parties to meet and develop a draft which could be presented to this >> working group at Montreal. I make that proposal again. Would you be >> willing to be in the San Francisco Bay Area during the week of 5/27 ( >> time and location can be announced this week) and resolve the issues you >> and the others on this alias have raised? This would seem to be the >> fastest, most efficient way of meeting the aggressive timeline that has >> been proposed. > >While I applaud your willingness to meet and to accomplish >things, I'm not sure that calling a meeting like this doesn't >voliate the spirit of the IETF. Only a few of the people who >have an interest in the working-group would be able to attend. >I think it would be more in keeping with the spirit of the IETF to >do as much as possible via the mailing list, where all can participate. > > >Having said that, if there's a meeting in the bay area I won't miss 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 tomw@netscape.com Tue May 7 19:37:07 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id TAA28740 for ; Tue, 7 May 1996 19:37:06 -0400 Received: from urchin.netscape.com (h-198-95-250-59.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA15905; Tue, 7 May 1996 19:37: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 QAA28685; Tue, 7 May 1996 16:37:46 -0700 Sender: tomw@netscape.com Message-Id: <318FDE8C.794B@netscape.com> Date: Tue, 07 May 1996 16:36:44 -0700 From: Tom Weinstein Organization: Netscape Communications, Inc. X-Mailer: Mozilla 3.0b4 (X11; U; IRIX 5.3 IP22) Mime-Version: 1.0 To: Eric Murray Cc: Tom Stephens , ietf-tls@w3.org Subject: Re: proposed charter for TLS working group References: <199605072238.PAA17720@slack.lne.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 2099 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls I am in violent agreement with Eric. -- One tag to rule them all, One tag to find them; One tag | Tom Weinstein to bring them all, and in the source tree bind them. | tomw@netscape.com Eric Murray wrote: > > Tom Stephens writes: > > > > Christopher, > > > > Microsoft is fully committed to STLP. > > By 'STLP' do you mean "Microsoft's proposal" or "the eventual > standard that the TLS working group produces"? > > "STLP" has become overloaded- some people take it mean Microsoft's > "strawman", others are using it as the name of the standard > that this group is discussing. > > I'd like to suggest that we use a diferent name for the standard > that the working group is supposed to produce. I have been > calling it "TLS", I would like to propose that we call it that. > Using a name that is not owned by any corporate entity should > reduce the amount of political manouvering that is going on. > > > Two weeks ago I posted to this alias an invitation for all interested > > parties to meet and develop a draft which could be presented to this > > working group at Montreal. I make that proposal again. Would you be > > willing to be in the San Francisco Bay Area during the week of 5/27 ( > > time and location can be announced this week) and resolve the issues you > > and the others on this alias have raised? This would seem to be the > > fastest, most efficient way of meeting the aggressive timeline that has > > been proposed. > > While I applaud your willingness to meet and to accomplish > things, I'm not sure that calling a meeting like this doesn't > voliate the spirit of the IETF. Only a few of the people who > have an interest in the working-group would be able to attend. > I think it would be more in keeping with the spirit of the IETF to > do as much as possible via the mailing list, where all can participate. > > Having said that, if there's a meeting in the bay area I won't miss 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 Tue May 7 19:53:36 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id TAA28782 for ; Tue, 7 May 1996 19:53:34 -0400 Received: from tide19.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA15971; Tue, 7 May 1996 19:53:33 +0500 Received: by tide19.microsoft.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB3C35.DCA673D0@tide19.microsoft.com>; Tue, 7 May 1996 16:54:31 -0700 Message-Id: From: Tom Stephens To: "'Eric Murray'" , "'Tom Weinstein'" Cc: "'ietf-tls@w3.org'" Subject: RE: proposed charter for TLS working group Date: Tue, 7 May 1996 16:53:30 -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: 2696 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls In what areas are you in violent agreement with Eric? That TLS should be used instead of STLP in referring to the standard? That this may violate the spirit of IETF and we should do as much as possible via the mailing list, but that you will attend the meeting at the end of the month in the Bay Area if it is held? Tom Stephens >---------- >From: Tom Weinstein[SMTP:tomw@netscape.com] >Sent: Tuesday, May 07, 1996 4:36 PM >To: Eric Murray >Cc: Tom Stephens; ietf-tls@w3.org >Subject: Re: proposed charter for TLS working group > >I am in violent agreement with Eric. > >-- >One tag to rule them all, One tag to find them; One tag | Tom Weinstein >to bring them all, and in the source tree bind them. | >tomw@netscape.com > > >Eric Murray wrote: >> >> Tom Stephens writes: >> > >> > Christopher, >> > >> > Microsoft is fully committed to STLP. >> >> By 'STLP' do you mean "Microsoft's proposal" or "the eventual >> standard that the TLS working group produces"? >> >> "STLP" has become overloaded- some people take it mean Microsoft's >> "strawman", others are using it as the name of the standard >> that this group is discussing. >> >> I'd like to suggest that we use a diferent name for the standard >> that the working group is supposed to produce. I have been >> calling it "TLS", I would like to propose that we call it that. >> Using a name that is not owned by any corporate entity should >> reduce the amount of political manouvering that is going on. >> >> > Two weeks ago I posted to this alias an invitation for all interested >> > parties to meet and develop a draft which could be presented to this >> > working group at Montreal. I make that proposal again. Would you be >> > willing to be in the San Francisco Bay Area during the week of 5/27 ( >> > time and location can be announced this week) and resolve the issues you >> > and the others on this alias have raised? This would seem to be the >> > fastest, most efficient way of meeting the aggressive timeline that has >> > been proposed. >> >> While I applaud your willingness to meet and to accomplish >> things, I'm not sure that calling a meeting like this doesn't >> voliate the spirit of the IETF. Only a few of the people who >> have an interest in the working-group would be able to attend. >> I think it would be more in keeping with the spirit of the IETF to >> do as much as possible via the mailing list, where all can participate. >> >> Having said that, if there's a meeting in the bay area I won't miss 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 tomw@netscape.com Tue May 7 20:04:34 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id UAA28881 for ; Tue, 7 May 1996 20:04:34 -0400 Received: from urchin.netscape.com (h-198-95-250-59.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA16051; Tue, 7 May 1996 20:04:32 +0500 Received: from ammodump (ammodump.mcom.com [205.217.232.97]) by urchin.netscape.com (8.6.12/8.6.9) with SMTP id RAA29954; Tue, 7 May 1996 17:04:39 -0700 Sender: tomw@netscape.com Message-Id: <318FE4DA.15FB@netscape.com> Date: Tue, 07 May 1996 17:03:38 -0700 From: Tom Weinstein Organization: Netscape Communications, Inc. X-Mailer: Mozilla 3.0b4 (X11; U; IRIX 5.3 IP22) Mime-Version: 1.0 To: Tom Stephens Cc: "'Eric Murray'" , "'ietf-tls@w3.org'" Subject: Re: proposed charter for TLS working group References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 561 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Tom Stephens wrote: > > In what areas are you in violent agreement with Eric? > > That TLS should be used instead of STLP in referring to the standard? > > That this may violate the spirit of IETF and we should do as much as > possible via the mailing list, but that you will attend the meeting at > the end of the month in the Bay Area if it is held? All of the above, which is why I didn't qualify it. -- One tag to rule them all, One tag to find them; One tag | Tom Weinstein to bring them all, and in the source tree bind them. | tomw@netscape.com From tomste@microsoft.com Tue May 7 20:33:27 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id UAA29083 for ; Tue, 7 May 1996 20:33:26 -0400 Received: from tide19.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA16166; Tue, 7 May 1996 20:33:25 +0500 Received: by tide19.microsoft.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB3C3B.6BFE3720@tide19.microsoft.com>; Tue, 7 May 1996 17:34:19 -0700 Message-Id: From: Tom Stephens To: "'Tom Weinstein'" Cc: "'ietf-tls@w3.org'" Subject: RE: proposed charter for TLS working group Date: Tue, 7 May 1996 17:33:20 -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: 845 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls I'll be looking forward to meeting you in three weeks. >---------- >From: Tom Weinstein[SMTP:tomw@netscape.com] >Sent: Tuesday, May 07, 1996 5:03 PM >To: Tom Stephens >Cc: 'Eric Murray'; 'ietf-tls@w3.org' >Subject: Re: proposed charter for TLS working group > >Tom Stephens wrote: >> >> In what areas are you in violent agreement with Eric? >> >> That TLS should be used instead of STLP in referring to the standard? >> >> That this may violate the spirit of IETF and we should do as much as >> possible via the mailing list, but that you will attend the meeting at >> the end of the month in the Bay Area if it is held? > >All of the above, which is why I didn't qualify it. > >-- >One tag to rule them all, One tag to find them; One tag | Tom Weinstein >to bring them all, and in the source tree bind them. | >tomw@netscape.com > From dpkemp@missi.ncsc.mil Wed May 8 08:58:38 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id IAA06540 for ; Wed, 8 May 1996 08:58:38 -0400 Received: from guardian.guard.ncsc.mil by www10.w3.org (5.0/NSCS-1.0S) id AA19399; Wed, 8 May 1996 08:58:25 +0500 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id IAA08738 for ; Wed, 8 May 1996 08:58:40 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma008730; Wed May 8 08:58:17 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 IAA29681 for ; Wed, 8 May 1996 08:54:34 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id IAA26871; Wed, 8 May 1996 08:58:12 -0400 Date: Wed, 8 May 1996 08:58:12 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199605081258.IAA26871@argon.ncsc.mil> To: ietf-tls@w3.org Subject: Re: proposed charter for TLS working group X-Sun-Charset: US-ASCII content-length: 1740 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls > By 'STLP' do you mean "Microsoft's proposal" or "the eventual > standard that the TLS working group produces"? > > "STLP" has become overloaded- some people take it mean Microsoft's > "strawman", others are using it as the name of the standard > that this group is discussing. Since the STLP strawman was clearly labeled as a "discussion draft" and "incomplete" and yet the media still immediately started calling it the Microsoft proposal, I don't think any name, including "TLS", would be immune from political influence. I'm agnostic on the choice - everyone here calls it "STLP or TLSP or whatever" anyway. > While I applaud your willingness to meet and to accomplish > things, I'm not sure that calling a meeting like this doesn't > voliate the spirit of the IETF. Only a few of the people who > have an interest in the working-group would be able to attend. > I think it would be more in keeping with the spirit of the IETF to > do as much as possible via the mailing list, where all can participate. > > Having said that, if there's a meeting in the bay area I won't miss it. As someone who won't be able to attend, I believe a face to face meeting would be valuable to speed things along. Other venues (hallways at IETF and USENIX) don't allow many of the interested parties to attend, yet that's where much of the work gets done. As long as the results of the meeting are reported out and those with objections have opportunity of reclama, I don't think a meeting violates the spirit of the IETF. Remember that the intelligence of a committee is inversely proportional to the square of the number of participants. A properly-composed small group may be able to move things along smartly, in both senses of the word. From paulh@imc.org Wed May 8 12:40:35 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id MAA19587 for ; Wed, 8 May 1996 12:40:35 -0400 Received: from imc.org by www10.w3.org (5.0/NSCS-1.0S) id AA21240; Wed, 8 May 1996 12:40:34 +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 JAA18780 for ; Wed, 8 May 1996 09:36:48 -0700 (PDT) X-Sender: paulh@imc.org (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 May 1996 09:38:39 -0700 To: ietf-tls@w3.org From: Paul Hoffman Subject: A new name for our protocol: SENT content-length: 944 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls On a slightly different note, none of the names that have been bandied about (TLS, STLP, or PCT, or SSL) are in the least bit pronounceable. This is meant to be a technology that will be widely used in many forms, and we're forcing the general population to spell it out when they say it. With that in mind, I propose that whatever protocol comes out of this group have a nice, meaningful acronym that can be pronounced in many languages as a single syllable. My suggestion, from French, is: SENT - S=E9curit=E9 en Niveau-Transport (For those with ASCII-only mail clients, there are acute accents over the two "e"s in Securite.) It says what we're doing (niveau meaning layer), the acronym is easy to pronounce in many languages, the acronym means nice things in French (feeling), the acronym means a somewhat relevant thing in English, and so on. And, it's about time that the IETF started naming things in languages other than English... From ChristopherA@consensus.com Wed May 8 14:30:14 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id OAA04126 for ; Wed, 8 May 1996 14:30:13 -0400 Received: from consensus.com (mail.consensus.com) by www10.w3.org (5.0/NSCS-1.0S) id AA02071; Wed, 8 May 1996 14:30:12 +0500 Received: from [157.22.240.12] by consensus.com with ESMTP (Apple Internet Mail Server 1.1); Wed, 8 May 1996 10:29:52 -0800 Message-Id: In-Reply-To: <199605081258.IAA26871@argon.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Organization: Consensus Development Corporation Date: Wed, 8 May 1996 11:29:31 -0700 To: ietf-tls@w3.org From: Christopher Allen Subject: Re: proposed charter for TLS working group content-length: 845 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls At 5:58 AM -0700 5/8/96, David P. Kemp wrote: >Remember that the intelligence of a committee is inversely proportional >to the square of the number of participants. A properly-composed >small group may be able to move things along smartly, in both senses >of the word. I agree with this statement. BTW, if the size of the group is small (say 7-10 or so) I'd be glad to host the meeting either in our Berkeley office or in our San Jose office. Both have access to workwalls. ------------------------------------------------------------------------ ..Christopher Allen Consensus Development Corporation.. .. 1563 Solano Avenue #355.. .. Berkeley, CA 94707-2116.. .. o510/559-1500 f510/559-1505.. From rodney@sabletech.com Wed May 8 14:51:42 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id OAA06677 for ; Wed, 8 May 1996 14:51:42 -0400 Received: from wizard.pn.com by www10.w3.org (5.0/NSCS-1.0S) id AA02305; Wed, 8 May 1996 14:51:35 +0500 Received: from massey (massey.ftp.com [128.127.128.152]) by wizard.pn.com (8.6.12) with SMTP id OAA09803 for ; Wed, 8 May 1996 14:51:23 -0400 Message-Id: <199605081851.OAA09803@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="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Wed, 08 May 1996 14:51:03 -0400 To: ietf-tls@w3.org From: Rodney Thayer Subject: A new name for our protocol: SENT content-length: 1887 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls sounds like a reasonable idea! >Resent-Date: Wed, 8 May 1996 12:41:36 -0400 >Resent-Message-Id: <199605081641.MAA19603@www19.w3.org> >X-Sender: paulh@imc.org (Unverified) >Date: Wed, 8 May 1996 09:38:39 -0700 >To: ietf-tls@w3.org >From: Paul Hoffman >Subject: A new name for our protocol: SENT >X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls >Resent-From: ietf-tls@w3.org >X-Mailing-List: archive/latest/121 >X-Loop: ietf-tls@w3.org >Sender: ietf-tls-request@w3.org >Resent-Sender: ietf-tls-request@w3.org > >On a slightly different note, none of the names that have been bandied >about (TLS, STLP, or PCT, or SSL) are in the least bit pronounceable. This >is meant to be a technology that will be widely used in many forms, and >we're forcing the general population to spell it out when they say it. > >With that in mind, I propose that whatever protocol comes out of this group >have a nice, meaningful acronym that can be pronounced in many languages as >a single syllable. My suggestion, from French, is: > >SENT - Sécurité en Niveau-Transport > >(For those with ASCII-only mail clients, there are acute accents over the >two "e"s in Securite.) It says what we're doing (niveau meaning layer), the >acronym is easy to pronounce in many languages, the acronym means nice >things in French (feeling), the acronym means a somewhat relevant thing in >English, and so on. And, it's about time that the IETF started naming >things in languages other than English... > > > > 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 tomste@microsoft.com Wed May 8 15:39:25 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id PAA13121 for ; Wed, 8 May 1996 15:39:24 -0400 Received: from abash1.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA02895; Wed, 8 May 1996 15:39:24 +0500 Received: by abash1.microsoft.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB3CD7.38D52AB0@abash1.microsoft.com>; Wed, 8 May 1996 12:09:35 -0700 Message-Id: From: Tom Stephens To: "'ietf-tls@w3.org'" , "'Christopher Allen'" Subject: RE: proposed charter for TLS working group Date: Wed, 8 May 1996 12:09:21 -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: 1481 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Based upon what I have seen on this list and discussions I have had, it looks as if we will have more than 10 attendees. I would like to propose meeting at one of the hotels in Palo Alto. Palo Alto is centrally located and we won't be imposing on any one company. If there are no objections, I will make some tentative arrangements and post the details on the list for your comments later today. Tom Stephens >---------- >From: Christopher Allen[SMTP:ChristopherA@consensus.com] >Sent: Wednesday, May 08, 1996 11:29 AM >To: ietf-tls@w3.org >Subject: Re: proposed charter for TLS working group > >At 5:58 AM -0700 5/8/96, David P. Kemp wrote: >>Remember that the intelligence of a committee is inversely proportional >>to the square of the number of participants. A properly-composed >>small group may be able to move things along smartly, in both senses >>of the word. > >I agree with this statement. > >BTW, if the size of the group is small (say 7-10 or so) I'd be glad to >host >the meeting either in our Berkeley office or in our San Jose office. >Both >have access to workwalls. > >------------------------------------------------------------------------ > >..Christopher Allen Consensus Development >Corporation.. >.. 1563 Solano Avenue >#355.. >.. Berkeley, CA >94707-2116.. >.. o510/559-1500 >f510/559-1505.. > > > From jis@mit.edu Wed May 8 17:26:06 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id RAA01168 for ; Wed, 8 May 1996 17:26:05 -0400 Received: from big-screw (BIG-SCREW.MIT.EDU) by www10.w3.org (5.0/NSCS-1.0S) id AA04288; Wed, 8 May 1996 17:26:04 +0500 Received: by big-screw id AA04633; Wed, 8 May 96 17:25:37 -0400 Sender: jis@mit.edu Message-Id: <31911131.41C6@mit.edu> Date: Wed, 08 May 1996 17:25:05 -0400 From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology X-Mailer: Mozilla 2.01 (X11; I; IRIX 5.2 IP22) Mime-Version: 1.0 To: Tom Stephens Cc: "'Win Treese'" , "'Christopher Allen'" , "'ietf-tls@w3.org'" Subject: Re: proposed charter for TLS working group References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 793 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Tom Stephens wrote: > Two weeks ago I posted to this alias an invitation for all interested > parties to meet and develop a draft which could be presented to this > working group at Montreal. I make that proposal again. Would you be > willing to be in the San Francisco Bay Area during the week of 5/27 ( > time and location can be announced this week) and resolve the issues you > and the others on this alias have raised? I won't be able to be on the West Coast that week (I have too many meetings and other commitments in and around Boston). However I would be willing to "Teleparticipate" if the meeting can be arranged for Monday or Tuesday (I have an all day commitment on Wednesday and will be traveling on Thursday and Friday [by bicycle]). -Jeff From elgamal@netscape.com Wed May 8 17:50:45 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id RAA05680 for ; Wed, 8 May 1996 17:50:44 -0400 Received: from urchin.netscape.com (h-198-95-250-59.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA04629; Wed, 8 May 1996 17:50:43 +0500 Received: from kingtut.mcom.com (h205-217-251-215.mcom.com [205.217.251.215]) by urchin.netscape.com (8.6.12/8.6.9) with SMTP id OAA05636 for ; Wed, 8 May 1996 14:51:28 -0700 Message-Id: <3191181E.7F22@netscape.com> Date: Wed, 08 May 1996 14:54:38 -0700 From: Taher Elgamal X-Mailer: Mozilla 2.01Gold (Win95; I) Mime-Version: 1.0 To: ietf-tls@w3.org Subject: [Fwd: HMAC-MD5: to be or not to be?] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 4476 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls This is forwarded to this group. We should keep the secrets in the inner hash in the MAC in SSSl/STLP/ the name of the day protocol. Taher HUGO@watson.ibm.com wrote: > > As it has been already announced in this list, MD5 is broken for collisions > (Hans Dobbertin has extended his own techniques used against MD4 to attack > MD5 as well). > MD5 needs to be dropped (hope everyone already did) from any use that > requires resistance to collisions by plain MD5. > > One application that is NOT broken with Dobbertin's attack is HMAC with MD5. > Collisions in plain MD5 do not compromise HMAC-MD5 as the latter uses > secret IVs and hides the result of the inner iterated function. > The question is whether the new attack has a significant potential > of being developed further to break also HMAC-MD5. > Beyond our own assessment we have got the opinion of a few first line > cryptographers that they see no way to make these techniques work against > the use of MD5 in HMAC. > > With permission of Hans Dobbertin I reproduce this note he sent to me > over the weekend in response to my question of whether he sees any > application of his results to break HMAC-MD5: > > Date: Sat, 4 May 1996 22:48:09 +0200 (MET DST) > From: Hans Dobbertin <> > To: "H.Krawczyk" > > Hi Hugo, > > I looked in your paper which you have sent me in January. To answer your > question I can assure you that I cannot image any way to attack MD5 as it > is used in HMAC. To be more precise, from the recent attack on MD5 > (compress) one cannot derive any reservation against the use of MD5 in > this context. (Perhaps one could argue that the randomness of MD5 is not > sufficiently investigated ..., but that is another question, and I > personally do not see a problem here.) > > Best regards, Hans > > This does not mean in any way that HMAC-MD5 is going to be secure forever. > It is only to stress that the new attack is not necessarily a reason to drop > MD5 from its current use in IPSEC. > > I believe that we can keep using it until new developments will bring > HMAC-MD5 closer to a break. Remember this "principle" from > draft-ietf-ipsec-hmac-md5-txt.00: > > Message authentication, as opposed to encryption, has a "transient" > effect. A published breaking of a message authentication scheme > would lead to the replacement of that scheme, but would > have no adversarial effect on information authenticated in the past. > This is in sharp contrast with encryption, where information encrypted > today may suffer from exposure in the future if, and when, the > encryption algorithm is broken. > > Following this principle I believe we can keep enjoying the better speed of > MD5 at least for some time (weeks? months? years? who knows?) > > Just to stress this: there is NO known security advantage in keeping > MD5 relative to going to SHA-1. The only issue here is performance. > It is there where the trade-off seems to favor MD5 right now. > > Having said all of this here is a short note on the theory behind HMAC-MD5. > In our paper we have chosen to make much stronger assumptions than needed > on the underlying hash function. This is motivated by the search of easy > to state and well-defined assumptions together with a simple and correct > analysis. One of these assumptions on the hash function which we call > "weakly collision resistance" requires resistance to collisions when the > IV is secret. In a strict sense such collisions can be found for MD5 > using Dobbertin's techniques. However, this is possible through > extension attacks that are prevented in HMAC by the outer application > of MD5. Therefore, the actual function HMAC-MD5 remains secure. > > In our coming Crypto'96 paper we will elaborate more on the analytical > issues and strength of assumptions. In particular, we may suggest an > additional (more conservative) variant of HMAC in which one appends a > key to the data before hashing (in the inner transformation). However, > this has to be seen as "yet another fence" and not something for which > there is clear indication that we need to adopt immediately. > > Bottom line: I suggest keeping HMAC-MD5 as defined now. (And being always > very attentive to updates from the cryptanalytic front.) > > Hugo -- Taher Elgamal elgamal@netscape.com Chief Scientist, Netscape Communications (T) 415 937 2898, (F) 415 428 4054 From dansimon@microsoft.com Wed May 8 19:11:18 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id TAA23310 for ; Wed, 8 May 1996 19:11:18 -0400 Received: from tide19.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA05859; Wed, 8 May 1996 19:11:17 +0500 Received: by tide19.microsoft.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB3CF8.CB7837B0@tide19.microsoft.com>; Wed, 8 May 1996 16:09:54 -0700 Message-Id: From: Dan Simon To: "'ietf-tls@w3.org'" , "'Taher Elgamal'" Subject: RE: [Fwd: HMAC-MD5: to be or not to be?] Date: Wed, 8 May 1996 16:09:47 -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: 1898 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls > >From: Taher Elgamal[SMTP:elgamal@netscape.com] > >This is forwarded to this group. We should keep the secrets in the >inner >hash in the MAC in SSSl/STLP/ the name of the day protocol. > >Taher Well, I certainly agree that if we keep MD5 around as a valid choice of hash function for MAC computation, then we should stick with HMAC. In that case, though, either MD5 should be removed from the "handshake hash" (or replaced with another, non-broken hash function), since it is used there without a key prefix to the input, or the "handshake hash" should be restructured as an HMAC-style MAC. (I'll make another pitch here for not explicitly specifying the hash function or functions used in the "handshake hash"; if this news about MD5 had come out a year later, then the body of the spec itself would have had to be revised, instead of just the list of valid hash functions). My own recommendation would be that use of MD5 simply be abandoned; after all, the new break affects not only the MAC method, but also (hash-and-)signature-based authentication, where no secret MAC key can be relied upon to make collision-finding harder. A more cryptographically correct alternative might be to define cipher suites with separate choices for "MAC hash function" and "signature hash function", with MD5 being permissible for the former (assuming HMAC-style MACs) but not the latter. An advantage of this approach would be that various superfast hash functions (Krawczyk's LFSR hash, Rogaway's "bucket hash") which are only useful for MACs could eventually be added as options. On the other hand, the extra complexity would make cipher suite management completely unwieldy. (Then again, I consider it to be already completely unwieldy, and would like to see each type of algorithm negotiated separately.) Daniel Simon Cryptographer, Microsoft Corp. dansimon@microsoft.com > > > From LANGFORD_SUSAN@tandem.com Wed May 8 20:23:11 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id UAA10262 for ; Wed, 8 May 1996 20:23:10 -0400 From: LANGFORD_SUSAN@tandem.com Received: from suntan.tandem.com by www10.w3.org (5.0/NSCS-1.0S) id AA06925; Wed, 8 May 1996 20:23:09 +0500 Received: from post.tandem.com \POS ,$ZNET by suntan.tandem.com (8.6.12/suntan5.960119) for id RAA24965; Wed, 8 May 1996 17:23:07 -0700 Received: by post.tandem.com \POS ,$ZNET 5 (4.13/4.5) id AA7481; 8 May 96 17:22:26 +1700 Date: 8 May 96 17:21:00 +1700 Message-Id: <199605081722.AA7481@post.tandem.com \POS ,$ZNET 5> To: maracchini_dave@tandem.com, ietf-tls@w3.org Subject: RE: [Fwd: HMAC-MD5: to be or not to be?] content-length: 683 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls > From: Dan Simon > > (I'll make another pitch > here for not explicitly specifying the hash function or functions used > in the "handshake hash"; if this news about MD5 had come out a year > later, then the body of the spec itself would have had to be revised, > instead of just the list of valid hash functions). Absolutely. Explicitly specifying the handshake hash functions in SSL is a weakness of the protocol, not a feature. Regarding the meeting in the Bay Area at the end of the month, someone from Atalla will certainly be there. (Probably myself and Dave Maracchini.) Susan Langford Sr. Cryptographic Analyst, Atalla langford_susan@tandem.com From tomw@netscape.com Wed May 8 21:21:30 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id VAA25439 for ; Wed, 8 May 1996 21:21:30 -0400 Received: from urchin.netscape.com (h-198-95-250-59.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA07856; Wed, 8 May 1996 21:21:29 +0500 Received: from ammodump (ammodump.mcom.com [205.217.232.97]) by urchin.netscape.com (8.6.12/8.6.9) with SMTP id SAA17999; Wed, 8 May 1996 18:17:27 -0700 Sender: tomw@netscape.com Message-Id: <31914761.3F54@netscape.com> Date: Wed, 08 May 1996 18:16:17 -0700 From: Tom Weinstein Organization: Netscape Communications, Inc. X-Mailer: Mozilla 3.0b4 (X11; U; IRIX 5.3 IP22) Mime-Version: 1.0 To: Dan Simon Cc: "'ietf-tls@w3.org'" , "'Taher Elgamal'" Subject: Re: [Fwd: HMAC-MD5: to be or not to be?] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 3508 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Dan Simon wrote: >> From: Taher Elgamal[SMTP:elgamal@netscape.com] >> >> This is forwarded to this group. We should keep the secrets in the >> inner hash in the MAC in SSSl/STLP/ the name of the day protocol. >> >> Taher > > Well, I certainly agree that if we keep MD5 around as a valid choice > of hash function for MAC computation, then we should stick with HMAC. > In that case, though, either MD5 should be removed from the "handshake > hash" (or replaced with another, non-broken hash function), since it > is used there without a key prefix to the input, or the "handshake > hash" should be restructured as an HMAC-style MAC. (I'll make another > pitch here for not explicitly specifying the hash function or > functions used in the "handshake hash"; if this news about MD5 had > come out a year later, then the body of the spec itself would have had > to be revised, instead of just the list of valid hash functions). I don't believe this is true. The way the handshake hashes are used in SSL 3.0 requires that a collision exist in both MD5 and SHA1 for the same pair of message streams. To construct such a collision is currently computationally infeasible. Negotiating the function(s) to be used in the handshake hashes allows a roll-back attack if any of the possible hash functions are compromised. > My own recommendation would be that use of MD5 simply be abandoned; I think that's a great idea. This attack certainly shows MD5 to be weaker than previously thought, but it's not totally broken. We should move away from MD5 as soon as reasonably possible, but I don't think we should panic and abandon existing standards without suitable replacements. > after all, the new break affects not only the MAC method, but also > (hash-and-)signature-based authentication, where no secret MAC key can > be relied upon to make collision-finding harder. What are you talking about? The MAC is SSL 3.0 is keyed and relies primarily on the secrecy of the key, not the collision intractability of the underlying hash function. Both places where signatures are used rely on both MD5 and SHA (except for DSA signing). What kind of attack do you think a hash collision could allow on the signed messages? > A more cryptographically correct alternative might be to define cipher > suites with separate choices for "MAC hash function" and "signature hash > function", with MD5 being permissible for the former (assuming > HMAC-style MACs) but not the latter. An advantage of this approach > would be that various superfast hash functions (Krawczyk's LFSR hash, > Rogaway's "bucket hash") which are only useful for MACs could > eventually be added as options. On the other hand, the extra > complexity would make cipher suite management completely unwieldy. > (Then again, I consider it to be already completely unwieldy, and > would like to see each type of algorithm negotiated separately.) I strongly oppose splitting the cipher suite up into several seperate "fields". It provides no extra level of flexibility or security and it only encourages people to mix and match algorithms in untested ways. As I already stated, I believe that allowing negotiation of the algorithm used for computing the handshake hashes allows a roll-back attack. The use of a single algorithm is also weaker than the paired algorithms currently used. -- One tag to rule them all, One tag to find them; One tag | Tom Weinstein to bring them all, and in the source tree bind them. | tomw@netscape.com From bsy@work.ucsd.edu Thu May 9 02:27:59 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id CAA00155 for ; Thu, 9 May 1996 02:27:58 -0400 Received: from odin.ucsd.edu by www10.w3.org (5.0/NSCS-1.0S) id AA13356; Thu, 9 May 1996 02:27:57 +0500 Received: from work.ucsd.edu by odin.ucsd.edu; id AA24123 sendmail 8.73/UCSDPSEUDO.4-CS via SMTP Wed, 8 May 96 23:27:56 -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 XAA06877; Wed, 8 May 1996 23:27:49 -0700 (PDT) Message-Id: <199605090627.XAA06877@work.ucsd.edu> To: Tom Weinstein , "'ietf-tls@w3.org'" Reply-To: Bennet Yee Subject: Re: [Fwd: HMAC-MD5: to be or not to be?] In-Reply-To: Your message of "Wed, 08 May 1996 18:16:17 -0700." <31914761.3F54@netscape.com> Date: Wed, 08 May 1996 23:27:48 -0700 From: Bennet Yee content-length: 4141 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls In message <31914761.3F54@netscape.com>, Tom Weinstein writes: > Dan Simon wrote: > > [ ... ] > > In that case, though, either MD5 should be removed from the "handshake > > hash" (or replaced with another, non-broken hash function), since it > > is used there without a key prefix to the input, or the "handshake > > hash" should be restructured as an HMAC-style MAC. (I'll make another > > pitch here for not explicitly specifying the hash function or > > functions used in the "handshake hash"; if this news about MD5 had > > come out a year later, then the body of the spec itself would have had > > to be revised, instead of just the list of valid hash functions). > > I don't believe this is true. The way the handshake hashes are used in > SSL 3.0 requires that a collision exist in both MD5 and SHA1 for the same > pair of message streams. To construct such a collision is currently > computationally infeasible. Negotiating the function(s) to be used in the > handshake hashes allows a roll-back attack if any of the possible hash > functions are compromised. The point is that the hash has to be "possible". The idea with having the functions separately negotiable is that the user is involved when researchers announce new techniques to void the collision intractibility assumption -- GUI or user-accessible configuration files must be provided so that the user can easily turn off a broken hash. Alternatively, an automated revocation-list style of operation is possible. This, I believe, is the approach that Dan Simon is advocating. I think that this is a reasonable approach. The SSLv3 approach seems to be to try to use multiple hashes to build up a more-collision-intractible hash for the handshake hashes. On the face of it, this looks pretty reasonable too and avoids issues with user confusion / service calls. There is a "however" side to this: I don't believe that anybody has calculated/proven the actual security of the alternating SHA/MD5 constructions (relative to the security of the base hash functions) used for generating key material. If the construction were really sound, maybe it'll be of interest to researchers since it'd be a general way to build more-collision-intractible functions from less-so ones. Furthermore, if there is a real need to build stronger hashes out of possibly weak ones, then why are we limiting ourselves to just MD5 and SHA? To just one application of this collision-intractibility "strengthening" construction? > > after all, the new break affects not only the MAC method, but also > > (hash-and-)signature-based authentication, where no secret MAC key can > > be relied upon to make collision-finding harder. > > What are you talking about? The MAC is SSL 3.0 is keyed and relies > primarily on the secrecy of the key, not the collision intractability > of the underlying hash function. Both places where signatures are used > rely on both MD5 and SHA (except for DSA signing). What kind of attack > do you think a hash collision could allow on the signed messages? In STLP there are options to use a signature key to authenticate; see the response message, 5.2.5, in the STLP draft. Like SSLv2's client authentication, but more symmetric. Furthermore, the world is larger than PCT/SSL/STLP/TLA-of-the-day. The PKCS standards, for example. > As I already stated, I believe that allowing negotiation of the algorithm > used for computing the handshake hashes allows a roll-back attack. The > use of a single algorithm is also weaker than the paired algorithms > currently used. A roll-back attack is possible only if the hash function remains enabled. Whether a revocation style of cryptographic primitive management to automate things is doable or manual, user intervention is used, it -is- possible to disable the use of some crypto-primitives. Completely disabling a (newly found to be) weak crypto-primitive is preferable to leaving it in place. -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 tomw@netscape.com Thu May 9 03:29:56 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id DAA13379 for ; Thu, 9 May 1996 03:29:55 -0400 Received: from urchin.netscape.com (h-198-95-250-59.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA14200; Thu, 9 May 1996 03:29:55 +0500 Received: from ammodump (ammodump.mcom.com [205.217.232.97]) by urchin.netscape.com (8.6.12/8.6.9) with SMTP id AAA29716; Thu, 9 May 1996 00:30:09 -0700 Sender: tomw@netscape.com Message-Id: <31919EC3.237C@netscape.com> Date: Thu, 09 May 1996 00:29:07 -0700 From: Tom Weinstein Organization: Netscape Communications, Inc. X-Mailer: Mozilla 3.0b4 (X11; U; IRIX 5.3 IP22) Mime-Version: 1.0 To: Bennet Yee Cc: "'ietf-tls@w3.org'" Subject: Re: [Fwd: HMAC-MD5: to be or not to be?] References: <199605090627.XAA06877@work.ucsd.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 5712 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Bennet Yee wrote: > In message <31914761.3F54@netscape.com>, Tom Weinstein writes: >> Dan Simon wrote: >>> [ ... ] >>> In that case, though, either MD5 should be removed from the "handshake >>> hash" (or replaced with another, non-broken hash function), since it >>> is used there without a key prefix to the input, or the "handshake >>> hash" should be restructured as an HMAC-style MAC. (I'll make another >>> pitch here for not explicitly specifying the hash function or >>> functions used in the "handshake hash"; if this news about MD5 had >>> come out a year later, then the body of the spec itself would have had >>> to be revised, instead of just the list of valid hash functions). >> >> I don't believe this is true. The way the handshake hashes are used in >> SSL 3.0 requires that a collision exist in both MD5 and SHA1 for the >> same pair of message streams. To construct such a collision is >> currently computationally infeasible. Negotiating the function(s) to be >> used in the handshake hashes allows a roll-back attack if any of the >> possible hash functions are compromised. > > The point is that the hash has to be "possible". The idea with having > the functions separately negotiable is that the user is involved when > researchers announce new techniques to void the collision > intractibility assumption -- GUI or user-accessible configuration > files must be provided so that the user can easily turn off a broken > hash. Alternatively, an automated revocation-list style of operation > is possible. This, I believe, is the approach that Dan Simon is > advocating. I think that this is a reasonable approach. > > The SSLv3 approach seems to be to try to use multiple hashes to build > up a more-collision-intractible hash for the handshake hashes. On the > face of it, this looks pretty reasonable too and avoids issues with > user confusion / service calls. There is a "however" side to this: I > don't believe that anybody has calculated/proven the actual security > of the alternating SHA/MD5 constructions (relative to the security of > the base hash functions) used for generating key material. If the > construction were really sound, maybe it'll be of interest to > researchers since it'd be a general way to build > more-collision-intractible functions from less-so ones. Furthermore, > if there is a real need to build stronger hashes out of possibly weak > ones, then why are we limiting ourselves to just MD5 and SHA? To just > one application of this collision-intractibility "strengthening" > construction? I think there are two different philosophies about how to react to a failure of one of the MAC functions. The SSL 3.0 philosophy seeks to design a redundant system that can withstand a single failure but then requires a patch to regain the redundancy. The STLP strawman philosophy allows a failure to compromise the system, but allows it to be fixed by a simple configuration change on the part of either party. Both philosophies have merit. Incidentally, the handshake hashes in the final version of the SSL spec are computed as (MD5(MD5()) + SHA(SHA())), not (MD5(SHA()) + SHA(MD5())) as in early versions. We felt that not alternating algorithms provided at least the same level of collision intractability without the somewhat dubious mixing of algorithms that you seem to be concerned about. The assumption then is that the algorithms are sufficiently unrelated so as to provide uncorrelated outputs. >>> after all, the new break affects not only the MAC method, but also >>> (hash-and-)signature-based authentication, where no secret MAC key can >>> be relied upon to make collision-finding harder. >> >> What are you talking about? The MAC is SSL 3.0 is keyed and relies >> primarily on the secrecy of the key, not the collision intractability >> of the underlying hash function. Both places where signatures are used >> rely on both MD5 and SHA (except for DSA signing). What kind of attack >> do you think a hash collision could allow on the signed messages? > > In STLP there are options to use a signature key to authenticate; see > the response message, 5.2.5, in the STLP draft. Like SSLv2's client > authentication, but more symmetric. Furthermore, the world is larger > than PCT/SSL/STLP/TLA-of-the-day. The PKCS standards, for example. Yes, I'd agree that MD5 should certainly not be used for the STLP response message. It seems to depend fairly strongly on the collision intractability of the hash function. I also agree with you that everyone should move away from MD5. I expect that MD5 will be in very bad shape in the not too distant future. >> As I already stated, I believe that allowing negotiation of the >> algorithm used for computing the handshake hashes allows a roll-back >> attack. The use of a single algorithm is also weaker than the paired >> algorithms currently used. > > A roll-back attack is possible only if the hash function remains > enabled. Whether a revocation style of cryptographic primitive > management to automate things is doable or manual, user intervention > is used, it -is- possible to disable the use of some > crypto-primitives. Completely disabling a (newly found to be) weak > crypto-primitive is preferable to leaving it in place. Absolutely. But the only way to defeat the roll-back attack is to have every installed product that uses the insecure algorithm configure it off. Personally, I worry that as more and more naive users begin to rely on cryptographic software, it will become harder for us to do that. -- One tag to rule them all, One tag to find them; One tag | Tom Weinstein to bring them all, and in the source tree bind them. | tomw@netscape.com From karlton@netscape.com Thu May 9 03:52:56 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id DAA13849 for ; Thu, 9 May 1996 03:52:55 -0400 Received: from ghoti.mcom.com (h-205-217-232-38.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA14311; Thu, 9 May 1996 03:52:55 +0500 Received: from ghoti (localhost [127.0.0.1]) by ghoti.mcom.com (940816.SGI.8.6.9/8.6.9) with SMTP id AAA29505; Thu, 9 May 1996 00:52:46 -0700 Sender: karlton@netscape.com Message-Id: <3191A44E.167E@netscape.com> Date: Thu, 09 May 1996 00:52:46 -0700 From: Phil Karlton Organization: Netscape Communications X-Mailer: Mozilla 3.0b4 (X11; U; IRIX 5.3 IP22) Mime-Version: 1.0 To: Tom Stephens Cc: "'Rodney Thayer'" , "'pcttalk@ftp.com'" , "'ietf-tls@w3.org'" Subject: Re: which to implement? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 2410 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Tom Stephens wrote: > > >SSLv3 and PCTv2 are both PAPER protocols. SSL 3 is NOT just a paper protocol. It exists in products currently in Beta. There are at least 5 independent implementations currently interoperating. I know of at least 4 more implementation efforts that are underway (2 in Java and 1 in Perl). > We're living with SSLv2 and > PCTv1 in real code, and we all agree that's not good enough. The > purpose of this TLS working group is to come up with something more > secure and more open, In what way is SSL 3 not open? > but I agree with Win and Taher that we need to be > in Final Draft form by July to have an IETF standard in 1996. This is > critical to all of us so that we don't have to even think about what we > implement. "STLP" should be the Internet standard - so let's get > serious about what's in it, so we can all get on with the code. Thousands of hours have gone into the development of SSL 3 (by engineers both inside of Netscape and out). Much of that time was devoted to analysis of the cryptographic properties. I can only assume that a similar amount of work went into PCT v2. The Microsoft strawman draft of STLP has not had that kind of analysis. The amount of work to come to the same degree of confidence in a protocol or implementation grows exponentially as the design gets more complicated. It's a sad fact that while adding feature A or feature B to an existing design, no compromise in the security of the system will result, but adding both can open an overlooked covert channel. The STLP strawman is more complicated than either SSL 3 or PCT 2. I don't think it is a reasonable starting point if we hope to make the schedules outlines in the charter. > >Do any of you want to sit down together for a day and work up an STLP > >draft to present to the whole working group before the IETF meeting in > >June? It would be naive to expect a day or two of meetings to be able to resolve some very difficult issues. While security is no longer my primary focus at Netscape, I will find the time to try and address some of the issues related to MACs, pre-encrypted files, etc. PK -- Philip L. Karlton karlton@netscape.com Principal Curmudgeon http://home.netscape.com/people/karlton Netscape Communications They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin From naganand@ftp.com Thu May 9 08:32:34 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id IAA21104 for ; Thu, 9 May 1996 08:32:33 -0400 Received: from ftp.com by www10.w3.org (5.0/NSCS-1.0S) id AA15745; Thu, 9 May 1996 08:32:34 +0500 Received: from ftp.com by ftp.com ; Thu, 9 May 1996 08:32:33 -0400 Received: from athena.ftp.com by ftp.com ; Thu, 9 May 1996 08:32:33 -0400 Message-Id: <2.2.32.19960509123554.003766c4@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 09 May 1996 08:35:54 -0400 To: ietf-tls@w3.org From: Naganand Doraswamy Subject: Pointer to SLTP document content-length: 189 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Could someone kindly give me a pointer to the SLTP document? Thanks, --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From dpkemp@missi.ncsc.mil Thu May 9 09:38:31 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id JAA04756 for ; Thu, 9 May 1996 09:38:24 -0400 Received: from guardian.guard.ncsc.mil by www10.w3.org (5.0/NSCS-1.0S) id AA16758; Thu, 9 May 1996 09:38:24 +0500 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id JAA17405 for ; Thu, 9 May 1996 09:38:39 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma017403; Thu May 9 09:38:12 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 JAA03161 for ; Thu, 9 May 1996 09:34:31 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id JAA27844; Thu, 9 May 1996 09:38:07 -0400 Date: Thu, 9 May 1996 09:38:07 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199605091338.JAA27844@argon.ncsc.mil> To: ietf-tls@w3.org Subject: Re: [Fwd: HMAC-MD5: to be or not to be?] X-Sun-Charset: US-ASCII content-length: 3426 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls > Date: Wed, 08 May 1996 18:16:17 -0700 > From: Tom Weinstein > I strongly oppose splitting the cipher suite up into several seperate > "fields". It provides no extra level of flexibility or security and it > only encourages people to mix and match algorithms in untested ways. > As I already stated, I believe that allowing negotiation of the algorithm > used for computing the handshake hashes allows a roll-back attack. The > use of a single algorithm is also weaker than the paired algorithms > currently used. I agree with Mr. Yee's point that both approaches (fixed single method with diverse algorithms, and multiple negotiated single-algorithm options) have merit. But I believe that the split cipher suite method has more merit. This discussion isn't about splitting it into several separate fields, it's about splitting it into two fields - MAC and everything else. Despite repeated warnings about untested mixing and matching, I can't see how switching between multiple hash functions in the MAC computation can have any hidden effect on the security of the bulk cipher or key exchange or certificate management. (There is of course the obvious effect - Bellovin has shown that encryption without integrity is weak). If there are any ideas about how switching between two equally-strong MAC algorithms (say SHA and RIPEMD-160) could affect the security of the rest of the cipher suite, I'd like to hear them. There is no reason why the two approaches couldn't be combined - some of the split-cipher-suite MAC options could be algorithm combinations, including MD5+SHA. It would be nice to avoid combinatorial explosion here, but a few useful combinations could be chosen. Mr. Dobbertin and Mr. Krawczyk believe that there is still some life left in MD5 as long as it's used in a HMAC-type nested structure. This vindicates the merits of using this type of MAC structure, and should put to rest any thoughts of using a simpler structure to make precomputation easier. > Date: Thu, 09 May 1996 00:29:07 -0700 > From: Tom Weinstein > > > > A roll-back attack is possible only if the hash function remains > > enabled. Whether a revocation style of cryptographic primitive > > management to automate things is doable or manual, user intervention > > is used, it -is- possible to disable the use of some > > crypto-primitives. Completely disabling a (newly found to be) weak > > crypto-primitive is preferable to leaving it in place. > > Absolutely. But the only way to defeat the roll-back attack is to have > every installed product that uses the insecure algorithm configure it off. > Personally, I worry that as more and more naive users begin to rely on > cryptographic software, it will become harder for us to do that. There are at least three ways to address algorithm roll-back attacks: 1) rely on user configuration to disable newly-found-to-be-insecure options, then remove the option in the next product release. This sacrifices backward compatibility. 2) address it as version rollbacks are currently addressed in SSL V3 - maintain compatibility with downrev peers but make it impossible for two current peers to negotiate a downrev insecure algorithm. 3) allow user configuration but provide no mechanism to prevent two current peers from negotiating downrev options. Hopefully will not go this route. From tomste@microsoft.com Thu May 9 12:29:56 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id MAA14594 for ; Thu, 9 May 1996 12:29:56 -0400 Received: from abash1.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA21407; Thu, 9 May 1996 12:29:55 +0500 Received: by abash1.microsoft.com with Microsoft Exchange (IMC 4.0.838.14) id <01BB3D89.5815D3E0@abash1.microsoft.com>; Thu, 9 May 1996 09:24:38 -0700 Message-Id: From: Tom Stephens To: "'Naganand Doraswamy'" Cc: "'ietf-tls@w3.org'" Subject: RE: Pointer to SLTP document Date: Thu, 9 May 1996 09:24:37 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.14 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit content-length: 411 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls It's located at: http://pct.microsoft.com/stlp >---------- >From: Naganand Doraswamy[SMTP:naganand@ftp.com] >Sent: Thursday, May 09, 1996 5:35 AM >To: ietf-tls@w3.org >Subject: Pointer to SLTP document > >Could someone kindly give me a pointer to the SLTP document? > >Thanks, > >--Naganand >---------------------------------------------------------------- >naganand@ftp.com >Tel #: (508)684-6743 (O) > > From bsy@work.ucsd.edu Thu May 9 13:44:38 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id NAA21008 for ; Thu, 9 May 1996 13:44:37 -0400 Received: from odin.ucsd.edu by www10.w3.org (5.0/NSCS-1.0S) id AA23695; Thu, 9 May 1996 13:44:37 +0500 Received: from work.ucsd.edu by odin.ucsd.edu; id AA22035 sendmail 8.73/UCSDPSEUDO.4-CS via SMTP Thu, 9 May 96 10:44:29 -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 KAA18131; Thu, 9 May 1996 10:44:18 -0700 (PDT) Message-Id: <199605091744.KAA18131@work.ucsd.edu> To: Phil Karlton Cc: Tom Stephens , "'Rodney Thayer'" , "'pcttalk@ftp.com'" , "'ietf-tls@w3.org'" Reply-To: Bennet Yee Subject: Re: which to implement? In-Reply-To: Your message of "Thu, 09 May 1996 00:52:46 -0700." <3191A44E.167E@netscape.com> Date: Thu, 09 May 1996 10:44:16 -0700 From: Bennet Yee content-length: 2865 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls In message <3191A44E.167E@netscape.com>, Phil Karlton writes: > > In what way is SSL 3 not open? AFAIK, the feature set was determined almost solely by Netscape. If we look at other standards in IETF/IEEE/ANSI/etc, we see a mix of both adapt-a-de-facto-standard and standards making by a committee. I don't claim that standards making by committee is necessarily a good thing, but I would say that adapt-a-de-facto-standard is not a particularly "open" process. While perhaps many programmer / cryptographer hours have already been spent on SSLv3, it is not "entrenched" like SSLv2. Anyways, these are more of the business side of things than technical, and I am a little leary about having to deal with it. Certainly, we need to decide how much attention we, as an IETF working group rather than as workers for some particular company or as academics, should be pay to the (cost of the) effort already spent. If we pay too much attention to it, then we might as well disband the working group and just adopt SSLv2. (Or 3. Or PCTv1 or 2. Pick your own poison.) > The Microsoft strawman draft of STLP has not had that kind of analysis. > The amount of work to come to the same degree of confidence in a > protocol or implementation grows exponentially as the design gets more > complicated. It's a sad fact that while adding feature A or feature B to > an existing design, no compromise in the security of the system will > result, but adding both can open an overlooked covert channel. Ah, technical claims. Please be careful about your terminology. A "covert channel" has a very specific meaning to people working in security, and I don't think that meaning is what you intended. Certainly as I had discussed earlier regarding the privacy issue that D. Wagner had pointed out, *all* of the protocols leak enough information for an eavesdropper to subsequently probe a web site and determine what object the user was viewing. There's probably enough muddling of minds out there already. Regarding the exponential growth of complexity. While cryptographic protocol composability is still an active area of research, the functionality changes in STLP are not exactly complicated. Certainly in systems design (and also possible to a certain extent in cryptographic protocol design) we layer components to reduce the design complexity -- when I hack code I certainly try to modularize things, and much of the same techniques apply to protocol design (esp the non-cryptographic components, such as record fragmentation or compression). To claim an exponential increase is wrong -- you've even had some experience in modularizing a protocol's design. -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 Thu May 9 14:22:12 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id OAA10276 for ; Thu, 9 May 1996 14:22:12 -0400 Received: from urchin.netscape.com (h-198-95-250-59.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA24860; Thu, 9 May 1996 14:22:11 +0500 Received: from kingtut.mcom.com (h205-217-251-215.mcom.com [205.217.251.215]) by urchin.netscape.com (8.6.12/8.6.9) with SMTP id LAA16678; Thu, 9 May 1996 11:21:08 -0700 Message-Id: <31923857.872@netscape.com> Date: Thu, 09 May 1996 11:24:23 -0700 From: Taher Elgamal X-Mailer: Mozilla 2.01Gold (Win95; I) Mime-Version: 1.0 To: Bennet Yee Cc: Phil Karlton , Tom Stephens , "'Rodney Thayer'" , "'pcttalk@ftp.com'" , "'ietf-tls@w3.org'" Subject: Re: which to implement? References: <199605091744.KAA18131@work.ucsd.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 3336 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Bennet Yee wrote: > > In message <3191A44E.167E@netscape.com>, Phil Karlton writes: > > > > In what way is SSL 3 not open? > > AFAIK, the feature set was determined almost solely by Netscape. If > we look at other standards in IETF/IEEE/ANSI/etc, we see a mix of both > adapt-a-de-facto-standard and standards making by a committee. I > don't claim that standards making by committee is necessarily a good > thing, but I would say that adapt-a-de-facto-standard is not a > particularly "open" process. While perhaps many programmer / > cryptographer hours have already been spent on SSLv3, it is not > "entrenched" like SSLv2. > You are dead wrong. SSL3 feature set was actually taken fromcomments that were sent to us by about 12 companies or so -- the ones that cared to give us comments that is. Please review your facts. > Anyways, these are more of the business side of things than technical, > and I am a little leary about having to deal with it. Certainly, we > need to decide how much attention we, as an IETF working group rather > than as workers for some particular company or as academics, should be > pay to the (cost of the) effort already spent. If we pay too much > attention to it, then we might as well disband the working group and > just adopt SSLv2. (Or 3. Or PCTv1 or 2. Pick your own poison.) > > > The Microsoft strawman draft of STLP has not had that kind of analysis. > > The amount of work to come to the same degree of confidence in a > > protocol or implementation grows exponentially as the design gets more > > complicated. It's a sad fact that while adding feature A or feature B to > > an existing design, no compromise in the security of the system will > > result, but adding both can open an overlooked covert channel. > > Ah, technical claims. > > Please be careful about your terminology. A "covert channel" has a > very specific meaning to people working in security, and I don't think > that meaning is what you intended. Certainly as I had discussed > earlier regarding the privacy issue that D. Wagner had pointed out, > *all* of the protocols leak enough information for an eavesdropper to > subsequently probe a web site and determine what object the user was > viewing. > > There's probably enough muddling of minds out there already. > > Regarding the exponential growth of complexity. While cryptographic > protocol composability is still an active area of research, the > functionality changes in STLP are not exactly complicated. Certainly > in systems design (and also possible to a certain extent in > cryptographic protocol design) we layer components to reduce the > design complexity -- when I hack code I certainly try to modularize > things, and much of the same techniques apply to protocol design (esp > the non-cryptographic components, such as record fragmentation or > compression). To claim an exponential increase is wrong -- you've > even had some experience in modularizing a protocol's design. > > -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 -- Taher Elgamal elgamal@netscape.com Chief Scientist, Netscape Communications (T) 415 937 2898, (F) 415 428 4054 From bsy@work.ucsd.edu Thu May 9 14:35:55 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id OAA17307 for ; Thu, 9 May 1996 14:35:55 -0400 Received: from odin.ucsd.edu by www10.w3.org (5.0/NSCS-1.0S) id AA25290; Thu, 9 May 1996 14:35:54 +0500 Received: from work.ucsd.edu by odin.ucsd.edu; id AA24861 sendmail 8.73/UCSDPSEUDO.4-CS via SMTP Thu, 9 May 96 11:35:52 -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 LAA19499; Thu, 9 May 1996 11:35:50 -0700 (PDT) Message-Id: <199605091835.LAA19499@work.ucsd.edu> To: Taher Elgamal Cc: Phil Karlton , Tom Stephens , "'Rodney Thayer'" , "'pcttalk@ftp.com'" , "'ietf-tls@w3.org'" Reply-To: Bennet Yee Subject: Re: which to implement? In-Reply-To: Your message of "Thu, 09 May 1996 11:24:23 -0700." <31923857.872@netscape.com> Date: Thu, 09 May 1996 11:35:48 -0700 From: Bennet Yee content-length: 1658 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls In message <31923857.872@netscape.com>, Taher Elgamal writes: > Bennet Yee wrote: > > > > In message <3191A44E.167E@netscape.com>, Phil Karlton writes: > > > > > > In what way is SSL 3 not open? > > > > AFAIK, the feature set was determined almost solely by Netscape. If > > we look at other standards in IETF/IEEE/ANSI/etc, we see a mix of both > > adapt-a-de-facto-standard and standards making by a committee. I > > don't claim that standards making by committee is necessarily a good > > thing, but I would say that adapt-a-de-facto-standard is not a > > particularly "open" process. While perhaps many programmer / > > cryptographer hours have already been spent on SSLv3, it is not > > "entrenched" like SSLv2. > > You are dead wrong. SSL3 feature set was actually taken fromcomments > that were sent to us by about 12 companies or so -- the ones that cared > to give us comments that is. Please review your facts. Taher, Please pardon me for not knowing the details about the process using which SSLv3 was created. I had heard about the SSLv3 in draft form while at MS (the current[?] evil empire), but it was already quite far along, and must have missed any call-for-participation that went out earlier. My other points about the direction of IETF and needing to decide on how weight to give to the effort already expended by various companies or researchers, as well as about care in using security/cryptography terminology still stand. -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 dansimon@microsoft.com Thu May 9 15:09:12 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id PAA03153 for ; Thu, 9 May 1996 15:09:11 -0400 Received: from tide21.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA26372; Thu, 9 May 1996 15:09:11 +0500 Received: by tide21.microsoft.com with Microsoft Exchange (IMC 4.0.838.14) id <01BB3DA0.20E1C7F0@tide21.microsoft.com>; Thu, 9 May 1996 12:07:43 -0700 Message-Id: From: Dan Simon To: "'Bennet Yee'" , "'Tom Weinstein'" Cc: "'ietf-tls@w3.org'" Subject: RE: [Fwd: HMAC-MD5: to be or not to be?] Date: Thu, 9 May 1996 12:07:40 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.14 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit content-length: 2838 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls >From: Tom Weinstein[SMTP:tomw@netscape.com] > > >I think there are two different philosophies about how to react to a >failure of one of the MAC functions. The SSL 3.0 philosophy seeks to >design a redundant system that can withstand a single failure but then >requires a patch to regain the redundancy. The STLP strawman >philosophy >allows a failure to compromise the system, but allows it to be fixed by >a simple configuration change on the part of either party. Both >philosophies have merit. If it is believed that SHA is not dependable enough, but that SHA concatenated with MD5 *is*, then a natural solution is to define a new hash function consisting of the concatenation of the two (call it SHAMD5 :^), and include it as an optional hash function for the protocol (perhaps as a separate "handshake/signature authentication hash function" parameter--once again, we see the value of negotiating security parameters independently.....). Implementers and administrators are then free to support SHAMD5--perhaps *only* SHAMD5--as their hash function of choice (for handshake and signature authentication, or even for general use). Alternatively, the protocol could negotiate a "primary" and "secondary" hash function, so that redundant MAC constructions could continue to be redundant into the future (unlike the SSL v3.0 "redundant" construction, which now turns out to be much less redundant than it was originally thought to be). I expect it would be simpler, however, just to define these combined hash functions as they become necessary. (SHARIPEMD, anyone?) And it's certainly less appealing to require what amounts to a significant protocol revision every time an explicitly embedded hash function is broken. > >> A roll-back attack is possible only if the hash function remains >> enabled. Whether a revocation style of cryptographic primitive >> management to automate things is doable or manual, user intervention >> is used, it -is- possible to disable the use of some >> crypto-primitives. Completely disabling a (newly found to be) weak >> crypto-primitive is preferable to leaving it in place. > >Absolutely. But the only way to defeat the roll-back attack is to have >every installed product that uses the insecure algorithm configure it >off. >Personally, I worry that as more and more naive users begin to rely on >cryptographic software, it will become harder for us to do that. Maybe I'm out of touch, but I would expect users to be more likely to toggle a configuration switch to disable a broken hash function than to install a new implementation of the next version of the protocol, whose only change from the previous version is in the pair of hash functions chosen for its "redundant" MAC construction. Daniel Simon Cryptographer, Microsoft Corp. dansimon@microsoft.com > > > > From karlton@netscape.com Thu May 9 17:38:37 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id RAA19082 for ; Thu, 9 May 1996 17:38:36 -0400 Received: from ghoti.mcom.com (h-205-217-232-38.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA01212; Thu, 9 May 1996 17:38:34 +0500 Received: from ghoti (localhost [127.0.0.1]) by ghoti.mcom.com (940816.SGI.8.6.9/8.6.9) with SMTP id OAA17758; Thu, 9 May 1996 14:37:13 -0700 Sender: karlton@netscape.com Message-Id: <31926588.59E2@netscape.com> Date: Thu, 09 May 1996 14:37:13 -0700 From: Phil Karlton Organization: Netscape Communications X-Mailer: Mozilla 3.0b4 (X11; U; IRIX 5.3 IP22) Mime-Version: 1.0 To: Bennet Yee Cc: Tom Stephens , "'Rodney Thayer'" , "'pcttalk@ftp.com'" , "'ietf-tls@w3.org'" Subject: Re: which to implement? References: <199605091744.KAA18131@work.ucsd.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 2340 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Bennet Yee wrote: > > In message <3191A44E.167E@netscape.com>, Phil Karlton writes: > > > > In what way is SSL 3 not open? > > AFAIK, the feature set was determined almost solely by Netscape. Let me correct that assumption. Features are in SSL 3 that Netscape has no plans to use. They are there because those that involved themselves in the early design asked for them. (For instance, the anonymous Diffie-Helman key exchange is in there to support protocols where MITM attacks are not an issue.) Public responses to the initial sketches for SSL 3 were coming in as early as August, 1995. Microsoft has had copies of the spec since at least November, 1995. There was been no feedback from Microsoft (asking questions or making suggestions) until a completely rewritten spec showed up the month after final SSL 3.0 spec went out. > Certainly, we > need to decide how much attention we, as an IETF working group rather > than as workers for some particular company or as academics, should be > pay to the (cost of the) effort already spent. If we pay too much > attention to it, then we might as well disband the working group and > just adopt SSLv2. (Or 3. Or PCTv1 or 2. Pick your own poison.) I disagree. The output of this working group will not be a protocol that gets picked once in 1996 and never changes. Even before the March draft was finished, consideration was being given as to what was needed for 3.1. (Support for attribute certificates was high on that list.) It would be good if this group was driving that process. What I am arguing for is to take SSL 3.0 as a base and to grow it with the features that are needed. Dropping a 35 page counter-proposal onto the table containing changes ranging from UDP support to password authentication means that efforts will not be focused on the respective ideas. > Please be careful about your terminology. A "covert channel" has a > very specific meaning to people working in security, and I don't think > that meaning is what you intended. I apologize for using the wrong word at 1:00 am. PK -- Philip L. Karlton karlton@netscape.com Principal Curmudgeon http://home.netscape.com/people/karlton Netscape Communications They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin From bfox@microsoft.com Thu May 9 20:30:51 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id UAA28373 for ; Thu, 9 May 1996 20:30:50 -0400 Received: from tide19.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA07220; Thu, 9 May 1996 20:30:49 +0500 Received: by tide19.microsoft.com with Microsoft Exchange (IMC 4.0.838.14) id <01BB3DCC.19AFB970@tide19.microsoft.com>; Thu, 9 May 1996 17:22:29 -0700 Message-Id: From: Barb Fox To: "'Bennet Yee'" , "'Phil Karlton'" Cc: Tom Stephens , "'Rodney Thayer'" , "'pcttalk@ftp.com'" , "'ietf-tls@w3.org'" Subject: RE: which to implement? Date: Thu, 9 May 1996 17:22:20 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.14 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit content-length: 4888 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Phil: Well, at least this list is getting lively! Let me try to address the points you made in both your recent posts. First: I know for a fact that Netscape solicited comments on SSLv3 pre-publication, as an Internet Draft, and moderated SSL-talk. There were plenty of comments and many of these along with some of the work we did with PCT are reflected in SSLv3. ( I point specifically to separation of MAC and encryption key lengths and a shorter, more efficient handshake message flow which showed up in SSL after PCT was published.) But my real point is that what went in and what didn't was primarily a Netscape decision. As Taher said earlier, you chose from the comments you received. Understandable - SSL is your protocol and you've got code to write, after all. But now we're at a different stage in the standards-setting process. We're talking about an Internet Standard, and comments/contributions should come from the whole Internet community. Frankly, only a small subset really cares, but from what we've seen so far, there are more than a few who want to show up in person to work on what will become TLS. We all seem to agree that SSLv3 is a good starting point, but the robust discussions on the TLS list point out the need for some modifications/improvements before we call it TLSv1. This kind of collaboration has got to be the best way to get a widely-endorsed (and implemented!) standard quickly. That's the whole reason we're coming and why we're not building a bunker around PCT and just defending it. Why should we all go to the trouble of submitting anything to the IETF on the standards track if it isn't better than what's already out there - and more important, we all get to choose what gets in it? Interoperability and open change control says it all. You're also right that we cannot expect a one or two day meeting to resolve all of the complex issues raised on the TLS list. But what we can do in this meeting - and in subsequent discussions on this list - is to get more people thinking and commenting. The working group should take full ownership of the protocol, and this is a great time to start. The meeting is at the Garden Court in Palo Alto on May 29th. I hope you and Taher can be there. Barbara Fox Microsoft ---------- From: Phil Karlton[SMTP:karlton@netscape.com] Sent: Thursday, May 09, 1996 2:37 PM To: Bennet Yee Cc: Tom Stephens; 'Rodney Thayer'; 'pcttalk@ftp.com'; 'ietf-tls@w3.org' Subject: Re: which to implement? Bennet Yee wrote: > > In message <3191A44E.167E@netscape.com>, Phil Karlton writes: > > > > In what way is SSL 3 not open? > > AFAIK, the feature set was determined almost solely by Netscape. Let me correct that assumption. Features are in SSL 3 that Netscape has no plans to use. They are there because those that involved themselves in the early design asked for them. (For instance, the anonymous Diffie-Helman key exchange is in there to support protocols where MITM attacks are not an issue.) Public responses to the initial sketches for SSL 3 were coming in as early as August, 1995. Microsoft has had copies of the spec since at least November, 1995. There was been no feedback from Microsoft (asking questions or making suggestions) until a completely rewritten spec showed up the month after final SSL 3.0 spec went out. > Certainly, we > need to decide how much attention we, as an IETF working group rather > than as workers for some particular company or as academics, should be > pay to the (cost of the) effort already spent. If we pay too much > attention to it, then we might as well disband the working group and > just adopt SSLv2. (Or 3. Or PCTv1 or 2. Pick your own poison.) I disagree. The output of this working group will not be a protocol that gets picked once in 1996 and never changes. Even before the March draft was finished, consideration was being given as to what was needed for 3.1. (Support for attribute certificates was high on that list.) It would be good if this group was driving that process. What I am arguing for is to take SSL 3.0 as a base and to grow it with the features that are needed. Dropping a 35 page counter-proposal onto the table containing changes ranging from UDP support to password authentication means that efforts will not be focused on the respective ideas. > Please be careful about your terminology. A "covert channel" has a > very specific meaning to people working in security, and I don't think > that meaning is what you intended. I apologize for using the wrong word at 1:00 am. PK -- Philip L. Karlton karlton@netscape.com Principal Curmudgeon http://home.netscape.com/people/karlton Netscape Communications They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin From ericm@lne.com Thu May 9 22:21:16 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id WAA01348 for ; Thu, 9 May 1996 22:21:15 -0400 Received: from slack.lne.com by www10.w3.org (5.0/NSCS-1.0S) id AA10944; Thu, 9 May 1996 22:21:00 +0500 Received: (from ericm@localhost) by slack.lne.com (8.7.1/1.0) id TAA04936; Thu, 9 May 1996 19:02:11 -0700 From: Eric Murray Message-Id: <199605100202.TAA04936@slack.lne.com> Subject: Re: which to implement? To: bfox@microsoft.com (Barb Fox) Date: Thu, 9 May 1996 19:02:10 -0700 (PDT) Cc: bsy@cs.ucsd.edu, karlton@netscape.com, tomste@microsoft.com, rodney@sabletech.com, pcttalk@ftp.com, ietf-tls@w3.org In-Reply-To: from "Barb Fox" at May 9, 96 05:22:20 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit content-length: 2263 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Barb Fox writes: > > Phil: > > Well, at least this list is getting lively! Let me try to address the > points you made in both your recent posts. > > First: I know for a fact that Netscape solicited comments on SSLv3 > pre-publication, as an Internet Draft, and moderated SSL-talk. Actually, it's an open, not moderated, list. > There > were plenty of comments and many of these along with some of the work > we did with PCT are reflected in SSLv3. ( I point specifically to > separation of MAC and encryption key lengths and a shorter, more > efficient handshake message flow which showed up in SSL after PCT was > published.) But my real point is that what went in and what didn't was > primarily a Netscape decision. For what it's worth, they were pretty open about accepting suggestions. As one of the first (only?) people to attempt to implement the original flawed SSLv3, I was able to make a number of suggestions. The SSL people at Netscape took the good ones, and even managed to accept the anonymous Diffie-Hellman that we asked them to include. In addition, pointers to the spec was posted on the cypherpunks list and comments were solicited from the list. While the SSLv3 spec development wasn't as open as say an IETF standard, for a proprietary standard there was a huge amount of outside input. Because of this, and the large amount of outside review that SSLv3 has had, I would like to see it used as a base for the TLS standard. I think that people from Microsoft, and many others, have made some good suggestions for improvements and additions to SSLv3. I think it would be useful to list all those suggestions in one place. I will go back through the ietf-tls list mail I have, and the other specs, and attempt to create such a list. In addition, at the original BOF there were _three_ proposals for a base for TLS- SSL, PCT, and SSH. I haven't heard anything about SSH on this list, and sadly I haven't had the time to research it. Could someone who's familiar with it post it's features and what features it has that might be improvements on SSLv3? -- 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 Fri May 10 01:45:38 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id BAA02931 for ; Fri, 10 May 1996 01:45:37 -0400 Received: from odin.ucsd.edu by www10.w3.org (5.0/NSCS-1.0S) id AA18116; Fri, 10 May 1996 01:45:34 +0500 Received: from work.ucsd.edu by odin.ucsd.edu; id AA21302 sendmail 8.73/UCSDPSEUDO.4-CS via SMTP Thu, 9 May 96 22:45:33 -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 WAA29211; Thu, 9 May 1996 22:45:31 -0700 (PDT) Message-Id: <199605100545.WAA29211@work.ucsd.edu> To: Phil Karlton Cc: Tom Stephens , "'Rodney Thayer'" , "'pcttalk@ftp.com'" , "'ietf-tls@w3.org'" Reply-To: Bennet Yee Subject: Openness, change control, future protocol revisions In-Reply-To: Your message of "Thu, 09 May 1996 14:37:13 -0700." <31926588.59E2@netscape.com> Date: Thu, 09 May 1996 22:45:29 -0700 From: Bennet Yee content-length: 4193 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls In message <31926588.59E2@netscape.com>, Phil Karlton writes: > > Certainly, we > > need to decide how much attention we, as an IETF working group rather > > than as workers for some particular company or as academics, should be > > pay to the (cost of the) effort already spent. If we pay too much > > attention to it, then we might as well disband the working group and > > just adopt SSLv2. (Or 3. Or PCTv1 or 2. Pick your own poison.) > > I disagree. The output of this working group will not be a protocol that > gets picked once in 1996 and never changes. Even before the March draft > was finished, consideration was being given as to what was needed for > 3.1. (Support for attribute certificates was high on that list.) It > would be good if this group was driving that process. > > What I am arguing for is to take SSL 3.0 as a base and to grow it with > the features that are needed. Dropping a 35 page counter-proposal onto > the table containing changes ranging from UDP support to password > authentication means that efforts will not be focused on the respective > ideas. Hi Phil, Thank you for correcting my error regarding SSLv3's development process. As I had said in response to Taher, I must have missed the initial call-for-participation messages. (I don't subscribe to cipherpunks and had heretofore avoided mailing lists. Still don't like 'em much. :) Anyway, SSLv3 may very well be a reasonable base. Perhaps the STLP modifications were too extensive or too one-sided (i.e., due to Microsoft's desires), but since STLP was actually based on the SSLv3 draft, it seems to me that we *are* growing SSLv3 -- the argument is really over whether the STLP changes to SSLv3 are needed. And we had a healthy argument/discussion going for a while. I am less sanguine than you about the impact of future changes in the protocol. When this WG publishes the TLS protocol, products will be created based on it, and that is likely to become a large installed base. How many SSLv2 clients are out there still (older Mozillas or others), even when your company kindly gives away Mozilla for free (at least to us academics)? And consider the installed base of servers, which may or may not be free. There is a significant cost to upgrade, though maybe it's good for business :). This is just for the Web -- TLS is supposed to be broadly applicable to transport level applications, so presumably we'll also see TLS-based telnet, nntp, smtp, etc, etc, broadening the installed base. The issue of protocol revision is still important nonetheless, even if we assume there is zero cost to the user to upgrade. While we are not dealing with APIs in this WG directly, recalling the SSLref&SSLv2->SSLv3 transition, it behooves us to *at least* write down what sort of revisions are being considered for the next rev (as much as is feasible) so that the APIs may be designed to accommodate these changes. Myself, I'd prefer to see this WG (or a subsequent one) specify some minimal core API (for Unix, Windows, and MacOS), so that we wouldn't run into these problems in the future, or at least run into them once for everybody rather than multiply in various different ways for various vendors / freeware implementations. If we don't do this and we do a protocol revision, we'll have to tread on ice to avoid breaking the various flavors of APIs lest one vendor decries foul because a change impacts -their- API more than their competitors. And we'll see more politics. After all, as I see the issue of change control, a lot of the politics is about the impact of revisions on time-to-market. (Certainly true of HTML tags.) It's unfortunate that as scientists / engineers that we have to deal with these business issues, but we should face reality squarely and deal with it as best we can. And I think that by thinking ahead about the need for added features, revisions, and considering API design issues, we would best serve the industry by avoiding future politics. -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 ChristopherA@consensus.com Fri May 10 01:58:27 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id BAA10868 for ; Fri, 10 May 1996 01:58:26 -0400 Received: from consensus.com (mail.consensus.com) by www10.w3.org (5.0/NSCS-1.0S) id AA18573; Fri, 10 May 1996 01:58:23 +0500 Received: from [157.22.240.191] by consensus.com with ESMTP (Apple Internet Mail Server 1.1); Thu, 9 May 1996 21:58:15 -0800 Message-Id: In-Reply-To: <199605100545.WAA29211@work.ucsd.edu> References: Your message of "Thu, 09 May 1996 14:37:13 -0700." <31926588.59E2@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Organization: Consensus Development Corporation Date: Thu, 9 May 1996 23:05:04 -0700 To: ietf-tls@w3.org From: Christopher Allen Subject: Re: Openness, change control, future protocol revisions content-length: 965 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls At 10:45 PM -0700 5/9/96, Bennet Yee wrote: >Myself, I'd prefer to see this WG (or a subsequent >one) specify some minimal core API (for Unix, Windows, and MacOS), so >that we wouldn't run into these problems in the future, or at least >run into them once for everybody rather than multiply in various >different ways for various vendors / freeware implementations. I'm uncomfortable with this. Hasn't IETF's experience with defining API's (as opposed to protocols) been poor? Someone else want to comment on their specific experience of trying to define APIs through an IETF standards process? ------------------------------------------------------------------------ ..Christopher Allen Consensus Development Corporation.. .. 1563 Solano Avenue #355.. .. Berkeley, CA 94707-2116.. .. o510/559-1500 f510/559-1505.. From tomw@netscape.com Fri May 10 04:06:06 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id EAA24414 for ; Fri, 10 May 1996 04:06:05 -0400 Received: from urchin.netscape.com (h-198-95-250-59.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA22878; Fri, 10 May 1996 04:06:04 +0500 Received: from ammodump (ammodump.mcom.com [205.217.232.97]) by urchin.netscape.com (8.6.12/8.6.9) with SMTP id BAA12918; Fri, 10 May 1996 01:06:57 -0700 Sender: tomw@netscape.com Message-Id: <3192F8E2.31DF@netscape.com> Date: Fri, 10 May 1996 01:05:54 -0700 From: Tom Weinstein Organization: Netscape Communications, Inc. X-Mailer: Mozilla 3.0b4 (X11; U; IRIX 5.3 IP22) Mime-Version: 1.0 To: Christopher Allen Cc: ietf-tls@w3.org Subject: Re: Openness, change control, future protocol revisions References: Your message of "Thu, 09 May 1996 14:37:13 -0700." <31926588.59E2@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 1012 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Christopher Allen wrote: > > At 10:45 PM -0700 5/9/96, Bennet Yee wrote: > >Myself, I'd prefer to see this WG (or a subsequent > >one) specify some minimal core API (for Unix, Windows, and MacOS), so > >that we wouldn't run into these problems in the future, or at least > >run into them once for everybody rather than multiply in various > >different ways for various vendors / freeware implementations. > > I'm uncomfortable with this. Hasn't IETF's experience with defining API's > (as opposed to protocols) been poor? Someone else want to comment on > their specific experience of trying to define APIs through an IETF > standards process? I agree. I'd prefer the WG to concentrate on the protocol with, perhaphs, an information RFC afterwards about a possible API. I don't want protocol design hampered by trying to adhere to some predefined API. -- One tag to rule them all, One tag to find them; One tag | Tom Weinstein to bring them all, and in the source tree bind them. | tomw@netscape.com From rodney@sabletech.com Fri May 10 09:22:27 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id JAA03150 for ; Fri, 10 May 1996 09:22:27 -0400 Received: from park.interport.net by www10.w3.org (5.0/NSCS-1.0S) id AA02434; Fri, 10 May 1996 09:22:26 +0500 Received: from ferguson ([199.249.254.9]) by park.interport.net (8.7.3/8.7.3) with SMTP id JAA29569 for ; Fri, 10 May 1996 09:22:21 -0400 (EDT) Message-Id: <199605101322.JAA29569@park.interport.net> 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: Fri, 10 May 1996 09:22:03 -0400 To: ietf-tls@w3.org From: Rodney Thayer Subject: on the subject of meetings content-length: 1335 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls I realize I'm three whole days behind in my mail, which means I seem to have about 85000 messages from this list I haven't read yet. HOWEVER, in case it hasn't been said before, I believe the concept of a meeting not at an ietf meeting is ok. I say this because, before each IETF, the people at headquarters send out reminder messages for people to publish minutes of any intermediate meetings. I also recall other WG's where there were intermediate meetings. If it were a SECRET meeting, or if there were no minutes published afterwards, or if the WG chair objected to the meeting, then I'd say it would be a bad idea. Therefore, since Win isn't objecting, as far as I can tell, and since this list is being used to propose a meeting, I think we are following accepted IETF practice on this. If someone REALLY wants to get worried you should go ask the AD. No, I can't make it -- wrong coast. That's not a complaint, that's just an artifact of my schedule. 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 <@heap.ben.algroup.co.uk:ben@gonzo.ben.algroup.co.uk> Fri May 10 10:17:09 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id KAA27823 for ; Fri, 10 May 1996 10:16:52 -0400 Received: from arachnet.algroup.co.uk by www10.w3.org (5.0/NSCS-1.0S) id AA03944; Fri, 10 May 1996 10:16:02 +0500 Received: from heap.ben.algroup.co.uk by arachnet.algroup.co.uk id aa01215; 10 May 96 15:13 BST Received: from gonzo.ben.algroup.co.uk by heap.ben.algroup.co.uk id aa19796; 10 May 96 14:39 BST Subject: Re: [Fwd: HMAC-MD5: to be or not to be?] To: Taher Elgamal Date: Fri, 10 May 1996 14:34:54 +0100 (BST) From: Ben Laurie Cc: ietf-tls@w3.org In-Reply-To: <3191181E.7F22@netscape.com> from "Taher Elgamal" at May 8, 96 02:54:38 pm Reply-To: ben@algroup.co.uk X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5124 Message-Id: <9605101434.aa28414@gonzo.ben.algroup.co.uk> X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Taher Elgamal wrote: > > This is forwarded to this group. We should keep the secrets in the inner > hash in the MAC in SSSl/STLP/ the name of the day protocol. > > Taher I would just like to be sure I'm understanding this correctly. Does this mean, for example, that an MD5 digest as used in PGP to generate a key fingerprint is no longer secure? Cheers, Ben. > > > HUGO@watson.ibm.com wrote: > > > > As it has been already announced in this list, MD5 is broken for collisions > > (Hans Dobbertin has extended his own techniques used against MD4 to attack > > MD5 as well). > > MD5 needs to be dropped (hope everyone already did) from any use that > > requires resistance to collisions by plain MD5. > > > > One application that is NOT broken with Dobbertin's attack is HMAC with MD5. > > Collisions in plain MD5 do not compromise HMAC-MD5 as the latter uses > > secret IVs and hides the result of the inner iterated function. > > The question is whether the new attack has a significant potential > > of being developed further to break also HMAC-MD5. > > Beyond our own assessment we have got the opinion of a few first line > > cryptographers that they see no way to make these techniques work against > > the use of MD5 in HMAC. > > > > With permission of Hans Dobbertin I reproduce this note he sent to me > > over the weekend in response to my question of whether he sees any > > application of his results to break HMAC-MD5: > > > > Date: Sat, 4 May 1996 22:48:09 +0200 (MET DST) > > From: Hans Dobbertin <> > > To: "H.Krawczyk" > > > > Hi Hugo, > > > > I looked in your paper which you have sent me in January. To answer your > > question I can assure you that I cannot image any way to attack MD5 as it > > is used in HMAC. To be more precise, from the recent attack on MD5 > > (compress) one cannot derive any reservation against the use of MD5 in > > this context. (Perhaps one could argue that the randomness of MD5 is not > > sufficiently investigated ..., but that is another question, and I > > personally do not see a problem here.) > > > > Best regards, Hans > > > > This does not mean in any way that HMAC-MD5 is going to be secure forever. > > It is only to stress that the new attack is not necessarily a reason to drop > > MD5 from its current use in IPSEC. > > > > I believe that we can keep using it until new developments will bring > > HMAC-MD5 closer to a break. Remember this "principle" from > > draft-ietf-ipsec-hmac-md5-txt.00: > > > > Message authentication, as opposed to encryption, has a "transient" > > effect. A published breaking of a message authentication scheme > > would lead to the replacement of that scheme, but would > > have no adversarial effect on information authenticated in the past. > > This is in sharp contrast with encryption, where information encrypted > > today may suffer from exposure in the future if, and when, the > > encryption algorithm is broken. > > > > Following this principle I believe we can keep enjoying the better speed of > > MD5 at least for some time (weeks? months? years? who knows?) > > > > Just to stress this: there is NO known security advantage in keeping > > MD5 relative to going to SHA-1. The only issue here is performance. > > It is there where the trade-off seems to favor MD5 right now. > > > > Having said all of this here is a short note on the theory behind HMAC-MD5. > > In our paper we have chosen to make much stronger assumptions than needed > > on the underlying hash function. This is motivated by the search of easy > > to state and well-defined assumptions together with a simple and correct > > analysis. One of these assumptions on the hash function which we call > > "weakly collision resistance" requires resistance to collisions when the > > IV is secret. In a strict sense such collisions can be found for MD5 > > using Dobbertin's techniques. However, this is possible through > > extension attacks that are prevented in HMAC by the outer application > > of MD5. Therefore, the actual function HMAC-MD5 remains secure. > > > > In our coming Crypto'96 paper we will elaborate more on the analytical > > issues and strength of assumptions. In particular, we may suggest an > > additional (more conservative) variant of HMAC in which one appends a > > key to the data before hashing (in the inner transformation). However, > > this has to be seen as "yet another fence" and not something for which > > there is clear indication that we need to adopt immediately. > > > > Bottom line: I suggest keeping HMAC-MD5 as defined now. (And being always > > very attentive to updates from the cryptanalytic front.) > > > > Hugo > > -- > Taher Elgamal elgamal@netscape.com > Chief Scientist, Netscape Communications > (T) 415 937 2898, (F) 415 428 4054 > -- Ben Laurie Phone: +44 (181) 994 6435 Freelance Consultant and Fax: +44 (181) 994 6472 Technical Director Email: ben@algroup.co.uk A.L. Digital Ltd, URL: http://www.algroup.co.uk London, England. From dennisg@plaintalk.bellevue.wa.us Fri May 10 10:47:24 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id KAA09838 for ; Fri, 10 May 1996 10:47:22 -0400 Received: from btw.cybersafe.com (btw.plaintalk.bellevue.wa.us) by www10.w3.org (5.0/NSCS-1.0S) id AA04788; Fri, 10 May 1996 10:47:12 +0500 Received: from imo.plaintalk.bellevue.wa.us (imo.plaintalk.bellevue.wa.us [192.168.1.7]) by btw.cybersafe.com (8.7.5/8.7.3/dpg hack 25jan96) with ESMTP id HAA03691; Fri, 10 May 1996 07:47:10 -0700 (PDT) Received: (from dennisg@localhost) by imo.plaintalk.bellevue.wa.us (8.7.5/8.7.3/dpg hack 5may96) id HAA02048; Fri, 10 May 1996 07:47:08 -0700 (PDT) Message-Id: <199605101447.HAA02048@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Dennis Glatting Date: Fri, 10 May 96 07:47:05 -0700 To: Christopher Allen Subject: Re: Openness, change control, future protocol revisions Cc: ietf-tls@w3.org Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: Your message of "Thu, 09 May 1996 14:37:13 -0700." <31926588.59E2@netscape.com> content-length: 1842 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Date: Thu, 9 May 1996 23:05:04 -0700 From: Christopher Allen > At 10:45 PM -0700 5/9/96, Bennet Yee wrote: > >Myself, I'd prefer to see this WG (or a subsequent > >one) specify some minimal core API (for Unix, Windows, and MacOS), so > >that we wouldn't run into these problems in the future, or at least > >run into them once for everybody rather than multiply in various > >different ways for various vendors / freeware implementations. > > I'm uncomfortable with this. Hasn't IETF's experience > with defining API's (as opposed to protocols) been poor? > Someone else want to comment on their specific > experience of trying to define APIs through an IETF > standards process? > I'll bite. :) The CAT WG developed and maintains the Generic Security Service API (GSS-API). I have written more than one implementation of the GSS-API and I participate in the CAT WG. (Oh, BTW, I don't speak for my employer. :)) The GSS-API can be considered a success, a failure, or mediocre, depending on your point of view. A GOOD POINT By far the GSS-API's (IMO) best point is that it is a standard. As a standard, it is a valuable check mark on a MIS manager's budget approval list. A BAD POINT Once a standard, customers hold you to the standard, even when it is broken. A MEDIOCRE POINT The applicability of the GSS-API is limited. In simple client/server applications the GSS-API is useful because it is a simple API (20 functions); however, in complex client/server environments it is not useful because it is a simple API -- it doesn't account for multi-threading. Certainly we can argue forever in the day the points of an IETF sponsored API. We can do the same for a protocol too. I'm not convinced there is a difference between an API standard and a protocol standard. The market is looking for both. -dpg From elgamal@netscape.com Fri May 10 12:02:16 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id MAA20761 for ; Fri, 10 May 1996 12:02:15 -0400 Received: from urchin.netscape.com (h-198-95-250-59.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA07369; Fri, 10 May 1996 12:02:14 +0500 Received: from kingtut.mcom.com (h205-217-251-215.mcom.com [205.217.251.215]) by urchin.netscape.com (8.6.12/8.6.9) with SMTP id JAA20167; Fri, 10 May 1996 09:01:45 -0700 Message-Id: <3193692C.70D9@netscape.com> Date: Fri, 10 May 1996 09:05:00 -0700 From: Taher Elgamal X-Mailer: Mozilla 2.01Gold (Win95; I) Mime-Version: 1.0 To: Barb Fox Cc: "'Bennet Yee'" , "'Phil Karlton'" , Tom Stephens , "'Rodney Thayer'" , "'pcttalk@ftp.com'" , "'ietf-tls@w3.org'" Subject: Re: which to implement? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 6720 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Barbara; Of course we did put in the comments that interested people seemed to agree on. However, when you receive conflicting comments from different groups of people, it is really hard to go one way or the other and somehow a decision needs to be made. I hope that through our discussions in the next meeting and in the IETF that we can resolve those differences that are actually hard to accomodate together in a single spec. It is and was always our objective to generate the best solutions that meet the fucntionality, security and efficiency (perhaps in that order) for the community and we actually did take the initiative to go to the IETF to get to the point where we have an industry standard. However, as you know the better standards are the ones that have actually been implemented and used. I am expecting that the IETF will actually produce a different protocol from the current SSLv3, and always committed to supporting the effort, however, we actually have quite a bit of experience in implementing SSL both ourselves and by helping others resolve spec ambiguities and we hope that the IETF group will take that into consideration. I actually wished that you had forwarded the PCT objectives and comments to us before coming out with PCT -- perhaps you would have been surprised with our reaction. The one thing I still do not like is separation of algorithms in defining cipherspec. I hope we can come to some agreement. Cheers, Taher Barb Fox wrote: > > Phil: > > Well, at least this list is getting lively! Let me try to address the > points you made in both your recent posts. > > First: I know for a fact that Netscape solicited comments on SSLv3 > pre-publication, as an Internet Draft, and moderated SSL-talk. There > were plenty of comments and many of these along with some of the work > we did with PCT are reflected in SSLv3. ( I point specifically to > separation of MAC and encryption key lengths and a shorter, more > efficient handshake message flow which showed up in SSL after PCT was > published.) But my real point is that what went in and what didn't was > primarily a Netscape decision. As Taher said earlier, you chose from > the comments you received. Understandable - SSL is your protocol and > you've got code to write, after all. > > But now we're at a different stage in the standards-setting process. > We're talking about an Internet Standard, and comments/contributions > should come from the whole Internet community. Frankly, only a small > subset really cares, but from what we've seen so far, there are more > than a few who want to show up in person to work on what will become > TLS. We all seem to agree that SSLv3 is a good starting point, but > the robust discussions on the TLS list point out the need for some > modifications/improvements before we call it TLSv1. > > This kind of collaboration has got to be the best way to get a > widely-endorsed (and implemented!) standard quickly. That's the whole > reason we're coming and why we're not building a bunker around PCT and > just defending it. Why should we all go to the trouble of submitting > anything to the IETF on the standards track if it isn't better than > what's already out there - and more important, we all get to choose > what gets in it? Interoperability and open change control says it > all. > > You're also right that we cannot expect a one or two day meeting to > resolve all of the complex issues raised on the TLS list. But what we > can do in this meeting - and in subsequent discussions on this list - > is to get more people thinking and commenting. The working group should > take full ownership of the protocol, and this is a great time to start. > > The meeting is at the Garden Court in Palo Alto on May 29th. I hope > you and Taher can be there. > > Barbara Fox > Microsoft > > ---------- > From: Phil Karlton[SMTP:karlton@netscape.com] > Sent: Thursday, May 09, 1996 2:37 PM > To: Bennet Yee > Cc: Tom Stephens; 'Rodney Thayer'; 'pcttalk@ftp.com'; > 'ietf-tls@w3.org' > Subject: Re: which to implement? > > Bennet Yee wrote: > > > > In message <3191A44E.167E@netscape.com>, Phil Karlton writes: > > > > > > In what way is SSL 3 not open? > > > > AFAIK, the feature set was determined almost solely by Netscape. > > Let me correct that assumption. Features are in SSL 3 that Netscape has > no plans to use. They are there because those that involved themselves > in the early design asked for them. (For instance, the anonymous > Diffie-Helman key exchange is in there to support protocols where MITM > attacks are not an issue.) > > Public responses to the initial sketches for SSL 3 were coming in as > early as August, 1995. > > Microsoft has had copies of the spec since at least November, 1995. > There was been no feedback from Microsoft (asking questions or making > suggestions) until a completely rewritten spec showed up the month > after > final SSL 3.0 spec went out. > > > Certainly, we > > need to decide how much attention we, as an IETF working group rather > > than as workers for some particular company or as academics, should > be > > pay to the (cost of the) effort already spent. If we pay too much > > attention to it, then we might as well disband the working group and > > just adopt SSLv2. (Or 3. Or PCTv1 or 2. Pick your own poison.) > > I disagree. The output of this working group will not be a protocol > that > gets picked once in 1996 and never changes. Even before the March draft > was finished, consideration was being given as to what was needed for > 3.1. (Support for attribute certificates was high on that list.) It > would be good if this group was driving that process. > > What I am arguing for is to take SSL 3.0 as a base and to grow it with > the features that are needed. Dropping a 35 page counter-proposal onto > the table containing changes ranging from UDP support to password > authentication means that efforts will not be focused on the respective > ideas. > > > Please be careful about your terminology. A "covert channel" has a > > very specific meaning to people working in security, and I don't > think > > that meaning is what you intended. > > I apologize for using the wrong word at 1:00 am. > > PK > -- > Philip L. Karlton karlton@netscape.com > Principal Curmudgeon http://home.netscape.com/people/karlton > Netscape Communications > > They that can give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety. > - Benjamin Franklin -- Taher Elgamal elgamal@netscape.com Chief Scientist, Netscape Communications (T) 415 937 2898, (F) 415 428 4054 From tomste@microsoft.com Fri May 10 14:35:46 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id OAA29547 for ; Fri, 10 May 1996 14:35:46 -0400 Received: from tide19.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA11831; Fri, 10 May 1996 14:35:41 +0500 Received: by tide19.microsoft.com with Microsoft Exchange (IMC 4.0.838.14) id <01BB3E58.C21D87E0@tide19.microsoft.com>; Fri, 10 May 1996 10:09:21 -0700 Message-Id: From: Tom Stephens To: "'ietf-tls@w3.org'" Subject: May 29th Meeting Date: Fri, 10 May 1996 10:09:06 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.14 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit content-length: 381 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls As Barb indicated in her posting, the meeting to discuss the TLS protocol is set for Wednesday, May 29th at the Garden Court Hotel in Palo Alto, California. In order to ensure we have a large enough meeting room, please send me an RSVP by 5/24. Feel free to contact me if you have any questions regarding accommodations, transportation, etc. Tom Stephens tomste@microsoft.com From ericm@lne.com Sat May 11 07:39:36 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id HAA18299 for ; Sat, 11 May 1996 07:39:35 -0400 Received: from slack.lne.com by www10.w3.org (5.0/NSCS-1.0S) id AA18303; Sat, 11 May 1996 07:39:33 +0500 Received: (from ericm@localhost) by slack.lne.com (8.7.1/1.0) id IAA08582; Fri, 10 May 1996 08:49:15 -0700 From: Eric Murray Message-Id: <199605101549.IAA08582@slack.lne.com> Subject: Re: Openness, change control, future protocol revisions To: dennis.glatting@plaintalk.bellevue.wa.us Date: Fri, 10 May 1996 08:49:14 -0700 (PDT) Cc: ChristopherA@consensus.com, ietf-tls@w3.org In-Reply-To: <199605101447.HAA02048@imo.plaintalk.bellevue.wa.us> from "Dennis Glatting" at May 10, 96 07:47:05 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit content-length: 1426 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Dennis Glatting writes: [should an API be in the TLS standard?] > > The CAT WG developed and maintains the Generic Security > Service API (GSS-API). I have written more than one > implementation of the GSS-API and I participate in the > CAT WG. (Oh, BTW, I don't speak for my employer. :)) The > GSS-API can be considered a success, a failure, or > mediocre, depending on your point of view. [..] > Certainly we can argue forever in the day the points of an > IETF sponsored API. We can do the same for a protocol too. > I'm not convinced there is a difference between an API > standard and a protocol standard. The market is looking > for both. While I think that an API standard might be useful, I'd like to see it done as another RFC, or some sort of supplimentary RFC to the eventual TLS one. I think that the TLS standard should be as simple as possible given reasonable flexibilty and the inherent complexity of cryptographic protocols. Simple standards are the ones that get implemented; complex ones get printed out and thrown in the back corners of people's offices, never again to see the light of day. Complex standards also take longer to become standards, and I'd hate for the TLS process to take so long that it winds up becoming irrelevant. -- 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 ChristopherA@consensus.com Tue May 14 14:32:26 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id OAA16288 for ; Tue, 14 May 1996 14:32:25 -0400 Received: from consensus.com (mail.consensus.com) by www10.w3.org (5.0/NSCS-1.0S) id AA11951; Tue, 14 May 1996 14:32:20 +0500 Received: from [157.22.240.192] by consensus.com with ESMTP (Apple Internet Mail Server 1.1); Tue, 14 May 1996 10:31:57 -0800 X-Sender: ChristopherA@consensus.com (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Organization: Consensus Development Corporation Date: Tue, 14 May 1996 11:29:13 -0700 To: ietf-tls@w3.org From: Christopher Allen Subject: Drafting TLS Specification Cc: Tim Dierks , Jim CastroLang , Jonathan Zamick , Jim CastroLang content-length: 1543 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls We at Consensus Development been following the various discussions on the TLS Working Group list with interest, and it is clear that someone will need to sit down and create a draft RFC describing whatever this working group decides upon. I am volunteering Consensus Development for this task; I will assign technical and writing resources towards producing that document based on the efforts of this group. I will say that we are a little prejudiced on the side of taking SSL 3 as a base and adding those features that Microsoft and others think that they need. Our lead engineer, Tim Dierks, has independently looked over the Microsoft strawman and has some real concerns about it's approach. However, we'll draft whatever the group consensus arrives at. Consensus Development is qualified to do this work by the fact that we are a fairly independent third party with the necessary experience in documentation and cryptographic protocols to produce a quality product (see our web pages for more info.) We have recently been implementing SSL 3, and have found a number of ambiguities and poorly clarified items that we'd like to prevent in any TLS protocol specification. ------------------------------------------------------------------------ ..Christopher Allen Consensus Development Corporation.. .. 1563 Solano Avenue #355.. .. Berkeley, CA 94707-2116.. .. o510/559-1500 f510/559-1505.. From watt@sware.com Mon May 20 11:46:09 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id LAA10158 for ; Mon, 20 May 1996 11:46:05 -0400 Received: from bastion.sware.com by www10.w3.org (5.0/NSCS-1.0S) id AA25575; Mon, 20 May 1996 11:46:03 +0500 Received: from shlep.sware.com (shlep.sware.com [139.131.1.14]) by bastion.sware.com (8.6.12/8.6.5) with SMTP id LAA04899 for ; Mon, 20 May 1996 11:45:45 -0401 Received: by shlep.sware.com (5.65/2.0) from mordred.sware.com id AA07560; Mon, 20 May 96 11:43:48 -0400 Received: by mordred.sware.com (5.65/2.1) id AA01595; Mon, 20 May 96 11:46:10 -0400 Sender: Charles Watt Message-Id: <9605201546.AA01595@mordred.sware.com> Subject: Missing requirements To: ietf-tls@w3.org Date: Mon, 20 May 1996 11:46:06 -0400 (EDT) From: Charles Watt X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 4211 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf 1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK aTxjgASxqHhzkx7PkOnL4JrN+Q== MIC-Info: RSA-MD5,RSA, BkrFKtDKMVnLUVZoapN3XfYzFFDupOYQW4tL4iEqptTl3oDCYD1lATrdWNfa6F+R OHpgEo/zCQB9RUH/70wod+Y= Although I've reread the archives, I appear to have missed this group's discussion on the requirements for a standard transport layer security protocol. The group's focus seems to be "let's slam something together ASAP so all of our browsers will interoperate, and maybe what we wind up with will also be useful to other applications". Although I too would like to see security deployed ASAP, I find this approach short sighted. In order to truly support electronic commerce applications, we shall need secure systems, not just secure applications. As an admittedly biased example, SecureWare's Hannah product (see http://www.secureware.com/papers for a white paper and protocol specifications) creates a secure system by providing transport layer security for ALL network communications in a manner that is transparent to the applications -- i.e., existing applications are secured without modification. It then controls access to transport layer networking (who can access which applications, what security services must be enforced, which algorithms and key sizes must be used, etc...) through ties to the system's underlying security policy. Although a security-aware user or application can request specific security services and algorithms, such requests cannot override security policy. In order to provide such pervasive security, Hannah implements transport security services within the protocol stack. This can best be achieved when there is clean separation between the actual transport layer security protocol and its supporting key management and authentication -- the approach taken by SDNS's SP4, OSI's TLSP, and other previous attempts to "standardize" transport layer security. I believe that a simple set of requirements can easily reconcile these different approaches to transport security such that they can be interoperable: - - Specification of two independent protocols: 1) A transport layer security protocol that provides for security- enhancement of network communications above the transport layer using a set of cryptographic keys supplied by some outside mechanism. This should be designed such that it is independent of (2) allowing for the potential replacement of (2) at some future date. 2) A key management and authentication protocol to support (1). This protocol need not be generic for supporting other IETF efforts such as IPSEC. It is hoped that a unified IETF key management protocol will eventually emerge to supercede this protocol. - - Although initial default algorithms should be specified, the design of the protocols should be independent of any specific cryptographic algorithms to permit potential future upgrade. - - The design of the two protocols should permit two possible modes of operation: 1) intermixed over a single communications channel (in-band key management) similar to the current operation of SSL and PCT. 2) over independent communications channels (out-of-band key management) as suggested by existing transport security standards. Hannah's protocols (public domain, available at previously mentioned URL) meet these requirements today. Both SSL and PCT can be easily modified to meet them as well. Charles Watt Chief Scientist SecureWare, Inc. -----END PRIVACY-ENHANCED MESSAGE----- From watt@sware.com Tue May 21 16:01:27 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id QAA05075 for ; Tue, 21 May 1996 16:01:26 -0400 Received: from bastion.sware.com by www10.w3.org (5.0/NSCS-1.0S) id AA05690; Tue, 21 May 1996 16:01:25 +0500 Received: from shlep.sware.com (shlep.sware.com [139.131.1.14]) by bastion.sware.com (8.6.12/8.6.5) with SMTP id QAA14900 for ; Tue, 21 May 1996 16:01:07 -0400 Received: by shlep.sware.com (5.65/2.0) from mordred.sware.com id AA29612; Tue, 21 May 96 15:59:11 -0400 Received: by mordred.sware.com (5.65/2.1) id AA05608; Tue, 21 May 96 16:01:32 -0400 Sender: Charles Watt Message-Id: <9605212001.AA05608@mordred.sware.com> Subject: TLS Meetings To: ietf-tls@w3.org Date: Tue, 21 May 1996 16:01:29 -0400 (EDT) From: Charles Watt X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1052 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf 1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK aTxjgASxqHhzkx7PkOnL4JrN+Q== MIC-Info: RSA-MD5,RSA, BvDJ7EyjotFeLAxQOu5yZvE4eCJs2ivwvGZPkA7bhQP2uv/BZCceXKKrO8mfNbM7 DBShVwf6KdHwNuIehdlCEjQ= Will this working group be meeting in Montreal? The currently posted IETF schedule does not show any time reserved for the group. Charles Watt SecureWare, Inc. -----END PRIVACY-ENHANCED MESSAGE----- From bsy@work.ucsd.edu Tue May 21 22:54:32 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id WAA12627 for ; Tue, 21 May 1996 22:54:31 -0400 Received: from odin.ucsd.edu by www10.w3.org (5.0/NSCS-1.0S) id AA07977; Tue, 21 May 1996 22:54:29 +0500 Received: from work.ucsd.edu by odin.ucsd.edu; id AA09031 sendmail 8.73/UCSDPSEUDO.4-CS via SMTP Tue, 21 May 96 19:54:22 -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 TAA26484; Tue, 21 May 1996 19:54:01 -0700 (PDT) Message-Id: <199605220254.TAA26484@work.ucsd.edu> To: Charles Watt Cc: ietf-tls@w3.org Reply-To: Bennet Yee Subject: Re: Missing requirements In-Reply-To: Your message of "Mon, 20 May 1996 11:46:06 -0400." <9605201546.AA01595@mordred.sware.com> Date: Tue, 21 May 1996 19:53:57 -0700 From: Bennet Yee content-length: 6368 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls In message <9605201546.AA01595@mordred.sware.com>, Charles Watt writes: > > .... The group's focus seems to be "let's slam something together > ASAP so all of our browsers will interoperate, and maybe what we wind up > with will also be useful to other applications". Although I too would > like to see security deployed ASAP, I find this approach short sighted. > In order to truly support electronic commerce applications, we shall > need secure systems, not just secure applications. To build secure systems, we would need to do a lot more work. Do you mean Orange Book B level at least? I doubt that you meant to replace Windows / MacOS / Unix with an alternative OS. In this context, what do you mean by "secure system"? > As an admittedly biased example, SecureWare's Hannah product > (see http://www.secureware.com/papers for a white paper and protocol > specifications) creates a secure system by providing transport > layer security for ALL network communications in a manner that is > transparent to the applications -- i.e., existing applications are > secured without modification. It then controls access to transport > layer networking (who can access which applications, what security > services must be enforced, which algorithms and key sizes must be > used, etc...) through ties to the system's underlying security policy. > Although a security-aware user or application can request specific > security services and algorithms, such requests cannot override > security policy. >From the white paper, it appears that Hannah "creates a secure system" only in the sense that it tries to mediate in all network traffic and provides some node management functionality. It is not multi-level security, obviously, since there's no data labelling and the node management functionality apparently provide basic, low level access control for network connections. I briefly looked at http://www.secureware.com/papers/pakmp/pakmp.ps, and have some questions. It is a 65 page document that dives quickly into the layout of the packets and does not seem to include a high level description of the cryptographic protocols used. On page 13, it states that Family C "provides key management using Diffie-Hellman", and that "authentication is achieved by having each side encrypt a nonce with the public key of the peer and having the peer return the decrypted value." Presumably with RSA, since that paragraph mentions RSA later, and presumably the nonce, both RSA-encrypted and not, are actually sent over a channel encrypted with the key derived in the D-H exchange. Later sections that I found on Family C had only "TBD" (4.4, pg 46). Now, this sort of authentication is subject to a man-in-the-middle attack, unless the D-H keys are somehow certified and the RSA certificates are linked to the D-H certificates. This is a very important requirement that does not seem to be stated anywhere. Now, pg 22 mentions PKCS3, so it does not appear that you're using the pair-wise fixed keys scheme but rather D-H with global p,g to obtain a shared secret the value of which neither side controls. Without something stronger than plain D-H, we can have the following scenario: Alice and Bob wishes to communite. Guy is the man in the middle. G pretends to be B to A (denoted G_B), and at the same time pretends to be A to B (G_A). G performs two independent D-H key exchanges with A and B (as G_B and G_A resp) to obtain two shared secrets k_a = g^{r_a r_{g_b}} mod p and k_b = g^{r_b r_{g_a}} mod p respectively. Now, suppose A wishes G_B to authenticate his identity as B. G_B can not do this directly, since he lacks Bob's RSA private key (d_b). However, when A sends her nonce r_n^{e_b} mod n_b, it is over the channel encrypted with k_a -- the D-H derived key Alice believes that she shares with Bob. Guy can easily obtain r_n^{e_b} mod n_b, of course, since he has k_a. Now G re-encrypts this value with k_b and sends it to B (acting as G_A). B decrypts using secret key cryptosystem key k_b, decrypts using RSA to obtain r_n, and replies with r_n over his secret-key protected channel. Straight to G, who can forward it to A. This is a simple, standard textbook-example MITM attack that I'd expect any of my students to understand and avoid. Perhaps your document is in error and does not actually describe the real cryptographic protocol family C as originally designed. In any case, a clearer document that describes the protocols involved rather than a which-byte-goes-where document (which is more useful to an implementer than a cryptographer) would be nice. I haven't looked at any of the other families A-G (or whatever the highest letter is); C just jumped out at me. > In order to provide such pervasive security, Hannah implements > transport security services within the protocol stack. This can best > be achieved when there is clean separation between the actual transport > layer security protocol and its supporting key management and > authentication -- the approach taken by SDNS's SP4, OSI's TLSP, and > other previous attempts to "standardize" transport layer security. Maybe Microsoft wouldn't care (;-), but Hannah's implementation -- as described in the white paper -- requires in-kernel modifications on Unix hosts (Hannah is only available HPUX and SCO -- for Windows Hannah takes over the Winsock DLL to control the network connections). This is contradictory to one of the (perhaps implicit) goals of being usable on all popular systems. Granted, the Hannah protocols may be implemented as a user-level library just like SSL/PCT/etc, but in that case the advantage of being pervasive (and thus can handle all network connections by mandate) disappears. -bsy p.s.: the Hannah protocol description appears to be missing a requirement to verify that the cert matches the DNS name somehow. For web use, we wouldn't want a certified but malicious web server to be providing Web documents that are purportedly from e.g. SecureWare using DNS spoofing tricks and its own certificate(s), which the users (or users' Web browsers) would not be able to examine in a completely transparent scheme. -------- 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 treese@openmarket.com Tue May 21 23:13:45 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id XAA12685 for ; Tue, 21 May 1996 23:13:45 -0400 Received: from relay.openmarket.com by www10.w3.org (5.0/NSCS-1.0S) id AA08066; Tue, 21 May 1996 23:13:44 +0500 Received: from mail.openmarket.com (mail-199.openmarket.com [199.170.183.6]) by relay.openmarket.com (8.6.10/8.6.6) with ESMTP id XAA26750 for ; Tue, 21 May 1996 23:13:14 -0400 Received: from w4-8.openmarket.com (Ptreese.openmarket.com [205.228.175.99]) by mail.openmarket.com (8.7.4/8.7.3) with SMTP id XAA00921 for ; Tue, 21 May 1996 23:13:12 -0400 (EDT) Message-Id: <2.2.32.19960522031236.00751300@mail-60.OpenMarket.com> X-Sender: treese@mail-60.OpenMarket.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 May 1996 23:12:36 -0400 To: ietf-tls@w3.org From: Win Treese Subject: Working group meeting in Montreal content-length: 164 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls The TLS working group will meet in Montreal on Monday, June 24 at 0930. Please send me a note if you would like to propose any items for the agenda. Win Treese From dpkemp@missi.ncsc.mil Wed May 22 11:09:27 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id LAA23886 for ; Wed, 22 May 1996 11:09:26 -0400 Received: from guardian.guard.ncsc.mil by www10.w3.org (5.0/NSCS-1.0S) id AA11873; Wed, 22 May 1996 11:09:25 +0500 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id LAA12806 for ; Wed, 22 May 1996 11:09:39 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma012804; Wed May 22 11:09: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 LAA01758 for ; Wed, 22 May 1996 11:05:32 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id LAA06555; Wed, 22 May 1996 11:09:06 -0400 Date: Wed, 22 May 1996 11:09:06 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199605221509.LAA06555@argon.ncsc.mil> To: ietf-tls@w3.org Subject: Re: Missing requirements X-Sun-Charset: US-ASCII content-length: 5802 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls > Date: Tue, 21 May 1996 19:53:57 -0700 > From: Bennet Yee > > In message <9605201546.AA01595@mordred.sware.com>, Charles Watt writes: > > > > .... The group's focus seems to be "let's slam something together > > ASAP so all of our browsers will interoperate, and maybe what we wind up > > with will also be useful to other applications". Although I too would > > like to see security deployed ASAP, I find this approach short sighted. > > In order to truly support electronic commerce applications, we shall > > need secure systems, not just secure applications. > > To build secure systems, we would need to do a lot more work. Do you > mean Orange Book B level at least? I doubt that you meant to replace > Windows / MacOS / Unix with an alternative OS. In this context, what > do you mean by "secure system"? I believe the issue is not whether the platform / OS (it's not just an OS question) will be replaced with something "secure", it is whether an IETF-standardized protocol should be designed in such a manner as to facilitate the development of secure systems, as opposed to relying on each separate application to design and incorporate it's own security. > I briefly looked at http://www.secureware.com/papers/pakmp/pakmp.ps, > and have some questions. It is a 65 page document that dives quickly > into the layout of the packets and does not seem to include a high > level description of the cryptographic protocols used. > > On page 13, it states that Family C "provides key management using > Diffie-Hellman", and that "authentication is achieved by having each > side encrypt a nonce with the public key of the peer and having the > peer return the decrypted value." Presumably with RSA, since that > paragraph mentions RSA later, and presumably the nonce, both > RSA-encrypted and not, are actually sent over a channel encrypted with > the key derived in the D-H exchange. Later sections that I found on > Family C had only "TBD" (4.4, pg 46). > > Now, this sort of authentication is subject to a man-in-the-middle > attack, unless the D-H keys are somehow certified and the RSA > certificates are linked to the D-H certificates. This is a very > important requirement that does not seem to be stated anywhere. > Now, pg 22 mentions PKCS3, so it does not appear that you're using > the pair-wise fixed keys scheme but rather D-H with global p,g to > obtain a shared secret the value of which neither side controls. Regardless of whether Hannah's *implementation* of D-H is subject to MITM attacks, D-H can be designed to resist known protocol attacks. See, for example, the draft ANSI X9.42 - 1996 "Establishment of Symmetric Algorithm Keys using Diffie-Hellman", available from the American Bankers Association. But critiqueing the specific protocols used by Hannah is focusing on the trees and ignoring the forest. The big issue is whether the session key establishment (or Security Association management) protocol should be cleanly separated from the traffic protection protocol. Both Hannah and IPSEC provide entirely separate protocols for key management and traffic protection; SSL and PCT provide partial separation by having a "Record Layer" distinct from the "upper layers" (handshake, alert, cipherspec, and application-data). The key point is that the traffic protection code (Hannah's NDSEP, IPSEC's AH and ESP, SSL's record layer) is relatively small and easy to implement, (although it must be carefully designed). It can be built into each application, or be stuffed into the network stack and shared by all applications, whichever you prefer. But the key management protocol (Hannah's PAKMP, IPSEC's ISAKMP) is big, complicated, and requirements are rapidly evolving. It makes sense to fully de-couple the two protocols so that: 1) a single KMP can be shared by all network layers - IP, transport, and application, 2) evolution in key management technology can be accommodated without replacing all the software that has it hardwired in, and 3) each application can be a *lot* smaller. How much of the code in Netscape Navigator or MS Internet Explorer is dedicated to web browsing, vs. the amount dedicated to handshaking and certificate management? The latter is just overhead, and the more flexible it becomes, the more the code bloats. > Maybe Microsoft wouldn't care (;-), but Hannah's implementation -- as > described in the white paper -- requires in-kernel modifications on > Unix hosts (Hannah is only available HPUX and SCO -- for Windows > Hannah takes over the Winsock DLL to control the network connections). > This is contradictory to one of the (perhaps implicit) goals of being > usable on all popular systems. Granted, the Hannah protocols may be > implemented as a user-level library just like SSL/PCT/etc, but in that > case the advantage of being pervasive (and thus can handle all network > connections by mandate) disappears. Modifying the network stack on Unix hosts only requires kernel modifications (and source) if you're using an obsolete Unix. If the kernel uses Streams networking (Solaris, for example) the application can just push another Streams module onto the stack. As mentioned above, it doesn't really matter if the Record Layer code is built in to the application or the stack - it isn't that large. If it isn't in the stack, you can't force all applications to use it, but it's a lot easier to build applications that do. I strongly recommend that the TLS working group define separate protocols for traffic protection and key management. As Mr. Watt pointed out, it's not necessary to wait for IPSEC to standardize ISAKMP/Oakley before getting products to market, we just need to make the TLS handshake protocol (whatever it turns out to be) pluggable. From bsy@work.ucsd.edu Wed May 22 16:00:28 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id QAA28291 for ; Wed, 22 May 1996 16:00:27 -0400 Received: from odin.ucsd.edu by www10.w3.org (5.0/NSCS-1.0S) id AA14006; Wed, 22 May 1996 16:00:26 +0500 Received: from work.ucsd.edu by odin.ucsd.edu; id AA19753 sendmail 8.73/UCSDPSEUDO.4-CS via SMTP Wed, 22 May 96 13:00:22 -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 NAA21496; Wed, 22 May 1996 13:00:15 -0700 (PDT) Message-Id: <199605222000.NAA21496@work.ucsd.edu> To: Charles Watt Cc: ietf-tls@w3.org Reply-To: Bennet Yee Subject: Re: Missing requirements In-Reply-To: Your message of "Wed, 22 May 1996 13:22:35 -0400." <9605221722.AA01417@mordred.sware.com> Date: Wed, 22 May 1996 13:00:05 -0700 From: Bennet Yee content-length: 4973 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls In message <9605221722.AA01417@mordred.sware.com>, Charles Watt writes: > > You missed the entire point of my message, which had nothing to do with > any specifics of our Hannah product. I will reiterate as succinctly > as I can that one point, and then address individual comments below. > > THE POINT: > > Integrating key management, authentication and data security > services into a single, in-band protocol is a BAD idea for a > generic transport layer security protocol. It effectively > eliminates architectures that are capable of providing higher > security and assurance. It also ensures redundant key management > facilities when other services such as IPSEC are deployed. Sorry for missing your point. It was not apparent from the original message. It appears you're trying to say is that you want a more orthogonal design. That's not entirely unreasonable. Certainly a better system results when good protocol design is coupled with good systems engineering. (Also, there's no need to SHOUT.) I have no wish to attack Hannah -- I was in part confused by a protocol specification document that described all these extra protocol families as if they were relevent and intended to be supported (if not yet). If you say that family C is irrelvant, fine. Personally, I don't like documents that try to do too many things at once: discussing bad, discarded alternatives like a high level [pre-]design document or a survey article, as well as talking about state diagrams and wire formats like an implementer's guide. But those are my biases. > [...] The point again is simply: > "Can the protocol support high security, high assurance implementations?" > If not, it is not a suitably generic protocol. The current drafts of SSL > and PCT. Cut-n-pasted from the proposed charter: > 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. And one of my points was that the TLS WG is not the IPSEC WG, nor is is it spec'ing out a fully generic, do everything protocol. Certainly non-repudiation is outside the scope of TLS -- nobody has mentioned signing every message yet AFAIK. Hannah's scope includes this (as an option); TLS's does not. The protocols that you fault with being too integrated / insufficiently generic, e.g., SSL or PCT or STLP, however, do not necessarily dictate system design. They certainly include necessary protocol version numbers etc to provide compatibility, as well as the numbering for crypto primitive negotiation/selection. If the claim is that key exchange/management protocols evolve too quickly and that an upgrade path should exist, then the versioning will already take care of that at the wire-level, and as long as the implementations are relatively clean upgrading should not pose great difficulties. If what you're looking for is to explicitly name the record layer one protocol and the key exchange/management layer another protocol, that's fine. It may help to clarify thinking to separate these even more explicitly. A security protocol, by any other name, resists the same attacks. Regarding the fact that DNS is not secure, we seem to have different opinions based on that same fact. You seem to want everybody to use the Hannah-provided certified namespace and nothing else. I think that's impractical. I argue that because DNS is not secure, something needs to be done in order to link the namespaces together. We have the certified names in one namespace, and DNS names in another. If the Hannah protocols were to be used, the application (e.g., Web browsers) will speak in one namespace (DNS names), but the secured transport that Hannah provides will talk in another (fully certified names). If I give you an URL (which contains a DNS name) and your browser ends up connecting to a fully certified agent, that agent may or may not have the expected correspondence to the DNS name. How the DNS name is "resolved" to the Hannah certified name must be verified. If your applications are Hannah-aware and deal only with certified names, fine. If your application thinks in one namespace that doesn't trivially map into the Hannah-supplied certified namespace, then we've still got a problem. To provide security with application transparency, after the authentication protocol runs -- which authenticates in the certified namespace -- the implementation should try to make sure that the name supplied by the user -- which is a DNS name or a raw IP address -- has something to do with the authenticated peer. -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 watt@sware.com Wed May 22 17:28:15 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id RAA00609 for ; Wed, 22 May 1996 17:28:14 -0400 Received: from bastion.sware.com by www10.w3.org (5.0/NSCS-1.0S) id AA14593; Wed, 22 May 1996 17:28:12 +0500 Received: from shlep.sware.com (shlep.sware.com [139.131.1.14]) by bastion.sware.com (8.6.12/8.6.5) with SMTP id RAA23069; Wed, 22 May 1996 17:27:50 -0401 Received: by shlep.sware.com (5.65/2.0) from mordred.sware.com id AA17928; Wed, 22 May 96 17:25:53 -0400 Received: by mordred.sware.com (5.65/2.1) id AA04598; Wed, 22 May 96 17:26:16 -0400 Sender: Charles Watt Message-Id: <9605222126.AA04598@mordred.sware.com> Subject: Re: Missing requirements To: bsy@cs.ucsd.edu Date: Wed, 22 May 1996 17:26:13 -0400 (EDT) From: Charles Watt Cc: watt@sware.com, ietf-tls@w3.org In-Reply-To: <199605222000.NAA21496@work.ucsd.edu> from "Bennet Yee" at May 22, 96 01:00:05 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 8539 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf 1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK aTxjgASxqHhzkx7PkOnL4JrN+Q== MIC-Info: RSA-MD5,RSA, BRUUhuffkTtFkDUN0jfsjruDA1cRqjm7+K1AzAHeRomsNw+KTxjRh++8uAGoXvvn qd6H5Nfkv9IbRmRvDTlwcvU= > > [...] The point again is simply: > > "Can the protocol support high security, high assurance implementations?" > > If not, it is not a suitably generic protocol. The current drafts of SSL > > and PCT. > > Cut-n-pasted from the proposed charter: > > > 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. > > And one of my points was that the TLS WG is not the IPSEC WG, nor is > is it spec'ing out a fully generic, do everything protocol. Certainly > non-repudiation is outside the scope of TLS -- nobody has mentioned > signing every message yet AFAIK. Hannah's scope includes this (as an > option); TLS's does not. Bennet, I was very specific about what I thought need be done, which was: >> - Specification of two independent protocols: >> >> 1) A transport layer security protocol that provides for security- >> enhancement of network communications above the transport layer >> using a set of cryptographic keys supplied by some outside >> mechanism. This should be designed such that it is independent >> of (2) allowing for the potential replacement of (2) at some >> future date. >> >> 2) A key management and authentication protocol to support (1). >> This protocol need not be generic for supporting other IETF >> efforts such as IPSEC. It is hoped that a unified IETF key >> management protocol will eventually emerge to supercede this >> protocol. >> >> - Although initial default algorithms should be specified, the design of the >> protocols should be independent of any specific cryptographic algorithms >> to permit potential future upgrade. >> >> - The design of the two protocols should permit two possible modes of >> operation: >> >> 1) intermixed over a single communications channel (in-band key >> management) similar to the current operation of SSL and PCT. >> >> 2) over independent communications channels (out-of-band key >> management) as suggested by existing transport security >> standards. This is only common sense and good protocol design. It certainly isn't "spec'ing out a fully generic, do everything protocol" and doesn't mention signing every packet. I've no idea where you came up with that. > The protocols that you fault with being too integrated / > insufficiently generic, e.g., SSL or PCT or STLP, however, do not > necessarily dictate system design. They certainly include necessary > protocol version numbers etc to provide compatibility, as well as the > numbering for crypto primitive negotiation/selection. If the claim is > that key exchange/management protocols evolve too quickly and that an > upgrade path should exist, then the versioning will already take care > of that at the wire-level, and as long as the implementations are > relatively clean upgrading should not pose great difficulties. Of course they dictate system design. There is no way to implement either one except by bundling them together over the same communication channel. They should be designed to support both in-band and out-of-band key negotiation so that they can support datagram-based services and higher assurance implementations. This is not difficult to do, and the current versions of SSL and PCT could be easily modified to meet these requirements much like Hannah (NDSEP/PAKMP), IPSEC (IPSEC/Oakley), SP4 (SP4/KMP) and other similar systems. > > If what you're looking for is to explicitly name the record layer one > protocol and the key exchange/management layer another protocol, > that's fine. It may help to clarify thinking to separate these even > more explicitly. A security protocol, by any other name, resists the > same attacks. > > Regarding the fact that DNS is not secure, we seem to have different > opinions based on that same fact. You seem to want everybody to use > the Hannah-provided certified namespace and nothing else. I think > that's impractical. I have no desire to constrain anyone's name space. I have a strong desire to see an IETF security infrastructure built upon well-conceived, robust mechanisms. Linking the Common Name to the domain name isn't one. > > I argue that because DNS is not secure, something needs to be done in > order to link the namespaces together. We have the certified names in > one namespace, and DNS names in another. If the Hannah protocols were > to be used, the application (e.g., Web browsers) will speak in one > namespace (DNS names), but the secured transport that Hannah provides > will talk in another (fully certified names). If I give you an URL > (which contains a DNS name) and your browser ends up connecting to a > fully certified agent, that agent may or may not have the expected > correspondence to the DNS name. How the DNS name is "resolved" to the > Hannah certified name must be verified. If your applications are > Hannah-aware and deal only with certified names, fine. If your > application thinks in one namespace that doesn't trivially map into > the Hannah-supplied certified namespace, then we've still got a > problem. There are several problems with linking authenticated identity with DNS names: 1) A domain name contains little meaningful information about the entity with which it is associated. They are handed out first come, first serve. If a customer connects to www.llbean.com, are they connected to the famous mail order company or an imposter? 2) Because DNS is insecure, an attacker can, at least within an isolated region, assume any domain name they choose. If they can convince any of the standard CA's supported by Netscape that they are www.netscape.com, or convince the user to accept a new CA, then they are netscape. 3) Do you suggest similar rules for client certificates? If so, it is unreasonable for me to be identified as watt@sware.com if I am also watt@mindspring.com and watt@directpc.com. If not, then the protocol is worthless for many applications such as banking where it is perhaps more important to identify the client than the server. My own opinion on this matter is that resolving authenticated name to DNS name is a non-issue. Who cares what domain name L.L. Bean uses for their server as long as I am sure I am talking to L.L. Bean when I place my order. Establishing this assurance cannot be achieved by linking the certificate name to the domain name. I would prefer to encode additional identification information in the certificate extension fields, which can be verified by the CA during certification and displayed in convenient, human readable format. But what ever scheme is chosen, the crux of the trust issue boils down to whether or not you can trust the other guy's CA to properly identify and register those entities that it certifies. But this is not a protocol issue and this is not the forum for deciding such issues. > > To provide security with application transparency, after the > authentication protocol runs -- which authenticates in the certified > namespace -- the implementation should try to make sure that the name > supplied by the user -- which is a DNS name or a raw IP address -- has > something to do with the authenticated peer. How does this work with mobile IP? Charles Watt SecureWare, Inc. -----END PRIVACY-ENHANCED MESSAGE----- From davismc@vnet.ibm.com Wed May 22 19:14:08 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id TAA01189 for ; Wed, 22 May 1996 19:14:07 -0400 Received: from VNET.IBM.COM by www10.w3.org (5.0/NSCS-1.0S) id AA15101; Wed, 22 May 1996 19:14:06 +0500 Message-Id: <9605222314.AA15101@www10.w3.org> Received: from RALVM12 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7827; Wed, 22 May 96 19:13:47 EDT Date: Wed, 22 May 96 19:09:40 EDT From: "Mark C. Davis ((919)254-7865)" To: tomste@microsoft.com Cc: ietf-tls@w3.org, davismc@vnet.ibm.com Subject: Re: May 29th Meeting content-length: 644 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Tom, Two questions about the meeting on May 29: 1. Do you have particular expectations of the participants? For example, you might expect them to have read the 4/8 Microsoft paper and be familiar with SSL V2, SSL V3, and PC V1 specifications. How about PCT V2? Hannah? A list such as used by recent W3C Security work group meetings might be useful to avoid making it a grand education session. 2. Do you have an agenda? Or a prioritized list of discussion topics? Looking at the notes that preceeded the announcement of this meeting does not help much. (I have some ideas, you may have a different list.) Thanks - Mark From bsy@work.ucsd.edu Wed May 22 20:10:32 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id UAA01490 for ; Wed, 22 May 1996 20:10:31 -0400 Received: from odin.ucsd.edu by www10.w3.org (5.0/NSCS-1.0S) id AA15384; Wed, 22 May 1996 20:10:30 +0500 Received: from work.ucsd.edu by odin.ucsd.edu; id AA02069 sendmail 8.73/UCSDPSEUDO.4-CS via SMTP Wed, 22 May 96 17:10:29 -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 RAA09609; Wed, 22 May 1996 17:10:12 -0700 (PDT) Message-Id: <199605230010.RAA09609@work.ucsd.edu> To: dpkemp@missi.ncsc.mil (David P. Kemp) Cc: ietf-tls@w3.org Reply-To: Bennet Yee Subject: Re: Missing requirements In-Reply-To: Your message of "Wed, 22 May 1996 11:09:06 -0400." <199605221509.LAA06555@argon.ncsc.mil> Date: Wed, 22 May 1996 17:10:10 -0700 From: Bennet Yee content-length: 4366 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls In message <199605221509.LAA06555@argon.ncsc.mil>, David P. Kemp writes: > > I believe the issue is not whether the platform / OS (it's not just > an OS question) will be replaced with something "secure", it is whether > an IETF-standardized protocol should be designed in such a manner as > to facilitate the development of secure systems, as opposed to relying > on each separate application to design and incorporate it's own security. Perhaps I'm being dense, but I don't see how having -any- security protocol standardized by IETF would mean relying on every separate app to design and incorporate its own security. As long as (minimally) version numbers exist to provide an on-wire upgrade path and with reasonable API design, we'd have to at most relink the apps. Unless, of course, the standardized protocol actually fails to provide any security properties whatsoever. The only other senses you might have meant by this that I can think of is if the protocol can not be implemented in a completely application transparent way, resulting in the app having to be modified. Are you arguing for having some mechanism to enforce the mandatory use of the TLS protocol? The use of dynamic libraries or streams modules or DLLs or whatever to separate the protocol processing from the core of the app? > Regardless of whether Hannah's *implementation* of D-H is subject to > MITM attacks, D-H can be designed to resist known protocol attacks. > See, for example, the draft ANSI X9.42 - 1996 "Establishment of > Symmetric Algorithm Keys using Diffie-Hellman", available from the > American Bankers Association. It's well known how to do D-H w/ auth in a protocol: exchange signatures of the protocol messages received after the D-H key has been exchanged, so you know what you think you sent was actually received by the intended recipients (via certs on sig keys). I was not talking about an implementation of D-H but a protocol design which uses D-H in an unsound way. I certainly did not examine any code. Maybe this is more of a terminology problem. Any protocol specification document that describes an unsound protocol shakes my faith in the entire document. So I am extremely glad to hear from Charles that this particular protocol design was actually discarded and that this was actually a writing/communication problem. > [ ... ] > But the key management protocol (Hannah's PAKMP, IPSEC's ISAKMP) is > big, complicated, and requirements are rapidly evolving. It makes > sense to fully de-couple the two protocols so that: > 1) a single KMP can be shared by all network layers - IP, > transport, and application, > 2) evolution in key management technology can be accommodated > without replacing all the software that has it hardwired in, and > 3) each application can be a *lot* smaller. From an architectural point of view, it is nice to fully decouple things. From a design-for-performance point of view, fully decoupling requires careful study of the interface between the two -- it would certainly be impossible to handle pre-encrypted, pre-MACed widely-distributed data with a naive interface. It is possible to having a nice, layered approach that still permits such speedups? I think so. I haven't been arguing against decoupling. I just noticed what appeared to be a flaw in a Hannah protocol, pointed to the protocol document by what appeared to be a statement that Hannah incorporated a design that was exemplary of the sort of separation for which we should strive. > Modifying the network stack on Unix hosts only requires kernel > modifications (and source) if you're using an obsolete Unix. If > the kernel uses Streams networking (Solaris, for example) the > application can just push another Streams module onto the stack. Installing a streams module require root access. Certainly heretofore browser installation had not required such, so "just" pushing another Streams module isn't necessarily something that we can mandate. Furthermore, last I heard Netscape provided a Linux version of Navigator, and while users of these systems are more likely to have root access, Linux/*BSD does not have Streams. -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 tomste@microsoft.com Thu May 23 12:27:21 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id MAA10254 for ; Thu, 23 May 1996 12:27:20 -0400 Received: from tide19.microsoft.com by www10.w3.org (5.0/NSCS-1.0S) id AA19922; Thu, 23 May 1996 12:27:20 +0500 Received: by tide19.microsoft.com with Microsoft Exchange (IMC 4.0.838.14) id <01BB488A.0C44E8F0@tide19.microsoft.com>; Thu, 23 May 1996 09:27:23 -0700 Message-Id: From: Tom Stephens To: "'Mark C. Davis ((919)254-7865)'" Cc: "'ietf-tls@w3.org'" Subject: RE: May 29th Meeting Date: Thu, 23 May 1996 09:27:16 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.14 Encoding: 52 TEXT content-length: 1702 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Mark, I hope to post a list of proposed discussion topics within the next couple of days. This list will be compiled from the topics raised on this list to date. If you or anyone else wishes to suggest topics for discussion which have not yet been posted to the list, then please post your suggestions and I will incorporate them into the document. On the morning of 5/29, the meeting attendees can decide which of the topics should be addressed at the meeting given the limited amount of time we have available to us. Location: Garden Court Hotel 520 Cowper Street Palo Alto, California Telephone: 415-322-9000 Schedule: 0800 - 0830, Continental breakfast 0830 - 1200, Morning session 1200 - 1300, Lunch 1300 - 1500, Early afternoon session 1500 - 1530, Afternoon break 1530 - 1700, Late afternoon session/wrap-up >---------- >From: Mark C. Davis ((919)254-7865)[SMTP:davismc@vnet.ibm.com] >Sent: Wednesday, May 22, 1996 4:09 PM >To: Tom Stephens >Cc: ietf-tls@w3.org; davismc@vnet.ibm.com >Subject: Re: May 29th Meeting > >Tom, >Two questions about the meeting on May 29: >1. Do you have particular expectations of the participants? For >example, > you might expect them to have read the 4/8 Microsoft paper and be > familiar with SSL V2, SSL V3, and PC V1 specifications. How about >PCT > V2? Hannah? A list such as used by recent W3C Security work group > meetings might be useful to avoid making it a grand education >session. >2. Do you have an agenda? Or a prioritized list of discussion topics? > Looking at the notes that preceeded the announcement of this meeting > does not help much. (I have some ideas, you may have a different >list.) > >Thanks - Mark > > From watt@sware.com Thu May 23 16:40:16 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id QAA16607 for ; Thu, 23 May 1996 16:40:15 -0400 Received: from bastion.sware.com by www10.w3.org (5.0/NSCS-1.0S) id AA21927; Thu, 23 May 1996 16:40:13 +0500 Received: from shlep.sware.com (shlep.sware.com [139.131.1.14]) by bastion.sware.com (8.6.12/8.6.5) with SMTP id QAA01589; Thu, 23 May 1996 16:39:52 -0401 Received: by shlep.sware.com (5.65/2.0) from mordred.sware.com id AA04838; Thu, 23 May 96 16:37:55 -0400 Received: by mordred.sware.com (5.65/2.1) id AA07380; Thu, 23 May 96 16:38:18 -0400 Sender: Charles Watt Message-Id: <9605232038.AA07380@mordred.sware.com> Subject: Re: Missing requirements To: bsy@cs.ucsd.edu Date: Thu, 23 May 1996 16:38:14 -0400 (EDT) From: Charles Watt Cc: watt@sware.com, ietf-tls@w3.org In-Reply-To: <199605231911.MAA09120@work.ucsd.edu> from "Bennet Yee" at May 23, 96 12:11:30 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 3583 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf 1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK aTxjgASxqHhzkx7PkOnL4JrN+Q== MIC-Info: RSA-MD5,RSA, B5DRYcHzmtWQyt5M3j9RGos4bWCZFYFaQMdOcnq+3aNQrYfMt+coEoQgQqQ2ISks Npw8lxJmrPu8/xzwooA4syc= > I was speaking of using the channel ciphers from SSL / PCT as is. > Certainly you can just update the IV (and unlink the packets) for > block ciphers. > > Reusing a key for a stream cipher opens you up to a very simple > cryptanalytic attack, *not* differential attacks. A differential > attack relies on gathering statistics from injecting related pairs of > plaintext blocks for a *block* cipher and examining the resultant pair > of ciphertext. It requires the ability to mount a (nonadaptive) > chosen plaintext attack, and the goal is to extract enough information > to determine the key used. See Biham & Shamir's nice book on > differential cryptanalysis. > > What you're referring to is the simple fact that the reuse of a stream > key results in the same cipher output stream being xor'd into multiple > plaintext streams to product ciphertext streams. Thus, the xor of a > pair of those ciphertext streams result in the cancelling of the > cipher output stream and would get you the xor of two plaintext > streams, which would presumably have relatively low entropy and can be > easily analyzed. No need to determine the key. This does not work against a stream cipher that incorporates feedback of the resulting ciphertext into the key stream. Such ciphers are vulnerable if you reuse the key, but require much more sophisticated techniques to break. Arguing whether such techniques classify as differential cryptanalysis is at best nitpicking. > > Unless the networking textbooks have been rewritten recently, UDP is a > > transport layer protocol. There is no extra complexity required of a > > transport layer security protocol to support UDP, provided that you have > > designed the protocol properly in the first place. > > Transport layer protocols as defined in the ISO OSI reference model > provide reliable virtual channels out of the network layer, which > provides unreliable datagrams. UDP in the TCP/IP world is simply IP > datagrams with very little extra proessing. UDP packets may be lost, > reordered, or duplicated, just like the IP packets. > > I guess we must have read different textbooks. To quote ISO 8072, the Transport Service Definition, connectionless mode transmission occurs "without any requirement to maintain any logical relationship among multiple transport-service-data-units". Sounds like UDP to me. To which ISO model were you referring? Regardless, if there is no extra complexity associated with making the protocol appropriate for UDP, what are your objections to doing so? Nitpicking about terminology that isn't even relevant to the topic of discussion is an annoying waste of time. Charles Watt SecureWare, Inc. -----END PRIVACY-ENHANCED MESSAGE----- From dpkemp@missi.ncsc.mil Fri May 24 12:07:20 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id MAA01002 for ; Fri, 24 May 1996 12:07:19 -0400 Received: from guardian.guard.ncsc.mil by www10.w3.org (5.0/NSCS-1.0S) id AA27905; Fri, 24 May 1996 12:07:18 +0500 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id MAA19952 for ; Fri, 24 May 1996 12:07:31 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma019950; Fri May 24 12:07:31 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 MAA08435 for ; Fri, 24 May 1996 12:03:51 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id MAA07892; Fri, 24 May 1996 12:07:24 -0400 Date: Fri, 24 May 1996 12:07:24 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199605241607.MAA07892@argon.ncsc.mil> To: ietf-tls@w3.org Subject: Re: Missing requirements X-Sun-Charset: US-ASCII content-length: 3263 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls > From bsy@work.ucsd.edu Wed May 22 20:07:31 1996 > > > I believe the issue is not whether the platform / OS (it's not just > > an OS question) will be replaced with something "secure", it is whether > > an IETF-standardized protocol should be designed in such a manner as > > to facilitate the development of secure systems, as opposed to relying > > on each separate application to design and incorporate it's own security. > > Perhaps I'm being dense, but I don't see how having -any- security > protocol standardized by IETF would mean relying on every separate app > to design and incorporate its own security. I guess I was trying (poorly) to make the distinction between having a single protocol that does both key management and encryption, and having two independent protocols. The "each separate app" business refers to the relative ease with which applications could be written to include Record-Layer-only code, vs. the difficulty of each app having to also include key and certificate management functions. > As long as (minimally) version numbers exist to provide an on-wire > upgrade path and with reasonable API design, we'd have to at most > relink the apps. Unless, of course, the standardized protocol > actually fails to provide any security properties whatsoever. Yes, you can accomplish anything with version numbers :-). I believe that one of the requirements of the TLS working group should be to specify a Record-Layer protocol that defines the on-the-wire data, along with an (extremely simple) API to allow session keys to be fed into the implementation of the protocol, whether the implementation resides in user space (the browser) or kernel space (the network stack). A completely independent requirement should be to define the handshake protocol by which the session keys are established. That is where all the session/connection state is maintained, where the debate over CipherSuite bundling will occur, where implementations will have to do certificate passing, parsing, validation, and caching, etc. These are the hard problems, and it makes sense to divorce them from the easy problem of defining a record layer. > > Modifying the network stack on Unix hosts only requires kernel > > modifications (and source) if you're using an obsolete Unix. If > > the kernel uses Streams networking (Solaris, for example) the > > application can just push another Streams module onto the stack. > > Installing a streams module require root access. Certainly heretofore > browser installation had not required such, so "just" pushing another > Streams module isn't necessarily something that we can mandate. > Furthermore, last I heard Netscape provided a Linux version of > Navigator, and while users of these systems are more likely to have > root access, Linux/*BSD does not have Streams. That paragraph was just a gratuitous dig at the people who are still using SunOS 4.x. I should have included a smiley, or omitted it altogether. Regardless, compliance with the proposed independent record/handshake TLS protocols does not mandate any particular implementation, app or stack-based. It just happens that separating out the key management protocol enables network stack implementations; it doesn't mandate their use. From bsy@work.ucsd.edu Fri May 24 13:31:00 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id NAA05023 for ; Fri, 24 May 1996 13:30:59 -0400 Received: from odin.ucsd.edu by www10.w3.org (5.0/NSCS-1.0S) id AA28663; Fri, 24 May 1996 13:30:58 +0500 Received: from work.ucsd.edu by odin.ucsd.edu; id AA04138 sendmail 8.73/UCSDPSEUDO.4-CS via SMTP Fri, 24 May 96 10:30:55 -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 KAA21157; Fri, 24 May 1996 10:30:49 -0700 (PDT) Message-Id: <199605241730.KAA21157@work.ucsd.edu> To: dpkemp@missi.ncsc.mil (David P. Kemp) Cc: ietf-tls@w3.org Reply-To: Bennet Yee Subject: Re: Missing requirements In-Reply-To: Your message of "Fri, 24 May 1996 12:07:24 -0400." <199605241607.MAA07892@argon.ncsc.mil> Date: Fri, 24 May 1996 10:30:48 -0700 From: Bennet Yee content-length: 3683 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Hi David, In message <199605241607.MAA07892@argon.ncsc.mil>, David P. Kemp writes: > > I believe that one of the requirements of the TLS working group should > be to specify a Record-Layer protocol that defines the on-the-wire data, > along with an (extremely simple) API to allow session keys to be fed > into the implementation of the protocol, whether the implementation > resides in user space (the browser) or kernel space (the network stack). This would be a very good goal. We do have to be careful about providing mechanisms for not just specifying the bulk encryption / hash functions and injecting the corresponding encryption and MAC keys, but also have a mechanism for the record layer to call-back or otherwise notify the key-exchange/management layer. One of the problems in SSLv2 was that sequence numbers wrapped around, providing the attacker (for long-lived, high volume connections) the opportunity to replay messages and have them MAC okay. To avoid this, there needs to be a mechanism for the record layer to tell the key management layer that the keys need to be refreshened. And while there's no public cryptanalysis of RC4 (the only cipher used in practice for https:) that tells us the maximum stream length that we should use prior to changing keys yet (unicity distance, etc), a mechanism should exist to allow the record layer -- which has the information about how long has the cipher been used as well as the number of records sent -- to likewise signal to the key management layer that a new key should be used. This necessarily implies that a synchronization record must exist to separate the data records that were encrypted using an old key and those encrypted using the new, or that a key-ID be incorporated in the header. Unless, of course, we want to incorporate extra redundency in the encrypted portion so trial decryptions can tell which key was used, which would not be good practice. > A completely independent requirement should be to define the handshake > protocol by which the session keys are established. That is where all > the session/connection state is maintained, where the debate over > CipherSuite bundling will occur, where implementations will have to > do certificate passing, parsing, validation, and caching, etc. > These are the hard problems, and it makes sense to divorce them from > the easy problem of defining a record layer. Agreed. And if we simply include a few fields in the records such as a variable sized cipher-specific data (new stream keys [encrypted] / key ID and new IV), then we can make it UDP-capable and make Charles and other folks happy. Datagram support was, I believe, one of the goals of PCTv2 and STLP (see STLPCiphertext's key_info member). We do have to think hard about what to do w/ datagrams that are delayed -- with stream ciphers and a new stream key per message, every datagram implicitly incorporates a change-key operation; with block ciphers (in CBC mode), all that needs to change on a per-datagram basis is the IV, so a refresh-key operation makes sense. For block ciphers, then, the datagram header should have either a new key and IV, or a key ID (use existing key) and new IV -- and we have to worry about datagrams that are delayed so they arrive after the encryption keys have been updated. Do we discard them, or do we decrypt them and pass them on to the application? Since UDP allows datagram duplication, loss, and reorderings anyway, I'd say to drop 'em. -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 Mon May 27 17:57:49 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id RAA03676 for ; Mon, 27 May 1996 17:57:48 -0400 Received: from odin.ucsd.edu by www10.w3.org (5.0/NSCS-1.0S) id AA16512; Mon, 27 May 1996 17:57:42 +0500 Received: from work.ucsd.edu by odin.ucsd.edu; id AA12865 sendmail 8.73/UCSDPSEUDO.4-CS via SMTP Mon, 27 May 96 14:57:40 -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 OAA06650; Mon, 27 May 1996 14:57:38 -0700 (PDT) Message-Id: <199605272157.OAA06650@work.ucsd.edu> To: Charles Watt Cc: ietf-tls@w3.org Reply-To: Bennet Yee Subject: Re: Missing requirements In-Reply-To: Your message of "Thu, 23 May 1996 16:38:14 -0400." <9605232038.AA07380@mordred.sware.com> Date: Mon, 27 May 1996 14:57:37 -0700 From: Bennet Yee content-length: 4310 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Hi Charles, In message <9605232038.AA07380@mordred.sware.com>, Charles Watt writes: > [ ... ] > This does not work against a stream cipher that incorporates feedback of the > resulting ciphertext into the key stream. Such ciphers are vulnerable if > you reuse the key, but require much more sophisticated techniques to break. > Arguing whether such techniques classify as differential cryptanalysis is > at best nitpicking. > [ ... ] > To quote ISO 8072, the Transport Service Definition, connectionless mode > transmission occurs "without any requirement to maintain any logical > relationship among multiple transport-service-data-units". Sounds like > UDP to me. To which ISO model were you referring? > > Regardless, if there is no extra complexity associated with making the > protocol appropriate for UDP, what are your objections to doing so? > Nitpicking about terminology that isn't even relevant to the topic of > discussion is an annoying waste of time. Yes, I do some nitpicking at times. (I think it's important to get our terminology straight in order to think clearly and communicate effectively.) You're right that a cipher in CFB mode does not suffer from the simple reorigination attack that a true stream cipher does, though the more sophisticated attacks that you allude to are still not differential cryptanalytic attacks. Typically CFB is used for cases where self-synchronization is needed to limit the effects of transmission errors (not a requirement w/ TLS traffic, since except for malicious packets we can assume that the CRCs will work okay); we also don't need error propagation, since we separately check the MAC on the data. There are attacks that are possible (if we allowed the same keys to be used for different sessions) that are simpler than differential cryptanalytic attacks. Certainly applications where a few gibberish blocks are tolerated (true for some data formats where there are fields that are "don't care" or unused by the viewing application, e.g., comment text fields in various image formats) are potentially at risk: using the same key for multiple sessions would open us up to replay attacks -- because MAC computation only depend on the record sequence numbers (and the common MAC key and the current record's data), if the record boundary happens in one of these "don't care" fields then an attacker may substitute records from a different session (but the same record number) into the current session: the substituted data would MAC-check okay, and the cipher will self-synchronize and as long as the "don't care" region is large enough (a block or so) the substituted data would also decrypt okay. This is not a problem for rebroadcasting the same pre-encrypted / pre-MACed data, of course, since there's only one data stream. Oh, thank you for correcting my mistake wrt ISO OSI terminology -- I've been thinking that that particular TSAP is just a thinly veiled NSAP and such trivial interface pass-throughs doesn't "count". (It's been about 10 years since I looked carefully at ISO OSI RM.) As for whether I have objections about UDP, the point of my messages was that I -don't- object to making the protocol usable for UDP, just that we need to examine the complexity-versus-functionality trade-offs. I don't think it's a "given" that we should (or should not) support datagrams. Others on this list had objected to the Microsoft STLP strawman, which was basically SSLv3 with PCTv2 extensions -- mainly datagram support and the ability to pre-encrypt/MAC data for low security data distribution applications such as (Web-based) bulk/multimedia data distribution -- because of disagreements over the trade-offs. I like the bulk data distribution feature, though I'd prefer if HMAC was retained. The datagram support isn't bad either, though as I had pointed out in a previous message, the interaction of rekeying and datagram support hadn't been completely thought out. For your applications, Charles, would STLP suffice? This would be a useful (though single) data point wrt what the consumers of the TLS protocol design want. -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 karlton@netscape.com Tue May 28 05:59:47 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id FAA14231 for ; Tue, 28 May 1996 05:59:47 -0400 Received: from ghoti.mcom.com (h-205-217-232-38.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA19703; Tue, 28 May 1996 05:59:46 +0500 Received: from ghoti (localhost [127.0.0.1]) by ghoti.mcom.com (940816.SGI.8.6.9/8.6.9) with SMTP id CAA14270 for ; Tue, 28 May 1996 02:59:45 -0700 Sender: karlton@netscape.com Message-Id: <31AACE90.167E@netscape.com> Date: Tue, 28 May 1996 02:59:44 -0700 From: Phil Karlton Organization: Netscape Communications X-Mailer: Mozilla 3.0b4 (X11; U; IRIX 5.3 IP22) Mime-Version: 1.0 To: ietf-tls@w3.org Subject: pre-encrypted files Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 4495 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls Of all the changes presented in the Microsoft STLP proposal, I found the support for pre-encrypted files to be the most useful. Pre-encrypted files were considered for SSL 3.0, but we felt that there was not time to finish the design without holding back the rest of the specification. There are two main reasons why a special mechanism for dealing with pre-encrypted files is interesting. One is to keep plain-text versions of the file off the disk of the distributing site. This has the advantage of protecting the file from those that manage to get unauthorized read access to the contents. The second reason for special-casing pre-encrypted files is that there may be a performance advantage for the distributor of the file if the identical contents needs to be made available to multiple recipients. It is this latter reason that seems to motivate the desire to include this in the TLS proposals. There are several issues to keep in mind while folding this support into the existing SSL specification. None of them are compelling reasons not to do the work. The record layering model will end up being reflected all the way up to how the pre-encrypted file is stored on the disk. SSL records are limited to 16K bytes and each fragment is separately MACed. The STLP proposal suggests a particularly weak MAC algorithm merely to allow the MACs to be (mostly) precomputed for the pre-encrypted files. Whatever protocol this group ends up with will be used to support more protocols than merely HTTP. The correct MAC algorithm to use is HMAC which will soon (if not already) be an RFC. The (potentially) weaker integrity requirements for some files (say images) that are broadcast many times, does not allow us to weaken that integrity check for all data for all higher level protocols. If I have time, I'll say more about MACs in a subsequent message. The STLP proposal had the new encryption key arriving in the ChangeCipherSpec message. This is a mistake. The ChangeCipherSpec message is NOT a handshake message; it sits directly on top of the record layer so that there is explicit separation of the different sub-protocols. It also means that there can be a number of changes staged for triggering at a single point. The STLP proposal also used the security of the current stream to protect the new encryption key. This leads to problems if the stream is currently at a less secure mode (null encryption or 40-bit encryption) than the required security of the new data. You do have to be careful not to increase the entropy of a current key above that allowed by U.S. export laws. (This is extremely unfortunate for an international protocol, but that is the reality of the situation.) The STLP proposal includes a stacking method to recover an earlier key value. There is no indication of the stack limit that implementations must support. A more straightforward approach would be to add another SSL handshake message: set write key. Since the two ends already share a 128-bit master key, the originating end could use a new salt together with the current master key to compute a hash and an XOR offset from the desired new encryption key. This could be used by either end and would take effect when the next ChangeCipherSpec message was sent. It has the advantage of not leaking a subsequent key when the previous was compromised. (Keeping the appropriate (according to U.S. export rules) amount of entropy in the new key is left as an exercise to the reader.) It might be tempting to try and transmit a constant (for a file across all users) MAC key using the same method used for the encryption key, but this would be a mistake. An earlier recipient of the file would then have enough information to successfully pull off a MITM attack against a later recipient. There may be a need to be able to set the compression method as well as the encryption key. You could either assume that the compression method will not change for a particular stream (meaning that the server may have to keep multiple copies of the pre-encrypted file ready) or you could introduce another handshake message that would allow the server to choose among the compression methods originally proposed by the browser. PK -- Philip L. Karlton karlton@netscape.com Principal Curmudgeon http://home.netscape.com/people/karlton Netscape Communications They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin From karlton@netscape.com Tue May 28 06:00:34 1996 Received: from www10.w3.org by www19.w3.org (8.6.12/8.6.12) with SMTP id GAA14469 for ; Tue, 28 May 1996 06:00:33 -0400 Received: from ghoti.mcom.com (h-205-217-232-38.netscape.com) by www10.w3.org (5.0/NSCS-1.0S) id AA19725; Tue, 28 May 1996 06:00:31 +0500 Received: from ghoti (localhost [127.0.0.1]) by ghoti.mcom.com (940816.SGI.8.6.9/8.6.9) with SMTP id DAA14277 for ; Tue, 28 May 1996 03:00:30 -0700 Sender: karlton@netscape.com Message-Id: <31AACEBE.2781@netscape.com> Date: Tue, 28 May 1996 03:00:30 -0700 From: Phil Karlton Organization: Netscape Communications X-Mailer: Mozilla 3.0b4 (X11; U; IRIX 5.3 IP22) Mime-Version: 1.0 To: ietf-tls@w3.org Subject: attribute certificates Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit content-length: 1458 X-List-URL: http://lists.w3.org/Archives/Public/ietf-tls There has been very little mention of attribute certificates in this forum, and support is needed in any new protocol. Attribute certificates allow a third party (usually a form of certificate authority) to assert that certain properties are true of the owner of some authentication certificate. Of