Re: [Openvpn-users] Features that should be in OpenVPN or VTun

[James Y. <ji...@nt...>]

>   - public-key encryption based on KEY records in DNS
>
> Hit the DNS, get the key, now you don't have to store it any place, and
you
> can discover it.  If you can think of an easier way to discover a KEY,
then
> I'm all ears.

Well the fundamental problem with key management is that nobody has figured
out a way for two parties on the internet to prove their identity to each
other without the use of either a centralized authority (i.e. verisign,
thawte, etc.), a web of trust (i.e. PGP), or the model of a small-scale
certificate authority such as one that authenticates the certificates of all
members of a small business so they can work from home over a secure link.

But the combination of TLS and RSA certificates goes a long way in creating
a useful public key infrastructure (PKI) where people can prove their
identities to each other without the use of pre-shared secrets.  OpenVPN, by
its reliance on TLS, also supports a full PKI.  OpenVPN also supports
pre-shared keys as well, so you have a choice on whether or not you want to
use TLS.

Now I'm not too familiar with KEY records but I took a look at RFC 2065 and
I don't see any reason why it couldn't be done.  After all, you're just
distributing public keys which are designed for public distribution.  If
anybody tries to spoof them, the certificate authority test will fail.  In
order to spoof, an attacker would need access to the private key which was
used to sign the public key certificate.

That's one of the reasons why Versign is riding high and the CEO of Thawte
is training to be the world's second space tourist, paying the $20 million
fare to the Russians using pocket change he received for selling Thawte (and
all this while the .coms were falling like flies).  All that money comes
from the need of millions of secure web site operators to be able to present
a public certificate that proves their identity and cannot be forged (unless
you figure out how to crack some pretty intractable problems in number
theory and factoring).

Getting back to RFC 2065, given that OpenVPN offloads key management to the
OpenSSL library, it's really up to OpenSSL whether or not they will support
DNS-based key management.  This is in keeping with OpenVPNs modular
philosophy (let TUN/TAP do the tunneling, let OpenVPN do the security).  If
I were to implement it, I would do it as a patch to OpenSSL.

>   - on-demand connections.
>
> Keep the IFaces up all the time.  Route data to it, and connect the actual
> TUNs with the high-water mark is reached.

OpenVPN supports persistent TUN/TAP devices if you want to keep the
interfaces up all the time.  See the --mktun option.

>
>   - Dynamic on-demand default tunnels using discovered Keys
>
> Send all data out via the TUN, except data that's already encapsulated.
If
> a tunnel cannot be established, then send it in the clear.  Otherwise, set
> up tunnel and shoot data.

Sending in the clear is dangerous for any VPN package, because people might
mistakenly use it without realizing it.  Because of this, OpenVPN requires
you to explicitly disable either encryption or authentication if you don't
want it, and then it warns you in big capital letters if that is what you
really want.

Jim