On Mon, Jan 20, 2014 at 10:27 AM, Dave Crocker <[email protected]> wrote:
> 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 looks more like an alternative to IPSEC than TLS to me. Given that IPSEC has been a flop, working on an alternative twenty years later seems fine to me. The types of use case where I see problems with our current infrastructure are for applications such as wireless networking where WiFi security is still a usability disaster and remote access (aka dialup but we don't dialup any more). One major design limit in IPSEC and TLS is that both view the key exchange as being integral to the security layer rather than a separate service. I would like to separate out consideration of how chunks of data passing over the net are tagged and bagged for encryption and authentication from the question of key setup. There is no logical reason why the key negotiation for TLS, IPSEC and tcpcrypt cant be shared. -- Website: http://hallambaker.com/
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
