On Thu, Feb 28, 2013 at 07:28:18PM +0000, Tony Finch wrote:
> (2) There is a draft for MTA-to-MTA SMTP. In addition to saying "use
> draft-ietf-dane-srv" (which covers most of what needs saying) it also
> addresses the fact that RFC 3207 doesn't specify how to validate mail
> server certificates.
>
> http://tools.ietf.org/html/draft-ietf-dane-smtp
My perspective, is that any sane administrator of a cluster of
equal-preference MX hosts will use:
example.com. IN MX 0 mx1.example.com.
example.com. IN MX 0 mx2.example.com.
...
;
_25._tcp.mx1.example.com IN CNAME 3.1.1._dane._smtp.example.com.
_25._tcp.mx2.example.com IN CNAME 3.1.1._dane._smtp.example.com.
...
;
3.1.1._dane._smtp.example.com. IN TLSA 3 1 1 <public-key-fingerprint>
and the question of the contents of the certificate (beyond containing
the expected public key) becomes moot.
The same goes with certificate usage 1, in fact I plan to treat
"1" as a clue-deprived typo for "3". IMNSHO the domain owner is
expected to not publish DNS bindings to certificates that fail to
pass PKIX validation. For the same reason I plan to treat "0" as
a clue-deprived typo for "2". This substantially simplifies
implementation with no real reduction in security.
Given that the overwhelming majority of SMTP the minority of SMTP
servers that offer TLS do so with self-signed or otherwise not
verifiable certificates, it makes little sense with SMTP to at this
late stage jump on board the sinking public CA ship. Therefore,
I would suggest that the use of "3 1 1" DANE records should be
strongly recommended for SMTP servers over all other options.
The remaining state machine (when DANE support is enabled) bols
down to:
- If destination is subject to local TLS policy:
http://www.postfix.org/TLS_README.html#client_tls_policy
do that in preference to any DANE policy (except when that local
policy *is* to do DANE for that specific destination).
- If MX RRset bogus (including bogus NXDOMAIN/NODATA): tempfail
- If MX RRset insecure: do opportunistic TLS with plaintext fallback
- If MX RRset NODATA, impute a validated "IN MX 0 <nexthop-domain>"
- If validated MX records in hand, for each MX host look for
a validated _25._tcp.<hostname> RRset.
- If bogus (including bogus NXDOMAIN/NODATA), remove host from
MX list (tempfail if last host)
- If insecure, do opportunistic TLSA with this host
- Discard malformed/unusable TLSA RRs
- Apply remaining policy, or if none do opportunistic TLS with
plaintex fallback.
In all the above a RRset that results from a chain of CNAME expansions
is validated if and only if all the CNAME RRs are validated in
addition to the final result RR.
Is there any particular portion of the draft on which you would
like to see additional community input?
--
Viktor.
