> On Jan 31, 2018, at 1:14 PM, Danny Horne <da...@trisect.uk> wrote:
>
> I've read what Postfix documentation I can find on the subject, and I
> don't understand why I'm seeing untrusted connections rather than
> trusted. I'm using an account at mailbox.org for testing purposes, they
> use DNSSEC / DANE for there server (as do I), and I see a verified
> connection when sending email to their server, but returned connections
> are untrusted.
>
> This is what's logged when TLS logging is set to 2 -
TLS log level 1 is almost always enough. More logging generally just
makes it harder to see the key information amidst all the low-level
noise.
> Jan 31 17:53:31 indium postfix/smtpd[30307]: Untrusted TLS connection
> established from mx1.mailbox.org[80.241.60.212]: TLSv1.2 with cipher
> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
It is exactly what's expected. DANE TLS is used by clients to authenticate
servers. There is no standard (I did not make progress on the draft
quickly enough) to use DANE to authenticate TLS clients to servers.
The server would need to know when and where to search for the client's
TLSA records. This would perhaps require a new SMTP command so that the
server configures its TLS engine to ask for client certificates and would
look up the client's TLSA records at something like:
_smtp-client.<helo-name-fqdn> IN TLSA ?
or a just-in-time TLS extension in the client TLS HELLO, that would
cause the server to do the same via a suitable TLS extension callback.
Even if this were all done, what would you do differently with clients
that did authenticate their HELO name (or some name sent in the TLS
extension)?
If there is a sufficiently well-motivated use-case for using DANE for
TLS client auth, I could resume work with Shumon Huque on the DANE
client auth draft, and add support for this in Postfix and OpenSSL,
but presently this does not seem a high priority. It is not clear
what real benefit such client authentication would bring.
Perhaps once DANE authentication of servers is more common, we can
look at extending DANE to cover clients, but for now the first step
is convincing enough servers to publish TLSA records.
Presently, I am tracking 5.2 million DNSSEC domains of which 177
thousand have TLSA records for at least all their primary MX hosts,
with 176 thousand of those having TLSA records for all MX hosts.
While we have some good progress with early adopters, we still
have a long way to go. I'll be giving a talk on DANE adoption
at ICANN61 in March.
--
Viktor.
