On 7/29/2014 8:48 AM, Eric Rescorla wrote:
On Tue, Jul 29, 2014 at 8:41 AM, Joe Touch <[email protected] <mailto:[email protected]>> wrote: On 7/29/2014 8:36 AM, Eric Rescorla wrote: On Tue, Jul 29, 2014 at 8:33 AM, Joe Touch <[email protected] That would be my view as well; TLS should never be involved with or triggered by TCP. Can you say more about why? It's a payload mechanism. IMO, involving TLS with TCP is layer crossing, and I don't see any good reason for it. Hmm... I'm not sure I follow this. We already use the TCP port number to indicate which protocol you are speaking. The problem is that it's not a negotiation. What's wrong with having a protocol offer and selection mechanism at the TCP layer (which is what my draft basically is).
TCP ports are like a "next header" tag. Yes, I would have preferred it to be a header after TCP that identifies the session protocol, and we're paying for that not being the case.
However, TCP options are for changing the behavior of TCP - not of the next layer. TLS doesn't change TCP at all. I don't like using a TCP option as a flag on a port number.
Besides, TLS already works just fine without it. Joe _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
