From owner-ietf-msgtrk@mail.imc.org Fri Feb 8 15:45:52 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24184 for ; Fri, 8 Feb 2002 15:45:51 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18Kguu18869 for ietf-msgtrk-bks; Fri, 8 Feb 2002 12:42:56 -0800 (PST) Received: from lin2.andrew.cmu.edu (LIN2.ANDREW.CMU.EDU [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18Kgt318865 for ; Fri, 8 Feb 2002 12:42:55 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) by lin2.andrew.cmu.edu (8.12.2.Beta3/8.12.2.Beta3) with ESMTP id g18Kgea4019031; Fri, 8 Feb 2002 15:42:40 -0500 Date: Fri, 8 Feb 2002 15:42:40 -0500 Message-Id: <200202082042.g18Kgea4019031@lin2.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: Tony Hansen Cc: ietf-msgtrk@imc.org Subject: msgtrk: MTQP, TLS, & SRV Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There is currently a discussion going on in LDAPEXT about STARTTLS and the interaction with SRV records that is probably of interest to MTQP. I note that MTQP uses SRV records (or MX records) to find which host to connect to, but I don't see any text on what name to expect once it gets there. This should probably be clarified. It might also be nice to point out that, on multi-homed MTQP servers, use of SRV records with the port specification can get around not knowing what certificate to hand back. Another possibility would be to add a "certificate expected" argument to the STARTTLS command, allowing the server to choose which certificate to return. I believe there was discussion of this in a working group meeting, but I don't recall what the outcome of it was. Larry From owner-ietf-msgtrk@mail.imc.org Fri Feb 8 16:03:26 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24729 for ; Fri, 8 Feb 2002 16:03:26 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18KtU719188 for ietf-msgtrk-bks; Fri, 8 Feb 2002 12:55:30 -0800 (PST) Received: from lin2.andrew.cmu.edu (LIN2.ANDREW.CMU.EDU [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18KtT319178 for ; Fri, 8 Feb 2002 12:55:29 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) by lin2.andrew.cmu.edu (8.12.2.Beta3/8.12.2.Beta3) with ESMTP id g18KtLa4019040; Fri, 8 Feb 2002 15:55:21 -0500 Date: Fri, 8 Feb 2002 15:55:21 -0500 Message-Id: <200202082055.g18KtLa4019040@lin2.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: Gregory Neil Shapiro Cc: ietf-msgtrk@imc.org, Tony Hansen In-reply-to: <15460.15047.458735.102587@horsey.gshapiro.net> Subject: Re: msgtrk: MTQP, TLS, & SRV References: <200202082042.g18Kgea4019031@lin2.andrew.cmu.edu> <15460.15047.458735.102587@horsey.gshapiro.net> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Fri, 8 Feb 2002 12:53:27 -0800 From: Gregory Neil Shapiro [...] When this was discussed for updating RFC 2487, the decision was to leave that to the TLS working group. As I recall, it was then brought up in that working group and it was agreed it should be part of the TLS client hello protocol. Yeah, they've been arguing about it for quite some time over there and I've mostly lost interest in following it, especially when their listserver bounced my message and then bounced my annoyed reply to their bounce. Personally, I'd rather see this solved in the underlying protocol then have each application protocol fix it independently (and differently). Regardless, MTQP needs to specify what certificate name needs to be sent. Larry From owner-ietf-msgtrk@mail.imc.org Fri Feb 8 16:03:30 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24741 for ; Fri, 8 Feb 2002 16:03:30 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g18L0Sk19346 for ietf-msgtrk-bks; Fri, 8 Feb 2002 13:00:28 -0800 (PST) Received: from horsey.gshapiro.net (root@horsey.gshapiro.net [209.220.147.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18L0R319342 for ; Fri, 8 Feb 2002 13:00:27 -0800 (PST) Received: from horsey.gshapiro.net (gshapiro@localhost [IPv6:::1]) by horsey.gshapiro.net (8.12.2/8.12.3.PreAlpha0) with ESMTP id g18L0Lku084704 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 8 Feb 2002 13:00:21 -0800 (PST) Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.12.2/8.12.2/Submit) id g18L0HSA084700; Fri, 8 Feb 2002 13:00:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15460.15457.468738.477381@horsey.gshapiro.net> Date: Fri, 8 Feb 2002 13:00:17 -0800 From: Gregory Neil Shapiro To: Lawrence Greenfield Cc: ietf-msgtrk@imc.org, Tony Hansen Subject: Re: msgtrk: MTQP, TLS, & SRV In-Reply-To: <200202082055.g18KtLa4019040@lin2.andrew.cmu.edu> References: <200202082042.g18Kgea4019031@lin2.andrew.cmu.edu> <15460.15047.458735.102587@horsey.gshapiro.net> <200202082055.g18KtLa4019040@lin2.andrew.cmu.edu> X-Mailer: VM 7.00 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Personally, I'd rather see this solved in the underlying protocol then have > each application protocol fix it independently (and differently). leg+> Regardless, MTQP needs to specify what certificate name needs to be leg+> sent. Why "regardless"? If it is solved in the TLS protocol, why duplicate it in the MTQP protocol? Or are you assuming it will never be solved by the TLS protocol? From owner-ietf-msgtrk@mail.imc.org Fri Feb 8 16:06:40 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24923 for ; Fri, 8 Feb 2002 16:06:40 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18L3xI19483 for ietf-msgtrk-bks; Fri, 8 Feb 2002 13:03:59 -0800 (PST) Received: from lin2.andrew.cmu.edu (LIN2.ANDREW.CMU.EDU [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18L3v319472 for ; Fri, 8 Feb 2002 13:03:57 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) by lin2.andrew.cmu.edu (8.12.2.Beta3/8.12.2.Beta3) with ESMTP id g18L3ka4019054; Fri, 8 Feb 2002 16:03:46 -0500 Date: Fri, 8 Feb 2002 16:03:46 -0500 Message-Id: <200202082103.g18L3ka4019054@lin2.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: Gregory Neil Shapiro Cc: Tony Hansen , ietf-msgtrk@imc.org In-reply-to: <15460.15457.468738.477381@horsey.gshapiro.net> Subject: Re: msgtrk: MTQP, TLS, & SRV References: <200202082042.g18Kgea4019031@lin2.andrew.cmu.edu> <15460.15047.458735.102587@horsey.gshapiro.net> <200202082055.g18KtLa4019040@lin2.andrew.cmu.edu> <15460.15457.468738.477381@horsey.gshapiro.net> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Fri, 8 Feb 2002 13:00:17 -0800 From: Gregory Neil Shapiro Cc: ietf-msgtrk@imc.org, Tony Hansen leg+> Regardless, MTQP needs to specify what certificate name needs to be leg+> sent. Why "regardless"? If it is solved in the TLS protocol, why duplicate it in the MTQP protocol? Or are you assuming it will never be solved by the TLS protocol? The multi-homed server problem can be solved in the TLS protocol. What name the client expects cannot. I do a SRV look on _mtqp._tcp.smtp3.example.com and get back msgtrk.example.com, port 4530. I connect to msgtrk.example.com 4530, and issue STARTTLS. What certificate name should I expect? (In a future TLS protocol, what certificate name should I request?) "smtp3.example.com" might not be a great choice: that certificate name may already be in use on a different machine. "msgtrk.example.com" is definitely wrong---I received it from the insecure DNS system. "_mtqp._tcp.smtp3.example.com" makes some sense but is kinda ugly. You can see the LDAP SRV discussion on ldapext for more on this. Larry From owner-ietf-msgtrk@mail.imc.org Fri Feb 8 16:14:52 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25143 for ; Fri, 8 Feb 2002 16:14:52 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18Ks3419141 for ietf-msgtrk-bks; Fri, 8 Feb 2002 12:54:03 -0800 (PST) Received: from horsey.gshapiro.net (root@horsey.gshapiro.net [209.220.147.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18Kru319136 for ; Fri, 8 Feb 2002 12:53:57 -0800 (PST) Received: from horsey.gshapiro.net (gshapiro@localhost [IPv6:::1]) by horsey.gshapiro.net (8.12.2/8.12.3.PreAlpha0) with ESMTP id g18KrUku084596 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 8 Feb 2002 12:53:30 -0800 (PST) Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.12.2/8.12.2/Submit) id g18KrRQg084593; Fri, 8 Feb 2002 12:53:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15460.15047.458735.102587@horsey.gshapiro.net> Date: Fri, 8 Feb 2002 12:53:27 -0800 From: Gregory Neil Shapiro To: Lawrence Greenfield Cc: Tony Hansen , ietf-msgtrk@imc.org Subject: Re: msgtrk: MTQP, TLS, & SRV In-Reply-To: <200202082042.g18Kgea4019031@lin2.andrew.cmu.edu> References: <200202082042.g18Kgea4019031@lin2.andrew.cmu.edu> X-Mailer: VM 7.00 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit leg+> Another possibility would be to add a "certificate expected" argument leg+> to the STARTTLS command, allowing the server to choose which leg+> certificate to return. I believe there was discussion of this in a leg+> working group meeting, but I don't recall what the outcome of it was. When this was discussed for updating RFC 2487, the decision was to leave that to the TLS working group. As I recall, it was then brought up in that working group and it was agreed it should be part of the TLS client hello protocol. Personally, I'd rather see this solved in the underlying protocol then have each application protocol fix it independently (and differently). From owner-ietf-msgtrk@mail.imc.org Fri Feb 8 19:42:34 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28324 for ; Fri, 8 Feb 2002 19:42:34 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g190e4525338 for ietf-msgtrk-bks; Fri, 8 Feb 2002 16:40:04 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g190e3325334 for ; Fri, 8 Feb 2002 16:40:03 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g190du910968; Fri, 8 Feb 2002 19:39:56 -0500 (EST) Message-Id: <200202090039.g190du910968@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Lawrence Greenfield cc: Gregory Neil Shapiro , Tony Hansen , ietf-msgtrk@imc.org Subject: Re: msgtrk: MTQP, TLS, & SRV In-reply-to: (Your message of "Fri, 08 Feb 2002 16:03:46 EST.") <200202082103.g18L3ka4019054@lin2.andrew.cmu.edu> Date: Fri, 08 Feb 2002 19:39:56 -0500 Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > "smtp3.example.com" might not be a great choice: that certificate name > may already be in use on a different machine. is that really a problem? can't there be different keys (on different machines) for a single principal? From owner-ietf-msgtrk@mail.imc.org Fri Feb 8 22:27:54 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01223 for ; Fri, 8 Feb 2002 22:27:54 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g193QsK27887 for ietf-msgtrk-bks; Fri, 8 Feb 2002 19:26:54 -0800 (PST) Received: from lin2.andrew.cmu.edu (LIN2.ANDREW.CMU.EDU [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g193Qq327883 for ; Fri, 8 Feb 2002 19:26:53 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) by lin2.andrew.cmu.edu (8.12.2.Beta3/8.12.2.Beta3) with ESMTP id g193Qka4019178; Fri, 8 Feb 2002 22:26:46 -0500 Date: Fri, 8 Feb 2002 22:26:46 -0500 Message-Id: <200202090326.g193Qka4019178@lin2.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: Keith Moore Cc: ietf-msgtrk@imc.org, Tony Hansen , Gregory Neil Shapiro In-reply-to: <200202090039.g190du910968@astro.cs.utk.edu> Subject: Re: msgtrk: MTQP, TLS, & SRV References: <200202090039.g190du910968@astro.cs.utk.edu> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: Keith Moore cc: Gregory Neil Shapiro , Tony Hansen , ietf-msgtrk@imc.org Date: Fri, 08 Feb 2002 19:39:56 -0500 > "smtp3.example.com" might not be a great choice: that certificate name > may already be in use on a different machine. is that really a problem? can't there be different keys (on different machines) for a single principal? If the two machines are under identical adminstrative control (probably an ok assumption for msgtrk) and if compromising one machine is acceptable for impersonating the other, this is ok. Larry From owner-ietf-msgtrk@mail.imc.org Mon Feb 11 06:49:45 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28557 for ; Mon, 11 Feb 2002 06:49:45 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1BBkwT14281 for ietf-msgtrk-bks; Mon, 11 Feb 2002 03:46:58 -0800 (PST) Received: from d06lmsgate-4.uk.ibm.COM (d06lmsgate-4.uk.ibm.com [195.212.29.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BBks314274 for ; Mon, 11 Feb 2002 03:46:55 -0800 (PST) Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate-4.uk.ibm.COM (1.0.0) with ESMTP id LAA82776 for ; Mon, 11 Feb 2002 11:33:27 GMT Received: from d06ml035.portsmouth.uk.ibm.com (d06ml035_cs0 [9.180.35.16]) by d06relay01.portsmouth.uk.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1BBjs8182120 for ; Mon, 11 Feb 2002 11:45:56 GMT To: ietf-msgtrk@imc.org MIME-Version: 1.0 Subject: Re: msgtrk: MTQP, TLS, & SRV X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Paul V Ford-Hutchinson" Message-ID: Date: Mon, 11 Feb 2002 11:46:16 +0000 X-MIMETrack: Serialize by Router on D06ML035/06/M/IBM(Release 5.0.8 |June 18, 2001) at 11/02/2002 11:46:25, Serialize complete at 11/02/2002 11:46:25 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Gregory Shapiroi wrote: >leg+> Another possibility would be to add a "certificate expected" argument >leg+> to the STARTTLS command, allowing the server to choose which >leg+> certificate to return. I believe there was discussion of this in a >leg+> working group meeting, but I don't recall what the outcome of it was. >When this was discussed for updating RFC 2487, the decision was to leave >that to the TLS working group. As I recall, it was then brought up in that >working group and it was agreed it should be part of the TLS client hello >protocol. >Personally, I'd rather see this solved in the underlying protocol then have >each application protocol fix it independently (and differently). There are two separate but intertwined issues here. i) Virtual Hosting ii) TLS server identity Virtual Hosting is where one port (== application protocol running on a well known port) on one host (== IP address) is actually perceived, by the client, to be multiple destinations. This is achieved by DNS. In order to support 'virtual Hosting' the application protocol must be modified to provide the DNS name of the intended destination. TLS server identity is the identity that the server verifies as part of the TLS handshake (usually the CN in an X.509v3 cert) For (http) Virtual Hosting a) client wants http on www.freddy.com b) client resolves http to '80' and www.freddy.com to '10.20.30.40' c) client connects to '10.20.30.40:80' d) client passes 'www.freddy.com' as part of the application protocol. Now, TLS breaks that, because it introduces a new step 'c+' (TLS handshake) which provides the TLS server identity that can be used to identify the server in step c+) without having the knowledge passed in the application protocol in step d). So, we have two ways to fix this: I) add the ability to pass the hostname in step c+) II) perform the TLS negotiation in step d+) For https we are stuck with I) (which is OK, because hostname == identity for HTTPS) For new protocols - if virtual hosting is defined for the non-TLS version of the protocol then the approach should be II) There is no need for a server-name indication on the STARTTLS command. If there is no vitual hosting - there is no problem If there is no non-tls version of the protocol then I guess the app protocol could choose either way - but I wouldn't recommend holding up an app protocol until tls-extensions gets done. For info - the proposed TLS extensions allow no server hostname negotiation and restrict the value to 'DNSname' only. Paul -- Paul Ford-Hutchinson : eCommerce application security : paulfordh@uk.ibm.com MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5JL +44 (0)1926 462005 http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html