On 10/13/2014 2:09 PM, Martin Thomson wrote:
> On 13 October 2014 11:37, Joe Touch 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
On 13 October 2014 11:37, Joe Touch 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 differ
On 10/13/2014 11:32 AM, Martin Thomson wrote:
> On 13 October 2014 11:22, Christian Huitema 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 t
On 10/13/2014 11:22 AM, Christian Huitema 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
On 13 October 2014 11:22, Christian Huitema 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
> 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 prevent
On 10/6/2014 11:19 PM, marcelo bagnulo braun wrote:
> El 07/10/14 08:04, John-Mark Gurney escribió:
>>
>
>>> Option 2 - Protect the payload plus some fields of the TCP header
>>> For this option we believe there are 3 possible approaches:
>>> Option 2.a -- include the MAC (and other relevant inf
On 13 October 2014 06:20, Brandon Williams wrote:
> I prefer option 1 for the reasons that John and Michael state.
My analysis of the header (which I can share) indicates that there is
very little value in protecting anything in the header (or
pseudoheader, which I note was not considered in the
I prefer option 1 for the reasons that John and Michael state.
That said, if header integrity protection is the general consensus, I prefer
> -- include the MAC for the TCP header fields in a TCP option and the
> MAC for the payload in the payload
because I believe it can be made to work throug
