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 happened.
dns.lu education.lu lmrl.lu restena.lu
There are just six more that I know of for a total of 10, in contrast to 962 domains with conformant certificate usages.
dougbarton.us retrosnub.uk retrosnub.net retrosnub.co.uk dnmailer.de davidhogue.com
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 https://dane.sys4.de/smtp/education.lu 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.
http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13#section-2.2
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 delivery.
http://tools.ietf.org/html/draft-ietf-dane-ops-07#section-10.3
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.