Re: Re: Firewalls breaking stuff: [Was re: fwtk]

["Charles W. Swiger" <chuck () codefab com>]

On Saturday, July 20, 2002, at 11:01  AM, Paul D. Robertson wrote:
> On Fri, 19 Jul 2002, Charles Swiger wrote:
> > Encryption isn't a magic bullet.  If you can not exchange mail with the
> > outside world at all, of course you don't run an MTA, any more than you
> > would run any other service that wasn't necessary.
>
> You're going from "external mail at all" to "Relay and read mail
> externally"- which are two very distinct things with signifcantly
> different risk profiles.

I agree that the two are very distinct things.  Perhaps we're simply 
disagreeing about how common the requirement to provide remote mail access 
is...?

> > However, I'm not "suddenly" providing remote access; the requirement for
> > employees to be able to remotely access email is quite a bit more common
> > at most organizations than the reverse.  Given that as a functional
> > requirement for a "working" network, I'd prefer to provide these services
> > in a way that's more secure rather than less secure.
>
> Actually, remote mail only isn't all that common,

We all draw from past experiences; almost every company I've worked with 
has wanted remote mail access (90% plus), but only 25% or so wanted to go 
to a VPN or equivalent, although the latter is becoming more common 
nowadays.

>  people don't tend to go for service level encryption versus VPN access.  
> Remote access brings with it a number of issues that aren't there with 
> local access, and there's an associated cost and risk with doing it.  For 
> instance now either your
> mail relay/reader box has to hook into the current authentication scheme,
>  or
> have it's own.  If it has its own, then it's got to be maintained with
> hires and fires.

It's true that the mail relay/reader box (or boxes; they don't have to be 
the same) has to be able to authenticate users, and you have to maintain 
the list as people join and leave.

This would be true of any mail system (even one used internally), however.

> Now people will send and receive mail on machines that
> the company doesn't own which may be trojaned...

Why wouldn't the company own their machines?

> Also, the ability to relay mail is normally predicated by the ability to
> read it, and if we want a cespool of insecurity, we should go to mail
> client protocols.  That's a dependency chain that's best served with a
> generic secure tunnel if it must be done at all, which negates the need
> for a service level tunnel.

If you want to provide complete internal access from a fixed remote 
location, then a VPN is a great solution.  If you only want to provide 
email access from random rather than predetermined remote locations, VPNs 
seem less well suited.

> > For people that use reusable passwords rather than S/Key or other 
> > one-time
> > password systems, are you claiming that SSL-based encryption is less
> > secure than plain text?
>
> No, but I'm claiming that there's not much of an organizational gain to
> providing service level encryption versus IP level generic
> encryption if you must provide remote access.

Okay.

> > Would plain text be better under any circumstances?  (If so, why?)
>
> Plain text is better under circumstances where you're doing things with
> the data that don't have the ability to get the key, where local legal
> requirements make encryption prohibitive, where you want someone to access
> the data,

These requirements you mention are orthogonal to the issue of whether 
encrypted passwords are better than plain text passwords from the 
standpoint of security.

> where the transport mechanism really *needs* the efficiency of
> data compression (do a lot of satcom and you'll understand that point
> painfully.)

A network connection with a large bandwidth times propogation delay 
cross-product has characteristics quite different from a LAN, sure.

> > FEATURE(`nocanonify') and relay email to your ISP's mailserver rather 
> > than
> > doing DNS lookups locally?
>
> That would require all mail to be relayed, kind of taking away the value
> of the TLS unless you're in an organization that only has one or two
> domains- if the intent is for employees to be able to mail to other
> employees, the privacy is probably as important as the authentication, no?

Why would you do that?  Of course you wouldn't relay internal mail outside!

However, all Internet-bound email is going to be relayed outside in any 
event, thus your mailserver(s) can avoid performing DNS lookups by handing 
the mail to the ISP's mailserver(s), instead.

-Chuck

       Chuck Swiger | chuck () codefab com | All your packets are belong to 
us.
       
-------------+-------------------+-----------------------------------
       "The human race's favorite method for being in control of the facts
        is to ignore them."  -Celia Green

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards