Hi Mark, On 09/17/2013 12:13 PM, 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.
Great. So anyone else here think that's a good plan and might get traction? I'd also be keen to know if you've any thoughts on the mptcp question - do you think tcpcrypt could be a real option for mptcp security? Cheers, S. > > 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
