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

Re: Enforced TLS per MX

Expand Messages
  • Wietse Venema
    ... Surely, the policy table is indexed by MX hostname as well as recipient domain. Wietse
    Message 1 of 7 , Feb 22, 2013
      Jan P. Kessler:
      > Dear list,
      >
      > 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.

      Wietse
    • Viktor Dukhovni
      ... 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
      Message 2 of 7 , 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.
      • Wietse Venema
        ... I see. This was a property of the legacy tls-per-site table. Wietse
        Message 3 of 7 , Feb 22, 2013
          Viktor Dukhovni:
          > 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

          I see. This was a property of the legacy tls-per-site table.

          Wietse
        • Viktor Dukhovni
          ... Yep, security is a pain. I did not want to provide a false sense of security with the new policy table. None of the fancy certificate verification is worth
          Message 4 of 7 , Feb 22, 2013
            On Fri, Feb 22, 2013 at 11:33:53AM -0500, Wietse Venema wrote:

            > Viktor Dukhovni:
            > > 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
            >
            > I see. This was a property of the legacy tls-per-site table.

            Yep, security is a pain. I did not want to provide a false sense
            of security with the new policy table. None of the fancy certificate
            verification is worth much if it is trivially subverted with a
            forged DNS response. We will be able to meet user expectations
            once DNSSEC is more pervasive (5-10 years with a bit of luck,
            they will typically be running 2.11 or later by then too).

            --
            Viktor.
          • Jan P. Kessler
            ... So it would have the same quality as the encrypt action, no? Something between 0 and 100, that could be explicitly mentioned in the docs. Doesn t help
            Message 5 of 7 , Feb 27, 2013
              Am 22.02.2013 17:06, schrieb Viktor Dukhovni:
              > 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.

              So it would have the same "quality" as the "encrypt" action, no?
              Something between 0 and 100, that could be explicitly mentioned in the
              docs. Doesn't help with a MITM but keeps out the firewall/provider guy
              with debug/snoop/tcpdump - and your idp of course :-(

              But I understand the point and agree with it although it doesn't make me
              very happy. We are replacing an interconnection between some companies
              with several 1000s of domains (actively used, frequently enhanced) via
              leased lines. This required (and unfortunately still requires) a
              database for domain exchange and some kind of 'administrative
              discipline' to keep it updated in time. My expectation is that DNSSEC
              will be globally used before the last point is going to function properly ;)
            • Viktor Dukhovni
              ... Yes. -- Viktor.
              Message 6 of 7 , Feb 27, 2013
                On Thu, Feb 28, 2013 at 12:25:53AM +0100, Jan P. Kessler wrote:

                > Am 22.02.2013 17:06, schrieb Viktor Dukhovni:
                >
                > > > 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.
                >
                > So it would have the same "quality" as the "encrypt" action, no?

                Yes.

                --
                Viktor.
              Your message has been successfully submitted and would be delivered to recipients shortly.