Re: msgtrk: MTQP, TLS, & SRV

[Tony Hansen <tony@xxxxxxx>]

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

	Tony Hansen
	tony@xxxxxxx

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@xxxxxxxxxx
> 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