[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-saag
Subject:    [saag] TLS in application protocols - summary so far
From:       "Paul V Ford-Hutchinson" <paulfordh () uk ! ibm ! com>
Date:       2001-10-17 8:59:33
[Download RAW message or body]

This is an S/MIME signed message.


Summarising the discussion so far (as I read it)

- The separate port approach is a bad idea and no new proposal should 
include it.  In the protocols where the practice is not widespread today, 
it should not be encouraged.

- HTTP TLS upgrade (RFC2817) is not deployable in the general web 
client/server case.  To migrate from port 443 (implicit TLS) to port 80 
(negotiated TLS) will require RFC2817 to be replaced - there is currently 
no work being done to do this.

- The multi-homing problem can be solved for https: by the adoption and 
implementation of the DNSname extension to TLS.  This is a pragmatic 
approach.

- For other (not http) protocols, virtual hosting should be achieved by 
the application protocol, prior to a TLS upgrade.

========

I guess that begs some new questions:

- Once DNSname is out there, will there ever be the impetus to replace the 
port 443 approach ?  Do we care ?

- How tenable is it to have fundamentally different approaches for 
different protocols ?  (The way we want to do it for most protocol vs the 
way we don't want to do it for the most used protocol)

- Should we insist that the DNSname extension addresses the fact that the 
application layer may be also performing a host name negotiation (either 
before or after the TLS one) and specify behaviour ?  (is there 
precedence: app vs TLS; first decided; or must there be agreement ? - what 
to do in the case of failure). 

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


["smime.p7s" (application/x-pkcs7-signature)]
_______________________________________________
saag mailing list
saag@mit.edu
http://jis.mit.edu/mailman/listinfo/saag


[prev in list] [next in list] [prev in thread] [next in thread]