On Fri, Feb 22, 2013 at 08:48:31AM -0500, Wietse Venema wrote:
> > We are trying to establish enforced TLS with a partner that hosts about
> > 2000 recipient domains. All of these point to the same four MX records:
> >
> > host[1-4].example.com
> >
> > As I did not want to specify all of these domains in our tls_policy
> > file, I wanted to ask if there is any option to enforce TLS by those MX
> > addresses.
>
> Surely, the policy table is indexed by MX hostname as well as
> recipient domain.
No, it is not. Only the nexthop domain is used since the MX host
is derived from unauthenicated MX lookups and is trivially subject
to MITM attacks.
Just enabling opportunistic TLS pratically guarantees that TLS
will be used whenever the partner supports TLS, and there is no
MITM attack. When there is an MITM attack, the attacker could spoof
DNS MX replies and turn off TLS if we supported per-host policy.
The only way to securely integrate MX lookups into TLS policy is
to use DNSSEC. As mentioned in a previous post to this list, that
code is already under development, and many pieces are in already
in place.
If the DNS for all the hosted domains is managed by a provider who
has implemented DNSSEC for all the domains in question, the OP will
eventually be able to set TLS policy based on the MX. Even better,
(much more scalably) the policy can be based on RFC 6698 (DANE)
records in DNS with no local policy at all.
All of this will take a while to become widespread, as DNSSEC is
still the exception, not the rule. The operational issues need to
be worked out.
I expect to complete DANE support for Postfix 2.11 some time in
the next few months. My time is somewhat constrained, as is Wietse's
so it will take a bit of time, but there is no rush...
I only know of one domain with DNSSEC MX records and DANE records
for their MX host, that's nlnetlabs.nl (the developers of unbound
and nsd, which are my recommendations for recursive and authoritative
name servers with DNSSEC support). Even they make it tricky to
fully secure email with TLS, since their MX RRset includes 3rd party
backup MX hosts which DO NOT have DNSSEC and DANE.
$ drill -D mx nlnetlabs.nl; # Note the "ad" flag in the respose!
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 57956
;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 5
;; QUESTION SECTION:
;; nlnetlabs.nl. IN MX
;; ANSWER SECTION:
nlnetlabs.nl. 10200 IN MX 50 open.nlnetlabs.nl.
nlnetlabs.nl. 10200 IN MX 100 omval.tednet.nl.
nlnetlabs.nl. 10200 IN MX 150 xs4all.dacht.net.
nlnetlabs.nl. 10200 IN RRSIG MX 8 2 10200 ...
$ drill -D TLSA _25._tcp.open.nlnetlabs.nl
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 60823
;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 5
;; QUESTION SECTION:
;; _25._tcp.open.nlnetlabs.nl. IN TLSA
;; ANSWER SECTION:
_25._tcp.open.nlnetlabs.nl. 10200 IN CNAME 3.1.1._dane.nlnetlabs.nl.
_25._tcp.open.nlnetlabs.nl. 10200 IN RRSIG CNAME 8 5 10200 ...
3.1.1._dane.nlnetlabs.nl. 10200 IN TLSA 3 1 1 0d1fcbd7...
3.1.1._dane.nlnetlabs.nl. 10200 IN RRSIG TLSA 8 6 10200 ...
$ drill -D TLSA _25._tcp.omval.tednet.nl; # Note lack of "ad" in this case!
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 61315
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; _25._tcp.omval.tednet.nl. IN TLSA
;; ANSWER SECTION:
;; AUTHORITY SECTION:
tednet.nl. 18000 IN SOA omval.tednet.nl. ...
--
Viktor.
