No, anything requiring publishing DNS records won't fly. OE is *opportunistic*. It doesn't care about what the true identity of the opposite party is. Any shmuck on dynamic IP should be able to use it instantly, with no observable performance degradation, using a simple patch.
If it doesn't fit these minimal requirements, it will die, just the same way FreeS/WAN did.
I absolutely agree. While it's possible to do things like MIM attacks if you don't know who the other guy is, look at how successful SSH is over any other kind of solution. Its biggest competitor at the time it was introduced was kerberized telnet/ftp. How many networks do you know that use Kerberos instead of ssh these days?
Look at how many folks use PGP - those who really know it and want it, or those who know enough about it and have some easily automated implementation that plugs in to their mail client. (i.e. commercial pgp with Eudora/Outlook plug in. As an aside, I'm still pissed off that the Mozilla mail client doesn't support PGP/GPG in addition to S/MIME or whatever the hell..)
Adding another infrastructure requirement that requires ISP layer changes will exponentially raise resistance to its adoption. While I do run my own server for mail/web, 99.9% of the internet luser population doesn't - and even so, I chose not to run my own DNS server. (Allowing register.com to do so makes it safer for me: it's one less service that might be compromised due to possible bugs.)
Making it optional to add that infrastructure layer - whether it's via DNS, LDAP, signed public keys, web o' trust / pgp keyserver, finger, or even something entirely new, is probably the safer way to go, BUT don't require it.
There do exist transparent web caching proxies out there (usually advertised as web accelerators.) I ran across such a few months ago when our satellite office couldn't connect to one of our servers. We were using private dns virtual host names to access management web pages on our servers. However the proxy intercepted those requests, and tried to resolve DNS, but obviously couldn't, so everyone in the office got a DNS error. It took some pretty strong words to get the ISP to even admit that they were using such a beast, much less disable it just for us.
It's certainly possible to create a proxy to do MitM interception that would foil even SSH. This wouldn't work so well against mobile devices which might fortuitously use a different route, but would work very well one hop above the server if that's the only pipe the server has.
There are ways to protect against this such as publishing a line for the known-hosts entry by other means, but no one does this (yet?) (i.e: sneakernet, finger, web page, pgp signed/encrypted email, over the telephone, etc.) (Another useful thing is to use public keys for SSH instead of passwords: this way the attacker won't be able to reuse your password - but you're still compromised the second you login.)
There are some rare cases where you absolutely want to know who you are talking to. For example an https server that allows control of financial data. Even in that case the server doesn't fully know who the client is, and doesn't need to (in order to establish the secure link) -- until a login (or CC info) is presented. In the case of using OE to talk to a server, the client already has some idea of the server's identity, and the server will eventually have some idea of who the client is.
As an aside: Just doing the above to encapsulate emails won't help at all against spamming: the spammers will just randomly generate throw away public keys, etc. They've already written trojan spammers with their own SMTP servers built in, it's only a few more (thousand?) lines of code to incrementally bypass that layer as well.
I've already seen a few years ago spam sites that return "yahoo.com" and "msn.com" in reverse DNS, but doing traceroutes reveals that they're actually in Korea or China, etc. So you can't fully rely on (spoofable) DNS info anyway.
If any of you remember the recent virii attacks where the attachment is a password protected zip file with the password in the body of the email, guess what: the evil ones kicked it up a notch once more.
Just yesterday, I saw a new form of this on cpunx: instead of a ZIP attachment, the new malware uses a RAR archive, and instead of the password being in clear text, it's inside an a randomly named attached .GIF file! They've not obscured it, so it's possible to add OCR to the anti-virus code, but it's now it's that much harder for the anti-virus to block.
Just as the virus authors evolve their code to adapt their offenses to the defenses of virus scanners, so will the spammers evolve their code to bypass spam filters, and we've already seen that spammers use virii/worms to spread their code...
Distributed computing is already here. Shame that it's biggest use is currently for evil. Ugh! :(
