Re: Re: [Users] Making FreeS/WAN harder to use, INTENTIONALLY.

On Sun, 2 Mar 2003, Sam Sgro wrote:

> It has caveats - really, it's only appropriate to keep policy groups off if we
> don't require it to implement security policy (ie, CIDRs in private or clear) 
> - and there may be other issues. But it's an intelligent use of OE, as opposed 
> to blindly enabling the technology, regardless of the state of DNS.
 
I have to agree here with Sam. AFAIK, the goal of the Freeswan Project
was to give users a "drop in" for doing "as much crypto as possible"
aimed at not only sysadmin's, but endusers as well. Especially endusers!

A few years ago, we could simply differentiate the enduser from the
sysadmin by seeing whether or not there was a local LAN connected to a
second interface connecting to the net. these days, endusers have that
setup as well, mostly using NAT, but soon (esp in ipv6 world) with more
and more real IP. Therefor we have to deal with pseudo-administrators,
endusers who connect a private network without the neccessary skills
we would consider minimum.

If we want them to try and do as much crypto without thinking, we have
to make sure that OE works by just adding the software. After all, this
was the goal for the "version 2" of the ipsec.conf file. If you do not
configure anything, we try to do crypto for you. I think we should keep
that goal, and ensure that the default configuration doesn't break things,
even if it would educte the user about security and crypto. 

As an similar case, take sendmail. First it could only do plaintext mail.
Then it could do TLS, but you had to set it up. Now it does TLS without
needing configuration, since it deems 'better crypto to unknown people,
then no crypto to unknown people". This is very much the Freeswan "Me
Tarzan, you Jane" concept. We should stick to it.

IMHO, the shipping defaults we should implement is "private or clear" for
undetermined conns (Opportunistic) and "private and block" for user defined
connections.

Paul