On Mon, Dec 24, 2001 at 02:45:16AM +0100, Lukasz Grochal wrote:
[both to me, and to the list, as I explicitly asked him not to]
> Matthew Byng-Maddick <exim@???> writes:
> > After all, the encryption gets you precisely nowhere and is more
> > expensive in terms of resources.
> Well, that sounds much like saying 'HTTPS gets you nowwhere'. And
> that's true - partially. As long as you can't authenticate your party,
Yes. I think you need to do some homework with respect to trust
relationships. IN WHICH CASE, THERE IS NO POINT IN DOING ENCRYPTION.
> you're vulnerable to blackhats attempting to impersonate them. But
> still, you get your data channel encrypted, which makes it harder for
> those with sniffers/carnivores/whatever to scan your mail for keywords
> and then perhaps dig in deeper if they find something interesting.
There is this little thing you might want to know about, called traffic
analysis. If they're watching the host, it is just as easy for them to
proxy and MitM the connection, especially if they've got the permission
of the hosting ISP to have the carnivore boxes. They may well even have
the private keys by permission of the host, in which case they can MitM
and sign the connection in a real way. You have many more problems to
worry about if you're just trying to hide from law enforcement.
This is, of course, not to mention the most obvious problem with your
argument, which is that the host providing the primary MX may just be
a relay, which will then relay the message to the delivery agent in
plain text, allowing the carnivore box to do its work at that point.
> Not much for security here, agreed - it's rather a matter of privacy.
> Anyways - I hope this makes my point of view clear.
Your point of view has been made clear, and is just plain stupid. If you
think you get any extra privacy through this route, you are plainly
clueless.
> > Server, setup as a relay, but only for machines that have a valid client
> > cert and do a TLS connection. For some reason, it can't currently get at
> > its certificates, (perhaps they're on an encrypted filesystem or some
> > such). Temporary error ensues, because the state of the connection is
> > undefined, so you have to abandon it completely. I try again, without
> > TLS this time, but the mailserver is configured to bounce all non-TLS
> > mail with a ``550 Relaying denied'' message. Thus you've just escalated
> > a temporary error (which should defer and retry) to a permanent one. I
> > think this is *bad* default behaviour.
> Great, OK. That means the host in question MUST NOT be a public MX for
> the domain. I hope that's clear and I won't elaborate on that issue.
Your *wrong* opinion. This is discriminatory to people who only have one
IP addresses.
> So now we actually have two scenarios, both involving use some policy
> based mail routing that bypases normal lookuphost/ipliteral routers:
> 1) The host in question is your smarthost and you route all your mail
> through them. You just setup a special router and switch the proposed
> option off for it along with setting up proper client certificates and
> stuff.
In which case, everything talking to it will have agreed encryption, in the
same way as they've ``agreed'' to use that machine as a smarthost. I think
you're missing what I mean by "agree".
> 2) There is some weird setup where some mail goes to some special purpose,
> top secret, members only relay host while all other mail is routed
> normally. But knowing that this special host cannot be listed as
> an MX for the domain, you must arrange a special router that handles
> mail for them. And you can turn the option off for it.
Huh!?
> > I think it's a crazy piece of functionality to have.
> Good. Still, it's one that won't hurt. If left disabled, it wouldn't
I've given you a good example where it does hurt, you chose to say that
I was wrong, but your own cluelessness shows through.
> influence Exim's functionality in any ways. When enabled, in most
> common real-world setup with lookuphost and iprouter it can't do you
> any harm either. And being able to turn it off for any other routers
> you might have to write, you're safe.
You're talking crap! I've given you a particularly good example of where
it doesn't work.
What you missed, is that you can't communicate that a client certificate
is required, in band with the STARTTLS command. By not being able to do
this, then trying to do encryption just because a host advertises STARTTLS
is obviously wrong, because you don't know what the policies required of
you are. This is what I said in my previous message, and if you don't
understand why this is bad, I suggest you don't try and do any encryption
at all.
> BTW - what do you think about so-called opportunistic encryption in
> IPSec? When you find a key available for some host, do you write their
> administrators asking for permission to use IPSec when communicating
> with them or do you just use it?
Well, IKE is not exactly a simple protocol to understand. I don't think
I'd use IPSec to a host without agreeing in advance in some way with the
administrator (which includes the administrator putting up a web page with
"please use IPSec with this key"). I don't see why I should expect it to
work, after all, it may require some kind of key from me, in the same way
as exim might, and this cannot be communicated in band for setting up the
connection, so you leave the connection in an inconsistent state.
Happy Christmas/Channukah/Diwali/Ramadan
MBM
--
Matthew Byng-Maddick <mbm@???> http://colondot.net/
