ietf-dane at dukhovni.org
Mon Jan 19 17:41:42 CET 2015
On Mon, Jan 19, 2015 at 12:15:34PM +0100, Wolfgang Breyha wrote:
> One of our users tried to send mail to the domain education.lu.
This is one of four related .lu domains with "unusable" TLSA RRsets.
I've notified them of the problem multiple times, and they initially
(on Dec 10th 2014) said they'd take care of it, but nothing has
There are just six more that I know of for a total of 10, in contrast
to 962 domains with conformant certificate usages.
The first is a conscientious objector to the SMTP draft's certificate
usage restrictions. The others never replied to my email notifying
them of the problem.
> The DANE validator
> says: "Unusable TLSA Records". Most likely because it is type 1 not allowed
> for DANE-SMTP?
Correct, this certificate usage is not appropriate for DANE SMTP
and should be treated as unusable by DANE SMTP clients. The Postfix
implementation predates the draft's final language.
> I've set hosts_try_dane = * in my SMTP transport.
> Exim refuses to talk to those hosts at all with "failure while setting up
> TLS session". Is this expected behavior in terms of DANE-SMTP? What's
> postfix doing in this case?
Todd Lyons unfortunately ran out of cycles before we finished the
Exim DANE code review.
That's a bug in the Exim implementation. When all TLSA records
are "unusable", the client MUST use TLS but without DANE authentication,
using either no authentication, or whatever authentication mechanisms
are appropriate via local policy.
A secure non-empty TLSA RRset where all the records are unusable: A
connection to the MTA MUST be made via TLS, but authentication is
not required. Failure to establish an encrypted TLS connection
MUST result in falling back to the next SMTP server or delayed
A service with DNSSEC-validated TLSA records implicitly promises TLS
support. When all the TLSA records for a service are found
"unusable", due to unsupported parameter combinations or malformed
associated data, DANE clients cannot authenticate the service
certificate chain. When authenticated TLS is dictated by the
application, the client SHOULD NOT connect to the associated server.
If, on the other hand, the use of TLS is "opportunistic", then the
client SHOULD generally use the server via an unauthenticated TLS
connection, but if TLS encryption cannot be established, the client
MUST NOT use the server. Standards for DANE specific to the
particular application protocol may modify the above requirements, as
appropriate, to specify whether the connection should be established
anyway without relying on TLS security, with only encryption but not
authentication, or whether to refuse to connect entirely.
Application protocols need to specify when to prioritize security
over the ability to connect under adverse conditions.
More information about the dane-users