Re: msgtrk: MTQP, TLS, & SRV

["Paul V Ford-Hutchinson" <paulfordh@xxxxxxxxxx>]

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