Subject: Re: [perpass] tcpcrypt applicability

From: "Christian Huitema" <[email-masked]>
Date: Sat, 25 Jan 2014 13:10:58 -0800

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 27 Jan 2014 11:28:36 -0500

> And then it requires new TCP options, which many NAT and firewalls are

Hence my proposal that this is something we should look at in conjunction
with TLSvNext.

There are two parts to any crypto transport, there is a key exchange and a
transport binding. Hitherto we have treated these as being intrinsically
and inseparably connected. So IPSEC uses IPSEC key exchange, TLS uses TLS
key exchange and so on.

If we separate the concerns here we could have one key exchange which could
be used with an IP, TCP, Socket or Message layer transport binding.

I certainly don't want a pure TCP layer binding because the application
needs to know what the security context is and what the key is
authenticated to. So I need some of the crypto to be visible at the socket
layer.

But I can certainly see room for a scheme where the TCP layer in the
platform looks to see if the upper layer is doing crypto and if not does
crypto opportunistically.

But then that raises the question of integration with DNS and our issues
with DNSSEC transport being only 97% visible at best but any deployment
having to work in 99.99999% of network configurations.

-- 
Website: http://hallambaker.com/