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.
draft-dukhovni-smtp-opportunistic-tls-00.xml.gz
Description: application/gunzip
o.html.gz
Description: application/gunzip
-- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
