A lot of the SSL vs. SSH discussion on here is just demonstrating the fact that there is no one-size-fits-all solution for authentication.<p>The point of tcpcrypt is to get the best security possible under any setting, so it can be used with both SSL- and SSH-like settings. See slide 5 of the talk on the web site:<p><a href="http://tcpcrypt.org/tcpcrypt-slides.pdf" rel="nofollow">http://tcpcrypt.org/tcpcrypt-slides.pdf</a><p>One thing I haven't seen discussed yet is that fact that come October, the EKE patent is going to expire, which means that all of a sudden it's going to be legal to do strong authentication using only human-chosen passwords. Strong password authentication is desperately needed, because people overwhelmingly both chose week passwords and don't think carefully about where they send those passwords.<p>Somewhat independent of tcpcrypt, section 4.3 of the tcpcrypt Usenix paper suggests a nice and simple secure password-authentication protocol. Deploying such a protocol would make a huge difference, except... what are you authenticating? You can prove possession of a password, but this doesn't actually protect you unless the authentication is tied to session traffic, and you are authenticating communication endpoints. SSL, IPSec, and even SSH don't provide adequate hooks for doing this (though SSH would be easier to retrofit than the other two). Tcpcrypt does.<p>So the way to view this is that in the absence of authentication, tcpcrypt will be vulnerable to MITM. But as soon as you go to authenticate yourself to a server (by typing a password or verifying a certificate), the authentication will fail, and the MITM will no longer be able to deceive the user.