Re: Saving Opportunistic Encryption
The simplest way to get half-safe opportunistic encryption is the Open Secret shared secret, or equivalently, draft-ietf-ipsec-internet-key-00.txt's shared secret. Everybody who wants to use it just adds it to their ipsec's list of known shared secrets, and uses it unless something better is available. It doesn't pretend to be MITM-proof, but it's a start. Doing the whole job correctly is much harder, which is why Gilmore's do-the-job-correctly-or-bust project didn't achieve the encrypting X% of the net by Christmas, where X1 and Christmas 2010. (This doesn't count the VPN market, which is what got the commercial support, even if many of the vendors used FreeS/WAN code, and it's a much easier problem even if ISAKMP/Oakley is a hard way to do something easy.) Forward DNS support is widely available, because anybody out there who doesn't want to run their own DNS can find a friendly DNS provider who'll sell them a subdomain they can use, e.g. joecypherpunk.FriendlyDnsProvider.net, and they can even do DNSSEC support (though obviously you can't walk the whole tree unless the roots are signed.) No ISP support needed. Reverse DNS support was pretty much a non-starter, because most ISPs don't give the user control over their reverse DNS space even if they bother to implement it at all. They're getting better, but you're still usually port123.box456.sfo.example.net, and forget getting DNSSEC support. You *could* make it work by building a separate Reverse DNS tree, like D.B.C.A.opportunistic-encryption.org, instead of hanging it off D.B.C.A.in-addr.arpa. You'd still have to get people to populate it, and make it scalable and DDOS-proof, but perhaps you could do it. Reverse DNS also has the problem that it's _not_ a 1:1 matching - a given IP address may have many virtual hosts on it, and therefore many domain names, and the domain names can be different for email vs. web vs. other protocols. So it can only work on a subset of the application space, even if you've got the control you need. Of course, forward DNS isn't really what you want, and reverse DNS mostly is, because there isn't a user interface to your IPSEC interface or routing tables, especially if the IPSEC box is some security gateway that the end user doesn't even have access to, so unless you want to invent some other protocol (not ISAKMP/Oakley/etc.) to seed the IPSEC Security Associations, all you've got to work with is the IP address of a destination, not a name. It's possible to play hackish workarounds that have the DNS server opportunistically fetch DNSSEC information, with the assumption that most people only talk to IP addresses that they got from DNS lookups, and it even has the performance advantage that you can do the fetch before you send out any TCP or UDP packets to the destination instead of stalling and risking timeouts. They're not hugely reliable, but they're a start, especially if you're going to fall back to Open Secret. They're mainly useful for machines that are doing their own IPSEC encryption, rather than using some IPSEC gateway/firewall box - otherwise you need to build dodgy configurations like running the DNS server on the IPSEC gateway and making sure DNS caching and IPSEC SA caching times are compatible. Also, working at this level means you're not just hacking the kernel, or the kernel plus some helper daemons - you're hacking BIND and its competitors, and suddenly you become responsible for maintaining them :-) Another approach is to invent a whole new protocol, separate from ISAKMP/Oakley/SKIP/etc., which does a handshake to fetch keys. It either has to hit a server at the destination's IP address, implying a need for firewall transparency and compatible address spaces (probably works better for transport mode than tunnel mode?), or else have some mechanism for finding a key+config server. Hugh Daniel suggested rehabilitating Finger as the end-system protocol (after all, we've long since patched the security bugs that the Morris worm used back in 1988). If you're building a non-end-to-end mechanism that uses IP addresses as its lookup, you're getting awfully close to reinventing Reverse DNS, or else building some other vast coordinated effort with half-vast goals. On the other hand, if you're patching half of ISAKMP/Oakley anyway, might as well patch Photuris, which is much smaller, lighter, and more correct. Bill Stewart Bill Stewart [EMAIL PROTECTED]
Re: Saving Opportunistic Encryption
On Tue, Mar 16, 2004 at 03:29:42PM +0800, Sandy Harris wrote: So, the apparent solution for me seems to be the approach that the SPAM blacklists used - publish information in a subspace of the forward DNS space instead of using the authoritative in-addr.arpa area. Worth discussing at least. 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. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgp0.pgp Description: PGP signature
Re: Saving Opportunistic Encryption
a couple nitpicks on otherwise interesting points... On Wed, Mar 17, 2004 at 09:02:17AM -0500, sunder wrote: 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..) There's a well-supported extension for that: http://enigmail.mozdev.org/ Actually, plans are in the works to make S/MIME an extension as well, so the two will soon be on equal footing. 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.) Out-of-band transmission of known-hosts entries has been standard operating procedure everywhere *I* have used ssh for the past 10 years. I thought everyone did that. regards, petard
Re: Saving Opportunistic Encryption
Eugen Leitl wrote: 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.
Re: Saving Opportunistic Encryption
On Wed, Mar 17, 2004 at 03:09:54PM +, petard wrote: There's a well-supported extension for that: http://enigmail.mozdev.org/ Actually, plans are in the works to make S/MIME an extension as well, so the two will soon be on equal footing. PGP/GPG has failed to protect the bulf of email for same reason as FreeS/WAN failed to protect the bulk of TCP/IP traffic. In comparison, opportunistic encryption via StartTLS has been a modest success, simply because it's so easy to deploy at MTA level (it would be a lot more successfull, if postfix/exim/qmail shipped with working StartTLS, or at least apt-get install yourMTAhere-tls would set up the certs and config properly). Purists would scoff that plaintext is default fallback, hence initial key setup easily disruptable, and MITM, and whatnot. However, if keys are cached, key changes and sudden reverts to plain for known hosts are logged, and key fingerprints for hosts crosscorellated, potential meddling becomes far easier to detect, and if only after the fact. Passive taps are easy, stealthy active traffic manipulation, on a large scale? Could as well look out for fecal precipitation from porcine aviation. Should it happen, upgrading to a web of trust is always an option. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgp0.pgp Description: PGP signature
Re: Saving Opportunistic Encryption
Hi, Sandy Harris wrote: Tarapia Tapioco wrote: A possible implementation looks like this: ... * Linux/KAME's IKE daemon racoon is patched to attempt retrieval of an RSA key from said DNS repository and generate appropriate security policies. Cleaner solution, but more work probably. Why would you use racoon? FreeS/WAN's Pluto is available, under GPL, already does OE, and works with 2.6 kernel IPsec (though I'm not certain if patches are needed for that). Wouldn't it be a better starting point? I have to take a look at this. Using racoon was my first idea because it seems to be the official Linux thing these days and is portable to the *BSDs, too. It's probably only the NIH syndrome at work. Also, using pluto suffers from the general FreeS/WAN problem of not allowing contributions from USAians. Anyway, thanks for the reminder - while the project is still at the half-assed idea tossing state, hacking FreeS/WAN should still be an option.
Re: Saving Opportunistic Encryption
Tarapia Tapioco wrote: We've recently seen FreeS/WAN die, not least due to the apparent practical failure of Opportunistic Encryption. The largest blocking point for deployment of OE always seemed to be the requirement for publishing one's key in the reverse DNS space. ... Yes. So, the apparent solution for me seems to be the approach that the SPAM blacklists used - publish information in a subspace of the forward DNS space instead of using the authoritative in-addr.arpa area. Worth discussing at least. A possible implementation looks like this: ... * Linux/KAME's IKE daemon racoon is patched to attempt retrieval of an RSA key from said DNS repository and generate appropriate security policies. Cleaner solution, but more work probably. Why would you use racoon? FreeS/WAN's Pluto is available, under GPL, already does OE, and works with 2.6 kernel IPsec (though I'm not certain if patches are needed for that). Wouldn't it be a better starting point?
Saving Opportunistic Encryption
We've recently seen FreeS/WAN die, not least due to the apparent practical failure of Opportunistic Encryption. The largest blocking point for deployment of OE always seemed to be the requirement for publishing one's key in the reverse DNS space. While most tech-savvy people are able to get access to forward domain space, reverse DNS space is still more heavily centralized and thus inaccessible to the general public. So, the apparent solution for me seems to be the approach that the SPAM blacklists used - publish information in a subspace of the forward DNS space instead of using the authoritative in-addr.arpa area. A possible implementation looks like this: * Keys are kept in TEXT record like with old-style OE, as a.b.c.d.opportunistic.net. The format of the text record contains * IKE authentication RSA key * optional secure owner identity, as in x.509 or PGP sig. * server signature. On the client side: * Keys are published via a TCP client. This ensures there's a minimal level of authentication that the submitter of a key is also in control of the IP address. Additionally, when an overwrite is attempted, we could attempt to obtain an ICMP echo response over the old SA and only accept the update when the old SA is dead. * J. Random libpcap application listens for traffic to different IP addresses and checks said DNS repository, manipulates security policy accordingly. This is just a dirty hack since it necessarily misses packets when the other node is first contacted, but it seems to be the easiest hack-me route, and it requires little to no platform integration, just * a libpcap implemenation * a command line interface to IPSEC security policies Check at least for Linux and Windows, probably *BSD too. * Linux/KAME's IKE daemon racoon is patched to attempt retrieval of an RSA key from said DNS repository and generate appropriate security policies. Cleaner solution, but more work probably. Obvious weaknesses: As the SPAM blacklists showed impressively, running an unpopular service on the net these days will get you DDoS'ed out of existence. Distributing the keys over the whole DNS space like FreeS/WAN OE did is the cleanest solution here, but I guess a cypherpunkly approach would also be good enough to get this thing started: Just use a configurable list of domains instead of just opportunistic.net, each with a different key, and publish these lists like those for remailers are currently published. Thoughts? (On a side note, minder.net has dropped a lot of my recent posts via remailers. Is there a better node for this?)
opportunistic encryption
Are there any reasons why current systems (whether OpenSource or not) don't ship with opportunistic IPsec out of the box? FreeS/WAN is really easy to set up, and such, but why having to do BIND juggling and extra installation steps. What are the reasons, crypto restrictions?
