Re: [perpass] tcpcrypt applicability

["Christian Huitema" <[e-mail]>]

From: Dave Crocker, Monday, January 20, 2014 7:27 AM
> On 1/20/2014 7:19 AM, Stephen Farrell wrote:
>> I'd expect that if tcpcrypt were implemented in
>> some kernels then it'd be useful in places where you can't
>> feasibly use TLS.
>
>
> what are some examples of when this could occur?
>
> as long as there is speculation about this as a legitimate alternative, 
> it would help to have the speculation include plausible examples.

TCPCRYPT is a very good way to do opportunistic encryption. It will
negotiate encryption by default at the beginning of the TCP session, without
any attempt to provide authentication. At the same time, the stack provides
a unique identifier of the encryption session, which can be used by the
application protocol to perform authentication and detect MITM by any way
they see fit -- PKI, EKE, PGP, some application specific scheme, or even
nothing if the application does not care. The architecture looks what we
should have done 20 years ago. Kudos to the authors of the spec.

But then, the big question is, is it deployable? First, it pretty much
requires OS implementation. I can foresee interesting discussions before big
development teams decide to do this. It also supposes a communication API
between app and stack, and also some yet-to-be-standardized application
protocols for managing the encryption identifiers. That too will take time.
And then it requires new TCP options, which many NAT and firewalls are known
to block by default.

In short, high potential, but likely to remain a small deployment for
several years. If I were a transport AD, I would charter the group and give
them time to grow... but of course I know better than give advice to the
folks actually doing the work.

-- Christian Huitema