On 7/30/2014 9:55 AM, Kevin Glavin wrote:
I also believe that goal of tcpinc is as a response to pervasive
monitoring, so a focus on payload meets that goal. As others mentioned,
protecting the header or portions thereof is widening the goals to
address other attack vectors beyond the goal of hampering pervasive
monitoring.
Kevin
That goal is probably much more quickly and easily addressed by
encouraging use of TLS (https, IMAP/POP with TLS, etc.), and encouraging
servers to either get certificates signed by a known authority or at
least self-signed.
That would side-step the need to modify TCP (a huge hurdle in
comparison) and all the NAT traversal issues (which already generally
support TLS except in cases where TCP encryption is likely to fail too -
e.g., for some regions where the snooped traffic has to match a visible
known profile).
Given TLS support is already available and in widespread use for the
most common apps (web, email), why not just do this via a BCP rather
than creating a new protocol with its related complexities?
Joe
From: Stephen Kent <[email protected] <mailto:[email protected]>>
Date: Tuesday, July 29, 2014 1:17 PM
To: "[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>
Subject: Re: [tcpinc] Protect or not the TCP header
+1
On 2014-7-29, at 8:58, marcelo bagnulo braun<[email protected]> wrote:
the charter reads:
- must always provide integrity protection of the payload data (it is
open for discussion for the WG if the TCP header should or should not
be protected).
So, I dont think we can clarify this, since it is up to the WG to figure it out.
So we do still need to figure it out :-)
My personal take is that the main goal of tcpinc is to make the widespread
eavesdropping on plaintext connections harder. So focus the focus should be on
the payload, and interoperability should trump protection against other attacks.
I fully understand that there are different opinions on this, and they are
equally valid. But we need to figure out where the consensus of the WG on this
lies.
Lars
_______________________________________________
Tcpinc mailing list
[email protected]https://www.ietf.org/mailman/listinfo/tcpinc
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
