[Openswan dev] Opportunistic Encryption thought over - x509 certificates vs DNS TXT records

[Paul Wouters]

On Thu, 15 Apr 2004, Marcus Blomenkamp wrote:

> Obstacles observed on deploying DNS-based OE:
> 
> Retrieving plain RSA signatures from DNS allow us to generate an ISAKMP SA, 
> however we still no not know who we are communicating with. In a usual setup 
> we cannot trust the DNS server thus opening up the possibility of spoofing 
> attacks.

OE without any third party integrity check is meant to help against passive
sniffers, not against active attacks againt you, wether it be dns or something
else.
Whatever the technology used, if A and B want to talk encrypted, and they never
met before, you MUST have a third party to help you autenticate some (or more)
trust. For OE, that is DNS (and preferably DNSSEC). One could also use X.509
certificates, but it isn't much better. Anyone can get a certificate your Windows
machine will trust, it's about what? $25 ?

> If we want to trust the DNS server there are two options - IPSec and DNSSEC. 

IPsec doesnt really help you secure a nameserver you don't control. And 
settingup an IPsec tunnel to a dns server YOU trust, still hardly means
anything if that trusted dns server then has to query completely untrusted
dns servers anyway.

> DNSSEC on the other hand - i must admit that i've not digged into that deeply 
> - is nowhere better. 

It is better, in that it can protect zones YOU control. Sure, it hasn't been widely
deployed yet (The protocol is going to the RFC Editor next IETF), but you are
mixing "deployment" with "technical merrits" here.

> Additionally one has to implant an DNSSEC resolver library into his system. 
> To my knowledge glibc does not provide that. Best wishes to anyone crossing 
> this software minefield.

You will need to run a caching resolving BIND on your client (NSD doesnt recurse) 

> Joe has a wireless LAN with several machines running GNU/Linux. Naturally he 
> wants them to communicate privately. However he has the IP addresses assigned 
> dynamically by a DHCP server. A static map of IP==RSASIG as it might be 
> configured on his trusted DNS server will bite on that scenario. To work 
> around this he configures his DNS server to accept dynamic changes aka DDNS. 
> To prevent one (possibly compromised) machine from subverting all DNS entries 
> Joe has to generate a separate shared-secret for each machine==DNS-entry 
> item. So in addition to his previously created RSA key pairs he creates yet 
> another key infrastructure. The resulting phenomenon is redundancy and 
> usually considered bad design.

This makes no sense whatsoever. I am not even understanding what you are trying
to say here.
If you have a wireless network, and you want machines in that network to talk securely,
the only thing you need to do is create an CA, which creates host certificates, and
distribute an ipsec.conf from one server. This is exactly what we have done with "WaveSEC
for Windows", a Linux based AP that also serves you an X.509 host certificate, and some
tools to setup the VPN with a double click. Then all traffic goes via IPsec to the AP,
and then further into the world unencrypted.
 
> Did i miss anything which might simplify the utilization of DNS records for 
> Opportunistic Encryption? 

Yes, on the full wavesec mode, DHCP actually injects the appropriate DNS records in
the reverse of the IP range (even private space ip if you run dns for it) without
the user needing to do anything. Crypto will just happen.

> The approach more suitable is already implemented in - sorry to all OS zealots 
> - Windows2k. Machines are simply equipped with their respective certs and 
> cacerts and can automagically build up an ISAKMP-SA to another machine if 
> both have their certs signed by the same CA. No dependencies on additional 
> infrastructure. It just plain works. Did i overlook something vital and thus 
> made a total fool of myself? If so then i apologize.

You did. First of all, CA certs that are trusted by comercial entities are expensive.
Too expensive for the common guy, but too cheap for a thief who wants to grab your
data. 

Another obvious problem is which CA do you trust? If you trust Verisign, you just
trusted half the world. So you will need to generate your own CA for trust, but no one
will trust that out of the box on their Windows machine.

Apart from that, Microsoft and Verisign are not interested in you achieving this. They
want you to use ActiveDirectory on an expensive Windows server and lots of signed/paid
certificates.

Also, certificates just won't scale. 

Perfect security is under YOUR control only, so you can't use Microsoft or Versign for
the bulk of the work. So it won't scale to make all IP traffic encrypted.
DNS records DO scale very well, but you don't have full control. Trust is spread out over
various people who control various parts of the dns. It isn't perfect, but it can spread
really fast fairly easily. (esp if we port Openswan to windows :)

> I haven't looked at OpenSWAN's code that much until now, but is this doable 
> with the current design of pluto and kernel? Could one reuse the same hooks 
> currently used by OE to trigger signature retrieval from DNS?

I am not sure what you are trying here. If you would fetch a certificate from DNS, how
can you trust that? You will need to check the cert's CA. Then can you trust that? If
so, how? By Verisign? By microsoft pre-install? By a virus?

I can inject any certificate and any CA into your windows registry without you needing
to give any password. Do you really want trust something based on a CA? In my opinion,
no, you cannot trust any CA or cert anymore then you can trust a DNS(sec) record. So
in that sense, the overhead of signing certs is not neccessary.
The only reason to use some sort of certficate system is the restrictions imposed by
Microsoft's IPsec implementation. Certs are the only way to avoid using something very
expensive.

> I do have real interest in bringing this to production quality. Am i the only 
> one longing for this feature? I don't think i could stem this up all by 
> myself.

i am curious how you think to use certificates for "anonymous encrypted" connections.
you have similar problems as with OE. If we can do this somehow with certificates, I'm
all for it, since it would get us "OE" for the Windows platform. But I don't currently
see how this can be done. 

If you can somehow prsent a flowchart of events that lead from two machines who never
met before, to two machines using IPsec, based on certificates, I would be very interested
in that, and I'm sure we could help implementing something as well.

Paul