(changing the subject to match the thread)
On 7/30/2014 11:59 PM, Eggert, Lars wrote:
Hi,
On 2014-7-30, at 19:04, Joe Touch <[email protected]> wrote:
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.
using TLS requires changes to the application on both endpoints.
Yes. Using a TCP solution requires changes to the OS on both endpoints.
We have ample evidence that the former is easy to do and deploy in a
widespread fashion - HTTPS, IMAP/POP with TLS, etc.
Having a solution inside TCP would protect apps that aren't protected,
but by using "cleartext" port numbers we are also increasing the risk
that those connections will be blocked by DPI devices.
My concerns are as follows:
- this work is motivated by the desire for greater protection
against pervasive monitoring
- a solution to pervasive monitoring should not make the
Internet more fragile or fragmented (IMO)
- such monitoring is already inhibited by TLS
- where TLS is blocked, I would expect a TCP or IP solution
to also be blocked
If the sole goal is anti-monitoring, we have what we need.
I also fear that a TCP-based solution might present a misleading view
that a session is E2E protected when a MITM acts as a TCPINC proxy; TLS
already has well-established procedures by which users can examine a
certificate and determine whether to trust it. Building that into an OS
and integrating its management with the user application (esp. legacy
apps) isn't going to be as intuitive.
Joe
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
