On Sat, Jan 25, 2014 at 4:10 PM, Christian Huitema <[email protected]>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/
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
