Re: [Tcpcrypt] v3 of the charter

[David Mazieres <[e-mail]>]

Daniel Kahn Gillmor <[e-mail]> writes:

> I know i raised the fingerprinting concern earlier here, but i'm
> concerned that this statement actually goes too far.  "must not increase
> information available for fingerprinting" implies that peers basically
> cannot cache state between subsequent connections, which seems like an
> obvious opportunity for performance improvements.

Exactly.  I'm worried that we are over-specifying stuff before we
understand the design space or know the trade-offs.  In particular, it
turns out that TCP is pretty fingerprintable anyway (e.g.,
Kohno/Broido/Claffy) and adding a new option is only going to make that
worse.  (Hey, there's a reason my mail server, mail avenger, puts an
abstract of the SMTP connection's SYN segment in a mail header.)  So
really the charter is too early a place to decide to resolve these
trade-offs in favor of privacy.

To my mind, the only thing that's really in scope for the charter is to
say drafts should discuss their effects on fingerprinting.  If different
proposals facilitate fingerprinting to different extents, then this is
one thing to take into account when weighing one proposal against
another.

My personal opinion is that we want to optimize for speed in the common
case and ensure sufficient APIs are available that if people defeat all
the other fingerprinting techniques (from TCP to HTTP-level stuff) TCP
Inc. isn't the one thing left by which you can't avoid fingerprinting.
But remember, the API document is only going to be informational anyway.

So for all these reasons, putting language in the charter to the effect
that TCP Inc. must not exacerbate fingerprinting is likely to gunk up
the standardization process without necessarily yielding any improvement
in privacy.


By the way, this principal applies to most other aspects of the
protocol.  E.g., I see Erik Nygren brought up the issue of DoS
resilience.  That's a great point.  I suspect we will find that DoS
resilience is part of a complex four-way trade-off also involving
normal-case fingerprint-resistance, minimizing use of option space in
SYN segments, and minimizing connection latency.  Do we really want the
charter to prioritize fingerprint-resistance and option space over DoS
resilience and latency?  I'd rather line up a bunch of proposals and
then decide the trade-offs.

That means we should pick the minimum set of requirements.  If it were
up to me, I'd summarize the requirements in a mere three sentences:

    - In the absence of an active attacker, must provide forward secrecy
      between any two hosts that use it, with no configuration required.

    - For TCP-Inc.-aware applications, must provide endpoint
      authentication hooks that can guarantee forward secrecy and
      integrity of the TCP data stream against active attackers.

    - Must gracefully support incremental deployment over today's
      Internet.

Beyond that, I'd say there are a bunch of desirable properties, and
there are issues (like fingerprinting) that each draft must discuss.
But we shouldn't place any further *requirements* on the design.

David