Subject: [dane] draft-ietf-dane-smtp

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 21 Apr 2013 08:58:34 +0200

Comments on draft-ietf-dane-smtp-01

"domain and its SMTP server host names (i.e. the MX recods), and"

=> MX Records

"If a server has TLSA records whose DNSSEC validation status is "secure", whether they are usable or not, the
   client MUST use TLS to connect to the server and validate the certificate according to [
   I-D.ietf-dane-srv] section 3."

I might have missed something in another draft, but which clients  does this MUST apply to? Is there a MUST use DNSsec somewhere else?
Or does this only apply IF dnssec is used? 

/O

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 21 Apr 2013 07:30:46 +0000

On Sun, Apr 21, 2013 at 08:58:34AM +0200, Olle E. Johansson wrote:

> => MX Records
> 
>   "If a server has TLSA records whose DNSSEC validation status is
>   "secure", whether they are usable or not, the client MUST use TLS
>   to connect to the server and validate the certificate according to
>   [I-D.ietf-dane-srv] section 3."
> 
> I might have missed something in another draft, but which clients
> does this MUST apply to? Is there a MUST use DNSsec somewhere else?

Not even then.

Sending systems are not obligated to implement either DNSSEC or
DANE TLSA.  Those that implement both, and are configured to make
use of both (at least for the destination domain in question) MUST
NOT fallback to plaintext delivery when no usable TLSA RRs are
found.  If usable TLSA RRs are found, then they are to be applied
per the SRV draft.

In the Postfix development snapshot the default fallback security
level when "dane" is enabled and TLSA RRs are present, but none
are usable, is "encrypt" (mandatory TLS with no authentication).
When no TLSA RRs are present, the default fallback level is "may"
(opportunistic TLS).

Administrators of sending systems may change either fallback level,
typically to something stronger, but also to "may" or "none" (no
TLS) if that's what they want.  I don't see a compelling reason to
prevent administrators from making this choice, they can also choose
to enable "dane" selectively or not at all.

If "dane" is enabled, the treatment of "unusable" RRs is by default
RFC compliant, and the documentation encourages this choice:

    If DNSSEC validated TLSA records are found, but none are usable
    (unsupported parameters or are malformed), the "dane" security
    level degrades to a security level specified via the
    "smtp_tls_dane_tlsa_unusable_level" main.cf parameter or via
    the per-destination "unusable_tlsa_level" attribute of a "dane"
    record in the policy table.  This security level is expected
    to require unconditional TLS with certificate verification if
    possible.  However, in most cases certificate verification will
    be impractical in the absense of usable TLSA records so the
    default degraded level is "encrypt".

I probably should add a comment to the effect that choosing "may"
or "none" is contrary to the receiving system's implied policy, and
should be avoided.

-- 
	Viktor.