On 10/13/2014 11:32 AM, Martin Thomson wrote: > On 13 October 2014 11:22, Christian Huitema <[email protected]> wrote: >>> I.e., any option-based solution might not work through a middlebox - >>> including the one that signals the use of TCPINC. At that point, we're >>> back to running TLS, and it seems pointless to discuss this as a TCP >>> variant, IMO. >> >> I agree with Joe. Can we list the attacks that would not be prevented by >> TLS, but that would be prevented by a version of TCPINC that does not >> protect the TCP header? > > I thought that seamless (i.e., opportunistic) negotiation of the > ability to run TLS was valuable, if nothing else.
TLS using unsigned (or self-signed) certs might be useful, but we've been talking about a TCP-level solution so it wouldn't interfere with userland TLS. That requires TCP-level indication that TLS is being used. That requires indicating the use of the additional layer of TLS somewhere - in the port number, in a TCP option, etc. - but NOT in the data stream because AFAICT we can't tell the difference between TCP-level TLS and userland TLS. (FWIW, if we can, then we ought to be talking about this as a seamless presentation layer and get "TCP" out of the discussion) Joe _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
