- From: Alan Freier <freier@netscape.com>
- Date: Tue, 29 Oct 1996 13:13:06 -0800
- To: John H Wilson <John_H_Wilson@ccm.jf.intel.com>
- CC: ietf-tls@w3.org
John H Wilson wrote: > > Is it the expectation of the TLS work group, that any TCP-based protocol > that listens on a well-known port, and now wants a TLS-secured version, > obtain another well-known port for that purpose? > > Or are there other strategies that you could suggest. > > For example, would it be frowned on to have a TLS implementation that > dynamically distinguishes ClientHello from the (insecure) Application > Protocol on a given port (assuming this can be done deterministically)? > > john_h_wilson@ccm.jf.intel.com This has been suggested on several occassions, and I've been one of the opponents to such schemes. The reason is in the last line Mr. Wilson's proposal, the assumption. That assumption has non-zero risk in that it might, under unforseen circumstances, result in ambiguious behavior. To reiterate my position, I believe that a protocol (in the IP world) is basically defined by the well-known port associated with that protocol. To add an SSL layer to such an existing protocol is equivalent to creating a new protocol and therefore demands a new (different) port number. However, I (and I don't think anybody contests this) believe that any new protocol definition should make provision for switching between secure and insecure associations. I would also be the first to admit that my position is a bit of a purist position. Still, somebody's got to represent the fringe :-) AO -- Alan O. Freier Corporate Cynic <freier@netscape.com> (415) 937-3638 (work)
Received on Tuesday, 29 October 1996 16:15:59 UTC