On Fri, Jul 25, 2014 at 08:14:14PM +0200, BlueStar88 wrote:
> It is a difference to talk about MUA-MTA or MTA-MTA connections
> (client-server role or server-server role). It's quite easy for MTAs, to
> have proper client certificates, to show perfect host integrity to other
> MTAs. Maybe it is time to make progress into that direction. Especially
> since most of the large email providers serve client certificates with
> correct CN to FQDN match on MTA-MTA connections already.
Wishful thinking does not trump cold hard logic. What exactly are
you proposing? An SMTP client connects to a TLS capable MTA, now
what?
* What does the server do differently when the client has a
certificate from a trusted CA, a certificate from an untrusted
CA, or no certificate at all?
* If a trusted certificate contains a set of DNS names, how
are the names used? If they are not used, what is the point
of the certificate? (Certificates bind public keys to names).
> Is there a way to have a host/domain specific chain walk decision, like
> in "smtp_tls_policy_maps"? For example: Let Google's MTA proceed on an
> inbound connection only if a previous chain walk was successful.
What's a "Google's MTA"? What is a "successful chain walk"?
> If, at
> some time, a MITM breaks the chain walk, the connections must be rejected.
MiTM detection is up to the SMTP client:
http://www.postfix.org/TLS_README.html#client_tls_limits
If a client does not do MiTM detection, then the MiTM can simply
connect to the server with no client certificates at all. Now
what? You'll reject all SMTP clients that don't present client
certificates? Why?
> >> I think the server checks, if the peer hostname fits the CN.
> >
> >It does not.
>
> It should.
Check against what? Before a name can be checked, one needs to
know what to compare it to. Client certificates are authorization
credentials and only meaningful when the server has a database
entry for the client in question. Just checking that the client's
certificate name is the client's certificate name is meaningless.
Now perhaps you want to have access checks keyed by the client name
provided that name comes from a trusted certificate, issued by a
particular authority, allowing check_ccert_access to work across
certificate renewals. Here, we'd have to figure out how to extract
the primary name from the certificate, or whether to try the check
with every DNS name (or perhaps even every email address) in the
certificate, and how to allow you to specify which CAs are valid
for which client names (unless you want a flat trusted CA list).
> Since strictness to a given security level is a) a decision of
> each MX node itself and b) must cover both directions in my opinion.
Failure to understand the fundamental asymmetry between the client
and server roles in SMTP (in particular) or TLS (in general) leads
to magical thinking where you want the impossible, and insist that
surely everyone is negligent or incompetent for failing to see the
light.
> Having
> only inbound connections covered, is a weak point of relying on security
> levels at all. You see, I can't tell Google, to proceed in my direction
> only if my certificate chain was walked by them successfully. It's a sort
> of chicken-egg problem.
You don't even need to tell them, then use TLS opportunistically,
and perhaps some day they will implement client-side DANE support
and will be able to discover your TLSA records and act accordingly.
A number of German email providers already do this, and more are
on the way.
> To solve this and if we really want to harden public MTA-MTA links, we
> should allow Postfix operators to set a better security level (Verify or
> DANE for example) on well known links independently. That means both
> directions without any cooperation of the remote node.
Sorry, verification of client certificates is meaningless without
some kind of authorization policy based on client identity. In
particular, client certs only make sense for domains with which
you have prior relationship.
What specifically are you trying to do. What would TLS levels
other than "none", "may" or "encrypt" actually mean in an SMTP
server? For example, how should a server behave when its TLS
security level is "secure" or "dane"?
--
VIktor.
