education.lu

[Viktor Dukhovni]

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.

-- 
	Viktor.