Hi, Jeff raised tcpcrypt [1] in his earlier email.
When this proposal came up a few IETFs ago, I was against it on the basis that we already have IPsec and TLS so why would we want yet another way to protect TCP sessions? Esp. since it didn't seem to allow the flexibility of IPsec or TLS in terms of key mgmt, nor have a DTLS variant etc etc. Maybe I was wrong. I'm not sure I was, but I do think its at least worth looking at again. I guess that tcpcrypt does do opportunistic encryption of TCP sessions, which now seems more attractive. A bit more heterogeneity in the infrastructure might also be useful and maybe some of the MITM attacks on TLS that have been done wouldn't be nearly as easy on this. (The ones where a CA has been subverted.) And now that MPTCP is going to attempt to be moved to the standards track, that will need better security than the experimental MPTCP RFC has, and this could do that. On the negative side, I'm not sure if this is still a live proposal, nor if it'd really get traction. I just don't know if using the data portion of segments works for key exchange. tcpcrypt doesn't currently seem to support PFS if public keys are re-used either. I guess there're also a bunch of other bits and pieces in there that'd need work as well. This might also be over-the-top for MPTCP's needs. And maybe we'd be better off putting effort into opportunistic encryption at the IP layer and in TLS. I'd be interested in knowing what folks think about that. Personally, I'm not sure, but if there were a groundswell of support for progressing tcpcrypt then I at least would be more interested than I was a year ago. Thanks, S. [1] https://tools.ietf.org/html/draft-bittau-tcp-crypt _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
