Subject: Re: msgtrk: MTQP, TLS, & SRV

From: Tony Hansen <[email-masked]>
Date: Tue, 12 Mar 2002 19:08:07 -0500

Was there a final resolution to this issue? I'll make whatever changes
to the document are necessary.

	Tony Hansen
	[email-masked]

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 :
> [email-masked]
> 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: Gregory Neil Shapiro <[email-masked]>
Date: Fri, 15 Mar 2002 11:38:46 -0800

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