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

Re: Enforced TLS per MX

Expand Messages
  • 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 1 of 7 , Feb 22, 2013
    • 0 Attachment
      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 2 of 7 , Feb 22, 2013
      • 0 Attachment
        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 3 of 7 , Feb 22, 2013
        • 0 Attachment
          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 4 of 7 , Feb 27, 2013
          • 0 Attachment
            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 5 of 7 , Feb 27, 2013
            • 0 Attachment
              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.