On 10/13/2014 2:09 PM, Martin Thomson wrote:
> On 13 October 2014 11:37, Joe Touch <[email protected]> wrote:
>>
>> 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.
>
> That's not a huge problem. An indication would be beneficial, or
> perhaps more appropriately, a control knob to disable TCPINC. That
> would allow people to avoid having two layers of TLS, but at worst
> it's merely suboptimal to have two layers. I don't see there being
> any fundamental problem with having two layers of protection.
The only real issue is:
- if the indication is in the header option space,
then it's susceptible to middleboxes that silently
remove it
- if the indication is in-band, it will be misinterpreted
as data by legacy endpoints
- if the endpoint looks for existing TLS at the beginning
of a connection, then you could have a TCP server
terminating user-level TLS at the client (interfering
with user-level TLS at the server)
I.e., if this is a TCP level solution, it's either indicated by the
header or in-band.
My conclusion is that:
- Once you use the header for an indicator,
you might as well consider protecting at least
some portions of it.
- If you don't use the header as an indicator,
you'll end up interfering with user-level TLS
Joe
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
