[exim-dev] Opportunistic DANE TLS mode for SMTP

Góra strony
Delete this message
Reply to this message
Autor: Viktor Dukhovni
Data:  
Dla: exim-dev
Temat: [exim-dev] Opportunistic DANE TLS mode for SMTP

I see that DANE was actively discussed on this list in March, sorry
I was not here to participate.

I am writing a draft RFC for an "experimental" protocol that
implements "opportunistic DANE TLS". This is designed to match
SMTP protocol reality whenever it is in conflict with strict
conformance with RFC 6698 or other potentially relevant IETF
documents. I'd like to see major MTAs implement the opportunistic
DANE TLS protocol. I'm also attempting to reach out to Sendmail
and Microsoft.

I am writing a separate draft on operational guidance for DANE TLSA
implementations that is not SMTP specific and covers some cornder
cases that need a bit more explanation than provided in RFC 6698.
With luck the second draft could be a basis for an update to 6698.

A couple of follow-ups to the March discussion:

    - It would be a mistake to use security status to trump MX
      preference.  Some sites have MX hosts that refuse all mail
      unless the secondary believe that the primary is down.


      Connecting to a secondary first, without trying the primary
      may even cause your MTA to be considered a spam source and
      denied access.


      The goal of TLS in SMTP is not end-to-end message security,
      it is rather hop-by-hop channel integrity.  When you connect
      to a particular MTA, you may be able to talk SMTP over a secure
      channel.  That's all.


      When you send to a secondary, even if that works, it will
      turn around and send to the primary, often over the same
      insecure channel you tried to avoid.  So I fully agree with
      Tony, DANE TLSA records MUST NOT trump MX preference.
      Receiving systems will configure themselves accordingly.


    - TLS with SMTP is best-effort opportunistic for the Internet
      at large.  PKIX-style always on security is not applicable,
      however SMTP can leverage DANE to make channel security MITM
      proof when a receiving domain publishes usable TLSA records
      (with DNSSEC in all the right places).


      If a sender wants unconditional use of TLS for a particular
      destination, he must configure special security settings for
      that destination (domain).


    - Turning on DANE by default for all destinations involves
      risks that should not be lightly ignored.  Administrators
      should be able to selectively enable DANE for some destinations,
      or selectively disable it for others.


      Postfix also allows enabling DNSSEC lookups (without which
      nobody gets DANE) on a per-transport (aka mailer in Sendmail
      terms, don't know what Exim would call this) basis.


    - Failure to authenticate a site for which usable TLSA records
      were found  MUST cause a connection abort.  However it is OK
      to treat frafile TLSA records as unusable, even if these
      are "must support" in RFC 6698.


    - PKIX certificate usages need not apply with MTA to MTA SMTP.
      Treat 0/1 as 2/3 respectively, but beware, that "0 0 [12]" and "0 1
      [12]" should by default be "unusable".  The reason is that if the
      trust anchor is a root CA, with certificate usage 0 the server
      is not obligated to include it in the chain, since the client
      is expected to do PKIX validation, and so should have a local
      copy.  Now with SMTP this is an unreasonable expectation, and
      so unless an MTA has a "complete set" of CA certs (whatever
      that means) usage 0 with selector != 0 is toxic, and should
      be treated unusable.  See section 7.4.2 of RFC 2246.


    - If you have useful suggestions for the (still very early)
      draft, or would like to contribute actively to its development
      please drop me a note.  I've not even finished proof-reading
      it yet, so please pardon any "grammer" lapses or other errors.


      Sadly strict conformance to RFC 6698 while resulting in a
      document that may get IETF approval, will also result in a
      document that will be in practice unusable.


      Thus it may be that there will be two DANE SMTP RFCs, one
      that is "standards track" that nobody uses, and another that
      is "experimental track" and is actually what MTAs implement.


      The only way to avoid this is for Tony's document to take a
      bolder departure from 6698 given the reality of the Internet
      SMTP infrastructure.  I don't know how realistic it is for
      a "standards track" SMTP document to rock the boat in the
      manner required.  Tony will be the best judge of that.


      I am not interested in IETF standards per-se, rather I'd like
      to see DANE used sensibly with SMTP, be it via a standards
      track document, an experimental protocol, or informal consensus.


    - If you're curious about how Postfix handles DANE, see:


    http://vdukhovni.github.io/postfix/TLS_README.html#client_tls_dane


    and the bext below from:


    http://vdukhovni.github.io/postfix/TLS_README.html#server_cert_key


        If you use RFC 6698 TLSA "2 0 1" or "2 1 1" records to
        specify root CA certificate digests, you must include the
        corresponding root CA certificates in the "server.pem"
        certificate file.


        % cat server_cert.pem intermediate_CA.pem root.pem > server.pem


        Remote SMTP clients will be able to use the TLSA record
        you publish (which only contains the certificate digest)
        only if they have access to the corresponding certificate.
        Failure to verify certificates per the server's published
        TLSA records will typically cause the SMTP client to
        defer mail delivery. The foregoing also applies to "2
        0 2" and "2 1 2" TLSA records or any other digest of
        a CA certificate, but it is expected that SHA256 will
        be by far the most common digest for TLSA. You are
        strongly urged to likewise include the root CA certificate
        in your server certificate file even if you use "0 0
        1" or "0 1 1" TLSA records. Some DANE implementations
        in SMTP clients (Postfix among them) may treat RFC 6698
        certificate usages "0" and "2" interchangeably.


        By default, support for TLSA records that specify
        certificate usage "0" via a digest is disabled in the
        Postfix SMTP client. As a best practice, publish either
        "3 0 1" or "3 1 1" TLSA associations. See the documentation
        of the tls_dane_trust_anchor_digest_enable main.cf
        parameter for details.


-- 
    Viktor.