On 7/29/2014 9:47 AM, Bodo Moeller wrote:
Joe Touch <[email protected] <mailto:[email protected]>>:
However, TCP options are for changing the behavior of TCP - not of
the next layer. TLS doesn't change TCP at all.
Well, that's if you think of TLS as (a sublayer of) an application
protocol.
It already is; that's how it's widely used.
> You could think of it as a sublayer of the transport protocol
instead. STARTTLS and the like aside, TLS basically doesn't change the
application protocol either. (In other words, may TLS is called
"Transport Layer Security" for a reason :-) )
It's really stream layer - not really transport (which would protect the
transport headers), not really application.
Besides, TLS already works just fine without it.
It does, if the application explicitly supports that. TCPINC, however,
is about providing protection against pervasive surveillance, with
opportunistic encryption without any changes to application protocol
specifications and implementations; so using TCPINC to negotiate use of
TCP certainly would add value.
That said, I now think that TCPINC should offer support to protect some
information from the TCP header, probably as an opt-in feature (with
rudimentary protection enabled by default). Simply enabling TLS for the
data stream clearly doesn't achieve that.
That's my view too; IMO, if we want to have TLS turned on as a default
in a "shim" layer we shouldn't need to negotiate that in a TCP option.
Joe
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
