tcpcrypt has been mostly dormant for the last couple of years, as we didn't really gain traction in the IETF last time round. I (and I believe my co-authors) still believe that tcpcrypt (or something similar) is a key part of moving forward on improving general Internet security, and especially on large-scale passive eavesdropping. We're happy and ready to put in energy if there's interest now.
The key reason for an approach at this layer in the stack is that it gets you the most bang for the buck. By leveraging the TCP handshake, you can get sessions encypted very easily with minimal infrastructure deployment, and only a single change to the stack. It's much harder to do that at the IP layer because there's no handshake, and it's hard to roll out _everywhere_ above TCP (it shouldn't really be so hard, but all the evidence of the last couple of decades is that it is). So our philosophy is: - Separate encryption from authentication. - Encryption is easy, and application-independent. Enable encryption by default, using ephemeral public keys for key exchange. - Authentication is hard and application-dependent (which also makes it dependent on the TCP port - different TCP ports need different authentication). Provide the hooks in tcpcrypt to support a wide range of authentication in applications running over the top of tcpcrypt. - Provide a hook in tcpcrypt so each end knows if the other end's application is capable of negotiating the next layer. We also showed how to do key exchange fast in servers, so there should be little cost of enabling it. In the long run we'd hope all TCP sessions would be encrypted, but wouldn't expect all to the authenticated. An interesting benefit is you cannot tell from eavesdropping whether or not an encrypted session will also be authenticated. This makes mounting a MITM attack risky if you want to go unobserved. As for PFS - tcpcrypt allows key resuse, but discourages doing too much reuse. It's up to the implementation how frequently to generate new key pairs, but it would be easy to do this in the background when idle. Whether you get PFS or not depends on how often the keys are reused (you can choose to never reuse, at some cost), but keys are never kept around for long. There's certainly no CA to subvert as far as encryption is concerned. Cheers, Mark > 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 > > > > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
