Loading ...
Sorry, an error occurred while loading the content.

291502Re: Enforced TLS per MX

Expand Messages
  • Viktor Dukhovni
    Feb 22, 2013
      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.
    • Show all 7 messages in this topic