By the way, if you want an intro to tcpcrypt, it's probably best to start with the Usenix Security paper: http://tcpcrypt.org/tcpcrypt.pdf It does a better job of explaining what we're trying to achieve than the internet draft.
Or as a quick intro, the video of the Usenix Security session by Andrea Bittau: http://tcpcrypt.org/talk.php Cheers, Mark On Tue, Sep 17, 2013, at 04:06 AM, Mark Handley wrote: > > 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 _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
