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

[Paul Wouters]

On Mon, 19 Apr 2004, Marcus Blomenkamp wrote:

> then 'mea culpa' for not explicitly pointing out that i'd setup a CA 
> beforehand. I thought this was implicitly clear to anyone.

Then how am I going to trust you CA? And after yours, the million other CA's
out there? Doing X.509 means there has to be a validation path between the
computer's X.509 certificate upto some CA you trust.
[ note: later on I realised you are not talking about anonymous connections,
  but only to a set a machines within your sphere. then this is not an issue,
  since you trust your own CA by issuing PKCS12 certificates which include the
  CA certificate ]
 
> > 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.
> 
> Having a secure tunnel to a trusted dns server authoritative for my local zone 
> is crucial for trustable intra-zone OE'd traffic in my opinion.  

I was talking about OE in general, now I am getting the feeling that what you call
"OE" means "a lot of machines within your own network". 
sure, for your own zones you can run a trusted static ipsec tunnel to your DNS
server. It is when doing OE to the big bad world, that you run into trust issues,
even if you trust your own dns server.

> This is a nice piece of software for automanaging DDNS entries but it does not 
> fulfill my requirements as it is subject to many attacks all based on the 
> fact that communication to the dhcp server is untrusted.

The IETF DHC working group is working on secure DHCP. I'd recommend trusting
DHCP stuff for now, and wait until those standards mature. Building your own
authenticity scheme is going to be much more work, and likely not as thought
out as one produced by a room full of IETF people.
 
> 1. One can subvert or generate dns entries without pre-authentication. 
> Creation of a dumb key pair and guessing/sniffing of forward dns names is 
> sufficient. 

Yes, but doing that as MITM is a lot harder. Because once I've done that, and
you weren't the MITM, I have an ipsec tunnel to the other end, and you can no
longer be the MITM anymore. If I ask some untrusted dns query, worst case both
you and the valid server will reply. That is detectable. Also, if you'd
manage to later change my DNS OE key, say by setting your MAC address and IP
to my machine, and manage to update the OE key, what will you be able to get?
While the IPsec tunnel is up, you can at most get encrypted traffic you cannot
decrypt. And once a rekey has happened and you "took over" my IP/Mac/IPsec key,
that would mean you could only decrypt traffic in response to what you send 
yourself. Well, OE is not a private static tunnel. If you want to connect to
cnn.com and encrypt your data, there is no need to leach my key/ip for that.

In short, I am not sure what your sniffing would accomplish here. Eitehr you
prevent me from setting up an ipsec tunnel, in which case you cannot sniff
anything from me, since I am not sending anything. Or you are a very noisy
MITM which is very likely to get detected and killed.

> 2. One can personate as gateway system, to what extent depends on the exact 
> incarnation of the gateway system (dns server on or behind gateway etc).

You'd have to lure me on your wireless network segment, and then sure, you can
lure me. SSH style hostkey caching (running caching bind on client) will
partially negate that. It will only work for new connections I'll establish.
if I do run an IPsec tunnel to my DNS or extrusion from my home IP number,
then you're still only seeig data you can't decrypt. If you manage to setup
IPsec for cnn.com, and I never visited that before, then sure, you can leach
that from me.

> So an active attacker can replace any part of your infrastructure 
> transparently.

Far from transparently.

> Please keep in mind that my primar concern is not anonymous 
> traffic between anonymous machines on my network but trustable traffic 
> between machines i own. As far as i interpreted the specs and docs WaveSec 
> does not provide that.

Right. Then just rollout one CA and sign all the hostkeys, and setup conns that
allow any cert to connect to any cert, signed by the same CA, and get it over
with. Then ensure that all your machines regularly fetch revoked certificates,
either using files, ldap or whatever other ways you want. And hope you can
detect quickly when some laptop got infected and had its certificate stolen
and re-used.
 
> > [... windows specific]
> > Also, certificates just won't scale.
> 
> Then I'd say OE in its current form does not even walk uprightly ;)

It is walking upright firmly, there are just not many people walking, they're
still crawling with Microsoft, using the ldap stick to try and stretch :)

> > [...]
> > 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?
> 
> Trampling on my impreciseness does not gain anybody anything :(

I wasn't trampling. I am seriously trying to see what you are trying to do, and
think where the problems might be. I'd love for you to come up with something
better then OE.
 
> I do not see either how certificates are more appropriate for anonymous 
> connections. But i think most valuable traffic, und thus in most need for 
> protection, is generated between participants who are not anonymous.

Okay. As I wrote above, we had some miscommunication about "OE". It is now
clear to me that you are trying to secure a limited about of hosts that are
part of your communication sphere. In that case, just use a CA and X.509 certs.
There is no need to put anything else in DNS, since each host will be equiped
with:
- The CA to verify all host certificates (including its own)
- Its host certificate
- IKE with X.509 to get the peer's certificate, which can be verified with the 
  local CA cert.
- A certificate revocation list to deny revoked certificates signed by the local CA.
  (I am not sure if Windows clients can actually also use a CRL)
 
> In dynamic scenarios (such as drafted above) raw rsasigs are worse manageable 
> because a key infrastructure has to be duplicated just to ensure proper 
> authentication of dynamic updates.

I agree. The only thing you need to rollout in your case is a proper CA.
 
> It seems to me that adapting xSWAN to dynamic scenarious is often disregarded 
> in design and documentation. On reading docs often enough one finds 
> statements analog to: "We do not know how to handle this dynamically so you 
> better keep your setup static". However reality isn't always that simple.

Most of the dynamicness that you are looking for is already there. The areas
where people run into troubles, such as "dhcp over ipsec" or "get an IP address
from the LAN range" are known problems, and will be part of the new version of
IKE (IKEv2)

> Currently i am developing something which one could call poor-mans OE. 

What is wrong with using a CA and X.509 certificates in your case?

> However pluto status output is not easy to follow then. Additionally I have 
> concerns against having that many explicit routes from a performance point of 
> view. Or can this be ignored generally?

Unless you are hitting a few new connections per second, you can ignore it. There
are known race conditions in the /proc code, but so far those are only triggered
by busy hosts running full OE, eg DNS and Webservers that try to initiate OE for
each incoming client.

Paul