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 _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
