Re: [perpass] tcpcrypt applicability

[Phillip Hallam-Baker <[e-mail]>]

On Sat, Jan 25, 2014 at 4:10 PM, Christian Huitema <[e-mail]>wrote:

> 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.
>

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/