<p>This post offer more information on a recent discussion we had here of opportunist encryption</p>
<p>Thought it may be interesting read for the group</p>
<p>William </p>
<div class="gmail_quote">---------- Forwarded message ----------<br>From: "Paul Wouters" <<a href="mailto:paul-tjj5GM33nZ3tb89JCkODlQ@public.gmane.org">paul@cypherpunks.ca</a>><br>Date: Sep 11, 2013 1:07 PM<br>Subject: [Cryptography] History and implementation status of Opportunistic Encryption for IPsec<br>
To: <<a href="mailto:cryptography-of7zbby7T3pWk0Htik3J/w@public.gmane.org">cryptography@metzdowd.com</a>><br>Cc: "D. Hugh Redelmeier" <<a href="mailto:hugh-pmF8o41NoarQT0dZR+AlfA@public.gmane.org">hugh-pmF8o41NoarQT0dZR+AlfA@public.gmane.org</a>>, "John Gilmore" <<a href="mailto:gnu-r+Tv4kcVSiE@public.gmane.org">gnu-r+Tv4kcVSiE@public.gmane.org</a>><br>
<br type="attribution"><br>
History and implementation status of Opportunistic Encryption for IPsec<br>
<br>
<br>
NOTE: On September 28, there is be a memorial service in Ann Arbour<br>
for Hugh Daniel, manager of the old IPsec FreeS/WAN Project.<br>
Various crypto people will attend, including a bunch of us<br>
from freeswan. Hugh would have loved nothing better than his<br>
memorial service being used as a focal point to talk about<br>
"new OE", so that's what we will do on Saturday and Sunday.<br>
If you are interested in attending, feel free to contact me.<br>
<br>
<br>
In light of the NSA achievements, a few people asked about the FreeS/WAN<br>
IPsec OE efforts and whatever happened to it.<br>
<br>
The short answer is, we failed and got distracted. The long answer follows<br>
below. At the end I will talk about the current plans that have lingered in<br>
the last two years to revive this initiative. Below I will use the word "we" a<br>
lot. Its meaning changes based on the context as various communities touched,<br>
merged, intersected and drifted apart.<br>
<br>
OE in a nutshell<br>
<br>
For those not familiar with IPsec OE as per FreeS/WAN implementation. When<br>
activated, a host would install a blocking policy for <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>. Every<br>
packet to an IP address would trigger the kernel to hold the packet and<br>
signal the IKE daemon to go find an IPsec policy for that destination. If<br>
found, the tunnel would be build, and an IPsec tunnel to the remote IP<br>
would be established, and packets would flow. If no policy was found,<br>
a "pass" hole was poked so packets would go out unencrypted. Public<br>
keys for IP addresses were looked up in the reverse DNS by the IKE<br>
daemon based on the destination address. To help with roaming clients<br>
(roadwarriors), initiators could store their public key in their FQDN,<br>
and convey their FQDN as ID when performing IKE so the remote peer could<br>
look up their public key in the forward DNS. This came at the price of<br>
two dynamic clients not being able to do OE to each other. (turns out<br>
they couldn't anyway, because of NAT)<br>
<br>
<br>
What were the reasons for failing to encrypt the internet with OE IPsec<br>
(in no particular order)<br>
<br>
1) Fragmentation of IPsec kernel stacks<br>
<br>
In part due to the early history of FreeS/WAN combined with the export<br>
restrictions at the time. Instead of spending more time on IKE and key<br>
management for large scale enduser IPsec, we ended up wasting a lot of<br>
time fixing the FreeS/WAN KLIPS IPsec stack module for each Linux release.<br>
Another IPsec stack, which we dubbed XFRM/NETKEY appeared around 2.6.9 and<br>
was backported to 2.4.x. It was terribly incomplete and severely broken.<br>
With KLIPS not being within the kernel tree, it was never taken into<br>
account. XFRM/NETKEY remained totally unsuitable for OE for a decade.<br>
XFRM/NETKEY now has almost all functionality needed - I found out today<br>
it shoudl finally have first+last packet caching for dynamic tunnels,<br>
which are essential for OE. Since the application's first packet triggered<br>
the IKE mechanism, the application would start retransmitting before IKE<br>
was completed. Even when the tunnel finally came up, the application<br>
was usually still waiting on that TCP retransmit. David McCullough and<br>
I still spend a lot of time fixing up KLIPS to work with the current<br>
Linux kernel. Look at ipsec_kversion.h just to see what a nightmare<br>
it has been to support Linux 2.0 to 2.6 (libreswan removed support for<br>
anything lower then recent 2.4.x kernels)<br>
<br>
Linux IPsec Crypto hardware acceleration in practise is only possible<br>
with KLIPS + OCF, as the mainstraim async crypto is lacking in hardware<br>
driver support. If you want to build OE into people's router/modem/setup<br>
box, this is important, though admittingly less so as time has moved on<br>
and even embedded hardware and phones are multicore or have special crypto<br>
CPU instructions.<br>
<br>
An effort to make the kernel the sole provider of crypto algorithms that<br>
everyone could use also failed, and the idea was abandoned when CPU crypto<br>
instructions appeared directly accessable from userland.<br>
<br>
2) US citizens could not contribute code or patches to FreeS/WAN<br>
<br>
This was John Gilmore's policy to ensure the software remained free for<br>
US citizens. If no US citizen touched the code, it would be immune to any<br>
presidential National Security Letter. I believe this was actually the<br>
main reason for KLIPS not going in mainstream kernel, although personal<br>
egos of kernel people seemed to have played a role here as well. Freeswan<br>
people really tried had in 2000/2001 to hook KLIPS into the kernel<br>
just the way the kernel people wanted. (Ironically, the XFRM/NETKEY<br>
hook so bad, it even confuses tcpdump and with it every sysadmin trying<br>
to see whether or not their traffic is encrypted) I still don't fully<br>
understand why it was never merged, as the code was GPL, and it should<br>
have just been merged in, even against John's wishes. Someone would<br>
have stepped in as maintainer - after all the initial brunt of the work<br>
had been done and we had a functional IPsec stack.<br>
<br>
In the summer of 2003, I talked to John and together we agreed it was<br>
time to fork. Openswan was born to clearly indicate US coders could<br>
contribute. However, at that point the (then crappy) XFRM/NETKEY IPsec<br>
stack was there to prevent OE from working due to the missing first+last<br>
packet caching. The FreeS/WAN Project ended and Openswan continued. At<br>
first in good pace, but that later slowed down and OE was no longer its<br>
focal point. (Due to legal reasons, I cannot go into details regarding<br>
the openswan history)<br>
<br>
3) Not using DNS without DNSSEC<br>
<br>
There were various issues that caused DNSSEC to get massively delayed.<br>
We needed DNSSEC to secure our DNS based distributed public key<br>
platform. Although it would have worked fine to use DNS against passive<br>
attackers (NSA trawling), we believed it was principly wrong to trust<br>
cryptographic material that was untrusted and vulnerable against active<br>
attacks. So while the developers encouraged people to put keys in DNS<br>
even without security, no one else picked it up. It sucks to need to say<br>
'we told you so'. But we should have really not waited on DNSSEC.<br>
<br>
3) Dealing with the DNS working groups at IETF<br>
<br>
The DNS community is one of the most pedantic group of people I know. They<br>
are very smart, often right, and had been known to be extremely defense<br>
of their DNS turf. (Note that things have improved considerably and if you<br>
think this is still an issue, I'm happy to try and help)<br>
<br>
IETF was divided about the convergence of the "security of the DNS"<br>
and the "DNS as PKI" despite that this had always been a goal of DNSSEC<br>
for a large group of people within the IETF. The FreeS/WAN people were<br>
driving DNSSEC not so much for DNS as for the key distribution. After all,<br>
you can detect DNS forging if you know your public keys.<br>
<br>
When we had the KEY/SIG records ready to go, it was decreed that it<br>
could only be used for the DNS itself. Applications could not use this<br>
KEY record. To make that distinction more clear, on the next change in<br>
the draft protocol, KEY was obsoleted and DNSKEY introduced. So IPsec<br>
keys were relegated back to TXT, since at the time we had no Generic<br>
Record format (RFC 3597) support, so waiting for any new RRtype to get<br>
any deployment to become usuable would take years. Almost everyone was on<br>
bind4 and never upgraded left us with no other choice but the TXT. Even<br>
though we wrote the OE and IPSECKEY RFCs, OE's only deployments were<br>
done using TXT records.<br>
<br>
4) DNSSEC was delayed by a decade<br>
<br>
DNSSEC deployment was slowly gaining traction, but I think we really<br>
needed the Kaminsky bug to get that extra push for DNSSEC outside the geeks<br>
of the IETF. The US government mandate for DNSSEC in .GOV helped as well. But by this time, OE was mostly forgotten.<br>
<br>
djb repeatedly tried to peddle his own warez. While not at all realistic,<br>
it always gained a lot of hype and media attention and probably did<br>
cause delays of DNSSEC deployment.<br>
<br>
Kaminsky himself was shooting down DNSSEC too. I personally heckled<br>
him at various Black Hat's and ICANN conferences until we finally sat<br>
down for a couple of hours to talk about DNSSEC's history and design<br>
goals. I'll claim my 15 minutes of fame for having converted him. It<br>
helped having Kaminsky say that although he didn't like the complexity,<br>
he couldn't see anything better. DNSSEC was needed for everyone.<br>
<br>
DNSSEC was gaining traction. Then we ran into a bunch of DNSSEC<br>
deployment issues. We had the delays due to NSEC vs NSEC3 with OPTIN,<br>
and then on top of that in 2008 when the first big ISP in Sweden<br>
turned on DNSSEC in their resolvers all that traction was blown away.<br>
<br>
Most consumer routers ran DNS proxies that implemented DNS as "known<br>
bitstreams" instead of implemeting the actual DNS protocol. The DNSSEC<br>
OK bit caused thousands of routers to drop DNSSEC packets as "invalid<br>
DNS". The only realistic solution: Turn it off and wait two years for<br>
those routers to get obsoleted by faster wifi standards and talk to those<br>
vendors so they would not repeat their mistake with their next generation<br>
of routers.<br>
<br>
We now have the IPSECKEY record format (though RFC 4025 is not useful,<br>
see below) and RFC 3597 for the generic DNS record deployed on all DNS<br>
servers. And we're on our way to have DNSSEC on every end node (see<br>
also draft-wouters-edns-tcp-chain-<u></u>query-00 I just submitted to the IETF)<br>
<br>
We have a mostly clean working UDP/TCP port 53 transport for DNSSEC<br>
on most networks (in part thanks to Google DNS). Although our hotspot<br>
handling is still a little rough, with dnssec-trigger the only tool<br>
to hack configurable DNSSEC support into the OS for our coffee shop<br>
visits when we need to rely on forged DNS.<br>
<br>
4) When you're NAT on the net, you're NOT on the net.<br>
<br>
Opportunistic Encryption relied on a clear peer to peer connection. But<br>
we managed to degrade the internet into servers and clients. NAT was the<br>
biggest problem, and with CGN around the corner, it's not something that<br>
is going away despite IPv6 offering enough IPs for everyone. In fact,<br>
for our "new OE", this is the biggest hurdle to overcome. When Alice<br>
cannot talk to Bob because she cannot reach him due to a (carrier grade)<br>
NAT, we are stuck wildly poking holes and hoping packets flow.<br>
<br>
5) The reverse DNS tree is dead Jim<br>
<br>
OE depended on the reverse tree as a security mechanism that someone<br>
who was claiming a public key for a specific IP range was actually the<br>
legitimate owner of that IP space. It was the security method for RFC-4025.<br>
<br>
But unless you are running in a datacenter, you do not have access to<br>
the reverse DNS. It is useless as key distribtion method. On top of that,<br>
large IPv6 deployments don't even care any more to run any authoritative<br>
DNS for their reverse.<br>
<br>
6) BTNS<br>
<br>
The IETF tried to revive this OE with the Better Then Nothing Security<br>
("BTNS") working group. Contrary to the name, they also fell into the<br>
"perfect is the enemy of good" trap and most discussion seemed to go into<br>
"channel binding" to upgrade anonymous IPsec to some kind of authenticated<br>
IPsec - at least by the time I became aware of them. In other words,<br>
the most important problem of key distribution was left outside the scope<br>
and no one actually seemed to have implemented anything. Though I have to<br>
admit, I'm behind on reading the VPN auto-discovery drafts. It is just<br>
very discouraging to still be reading problem statement drafts. More<br>
over, I don't think we should setup IPsec tunnels based on packets<br>
hitting the kernel. We have better ways now that we can leverage DNSSEC.<br>
<br>
7) We were all complacent<br>
<br>
The only interest for IPsec was for corporate VPNs. During the<br>
above listed problem periods, OE people gave up. Some walked away<br>
from IETF. While everyone gained an always-on portable IP device,<br>
their crypto capabilities were practically non-existent. My current<br>
iphone 5 can connect to a corporate VPN, but trying to make it _just_<br>
send out encrypted packets is impossible. Some trickery can be used to<br>
cause almost any packet to setup the VPN, but while that's going on it<br>
is still leaking like a sieve. VPN is seen by phone vendors as a method<br>
to gain some enterprise users, not as the tool to protect the consumer.<br>
The Apple VPN client is a 10+ year old patched version of racoon. The<br>
only vendor that took VPNs seriously was RIM and we punished them by not<br>
buying their products, because we had other priorities like FourSquare,<br>
Facebook and Twitter.<br>
<br>
We can only hope that those PRISM players are now put under economic<br>
pressure by frightened consumers to fix this. But as long as VPNs and<br>
DNSSEC is slow and error-prone, it is better for them not to go there.<br>
<br>
<br>
<br>
The New Opportunistic Encryption<br>
<br>
I've been brainstorming with various people on how to put IPsec OE back on<br>
the table. I've discussed this with a bunch of people around me, including<br>
the late Hugh Daniel, John Gilmore and Hugh Redelmeier of freeswan.<br>
<br>
The packet capturing <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> policy is not a good method because<br>
we cannot make any decision on where to find a public key for an IP<br>
address. The reverse is unusable, and IP addresses change often. We used<br>
it because we had nothing better. But now we do. Since every (secure)<br>
platform now runs DNSSEC on the end node, we can use this as our decision<br>
making point. Imagine my phone running a DNSSEC resolver (say unbound)<br>
and an IKE daemon (say libreswan). The DNS server has access to the set<br>
of DNS name and matching IP address. It can lookup the key in the forward<br>
DNS zone, and hand over the public key, dns name and IP address to the IKE<br>
daemon!<br>
<br>
1) User tells browser to go to <a href="http://www.cypherpunks.ca" target="_blank">www.cypherpunks.ca</a><br>
2) browser does a lookup for the A/AAAA record of <a href="http://www.cypherpunks.ca" target="_blank">www.cypherpunks.ca</a><br>
3) DNSSEC resolver performs the lookup/validation for the A/AAAA record of<br>
<a href="http://www.cypherpunks.ca" target="_blank">www.cypherpunks.ca</a> and additionally looks up the IPSECKEY record of<br>
<a href="http://www.cypherpunks.ca" target="_blank">www.cypherpunks.ca</a>.<br>
4a) The resolver will wait with returning the A/AAAA record to the browser<br>
until it knows if the IPSECKEY record exists or not. If not, it releases<br>
the A/AAA answer to the application. Packets flow in the clear.<br>
4b) The resolver finds an IPSECKEY record. It sends the pubic key, the FQDN<br>
and the IP address(es) to the IKE daemon and waits for a response.<br>
Meanwhile it does _not_ release the A/AAAA record to the application.<br>
5) The IKE daemon sets up the IPsec tunnel. We haven't reached agreement<br>
yet over how this should be done. There are two choices:<br>
<br>
a) The client uses an "@anonymous" ID for itself along with sending its<br>
public key inline with IKE. The client is responsible for ensuring there is<br>
no MITM attack, as it knows the server's public key (from DNSSEC). The<br>
responding server will just use any key it received inline if it was received<br>
for the "@anonymous" ID.<br>
<br>
b) The initiator (aka client) uses its own FQDN-based ID. It has<br>
preconfigured its DNS so that an IPSECKEY record exists for its FQDN<br>
(protected by DNSSEC). The key is not send inline with IKE. Instead,<br>
when the responder (aka server) sees the non-anonymous ID, it will perform<br>
a DNSSEC secured lookup to obtain the IPSECKEY out of band. Both parties<br>
confirm there is no MITM.<br>
<br>
The advantage of a) is that it leaks less user information and makes tracking<br>
users harder. The client can regularly generate another anonymous keypair.<br>
The disadvantage of a) is that it turns peers into clients and servers. And<br>
two clients cannot initiate OE to each other.<br>
<br>
6) The tunnel is established and the IKE daemon notifies the local DNSSEC server<br>
that had instructed it to setup the IPsec tunnel.<br>
<br>
7) The resolver releases the IP address to the application.<br>
<br>
8) The applications starts sending packets and the IPsec policy encrypts them al.<br>
<br>
I'm personally in favour of the @anonymous solution. But there is no reason why support<br>
for both could not be implemented.<br>
<br>
What are some of the obstacles and work to do:<br>
<br>
1) writing the unbound plugin 2) writing the support for @anonymous for the server-side.<br>
This includes raw keys for IKEv2<br>
(<a href="http://tools.ietf.org/html/draft-ietf-ipsecme-oob-pubkey-00" target="_blank">http://tools.ietf.org/html/<u></u>draft-ietf-ipsecme-oob-pubkey-<u></u>00</a>)<br>
3) With NAT, the client suggests an inner-IP. This could be abused or clash,<br>
We need to 'contain' each connection, possibly using generated ipv6<br>
addresses 4) We cannot use the "gateway" field of RFC-4025, or people<br>
could trick a server into giving a client all communication to a certain<br>
IP address that does not belong to them<br>
5) anonymous connections should generate throw-away keys to remain anonymous<br>
6) implement draft-wouters-edns-tcp-chain or else latency/RTTs will prevent<br>
real-life deployment of DNSSEC validated IPSECKEYs on mobile devices.<br>
7) This allows no upgrading from anonymous to mutually authenticated, but IKE<br>
policies can be added to the server/client that would match on different IDs<br>
(eg X.509) that work independantly of OE without introducing complicated<br>
channel binding promotion code. Other IKEv2 extensions could possible be<br>
applied to facilitate promitions.<br>
<br>
I'm sure more implementation issues will show up once we get this going,<br>
but there are no real fundamental issues why we cannot deploy this in<br>
a couple of months of time. My plan is to get libreswan to support this<br>
version of OE. Additionally, once we use draft-wouters-edns-tcp-chain,<br>
it becomes cheap to do these lookups through the tor network. If the<br>
tor exit nodes then also feed each other with DNSSEC cache material,<br>
it should make tracing individual clients even harder.<br>
<br>
(anyone willing to assist, especially with coding, do contact me)<br>
<br>
Paul<br>
______________________________<u></u>_________________<br>
The cryptography mailing list<br>
<a href="mailto:cryptography-of7zbby7T3pWk0Htik3J/w@public.gmane.org" target="_blank">cryptography@metzdowd.com</a><br>
<a href="http://www.metzdowd.com/mailman/listinfo/cryptography" target="_blank">http://www.metzdowd.com/<u></u>mailman/listinfo/cryptography</a><br>
</div>