From owner-ietf-msgtrk@mail.imc.org Tue Mar 12 19:20:09 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 TAA13096 for ; Tue, 12 Mar 2002 19:20:09 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2D0GSf01052 for ietf-msgtrk-bks; Tue, 12 Mar 2002 16:16:28 -0800 (PST) Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2D0GQ401048 for ; Tue, 12 Mar 2002 16:16:26 -0800 (PST) Received: from maillennium.att.com ([135.25.114.99]) by almso2.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g2D0GO925198 for ; Tue, 12 Mar 2002 19:16:24 -0500 (EST) Received: from att.com ([135.210.75.82]) by maillennium.att.com (mailgw1) with SMTP id <20020313001623gw1001rpuke> (Authid: tony); Wed, 13 Mar 2002 00:16:23 +0000 Message-ID: <3C8E9867.46921FD6@att.com> Date: Tue, 12 Mar 2002 19:08:07 -0500 From: Tony Hansen X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-msgtrk@imc.org Subject: Re: msgtrk: MTQP, TLS, & SRV References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-msgtrk@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Was there a final resolution to this issue? I'll make whatever changes to the document are necessary. Tony Hansen tony@att.com Paul V Ford-Hutchinson wrote: > > 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 From owner-ietf-msgtrk@mail.imc.org Fri Mar 15 14:42:01 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 OAA08190 for ; Fri, 15 Mar 2002 14:42:00 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2FJcuP11694 for ietf-msgtrk-bks; Fri, 15 Mar 2002 11:38:56 -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 g2FJct411687 for ; Fri, 15 Mar 2002 11:38:55 -0800 (PST) Received: from horsey.gshapiro.net (gshapiro@localhost [IPv6:::1]) by horsey.gshapiro.net (8.12.3.Beta1/8.12.3.Beta1) with ESMTP id g2FJcl4G084016 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 15 Mar 2002 11:38:47 -0800 (PST) Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.12.3.Beta1/8.12.3.Beta1/Submit) id g2FJckl8084013; Fri, 15 Mar 2002 11:38:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15506.19910.322625.338248@horsey.gshapiro.net> Date: Fri, 15 Mar 2002 11:38:46 -0800 From: Gregory Neil Shapiro To: Tony Hansen Cc: ietf-msgtrk@imc.org Subject: Re: msgtrk: MTQP, TLS, & SRV In-Reply-To: <3C8E9867.46921FD6@att.com> References: <3C8E9867.46921FD6@att.com> 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 tony> Was there a final resolution to this issue? I'll make whatever changes tony> to the document are necessary. Here is a possible diff to the -04 document (I never saw the -05 draft submitted). What do people think of this change? Should something be used instead of opt-text for the optional parameter? --- mtqp~ Fri Mar 15 11:30:18 2002 +++ mtqp Fri Mar 15 11:35:44 2002 @@ -627,13 +627,19 @@ 6. STARTTLS Command Syntax: - "STARTTLS" CRLF + "STARTTLS" opt-text CRLF TLS [TLS], more commonly known as SSL, is a popular mechanism for enhancing TCP communications with privacy and authentication. An MTQP server MAY support TLS. If an MTQP server supports TLS, it MUST include "STARTTLS" in the option specifications list on protocol startup. + The optional parameter, if specified, MUST be a fully qualified +domain name. A client MAY specify the hostname it believes it is speaking +with so that the server may respond with the proper TLS certificate. This +is useful for virtual servers which provide message tracking for multiple +domains (i.e., virtual hosting). + If the server returns a negative response, it MAY use one of the following response codes: "/" "unsupported" @@ -909,7 +915,7 @@ mtrk-secret = base64 - starttls-command = "STARTTLS" CRLF + starttls-command = "STARTTLS" opt-text CRLF quit-command = "QUIT" CRLF