Always "Untrusted TLS" for own Postfix instances

[Dirk Stöcker]

Hello,

I'm lost and don't find any solution anymore, so I now need to ask.

I'm running three mail-servers with Postfix 2.9.6 (valid TLS cert), 2.7.2
(self-signed), 2.11.0 (self-signed).

And whatever I do I'm unable to get any of these three to show a trusted
connection to any of the others. It trusts Google and GMX and whatever,
but not my own servers. That's disturbing.

Here the configs I use essentially

smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_cert_file = ...cert file include cert and all related ca's...
smtpd_tls_key_file = ...key...
smtpd_tls_CApath = /etc/ssl/certs/

smtp_tls_loglevel = 1
smtp_tls_security_level = may
smtpd_tls_CApath = /etc/ssl/certs/

The certificates are installed and

openssl s_client -debug -connect ...server...:25 -starttls smtp

also says that certificate chain is complete and valid. But Postfix tells
me "Untrusted" when sending a mail to one of the others. Always. It's
disturbing.

Using a higher loglevel for TLS it seems that the other servers like
Google send the certificates in initial connection of TLS, but my Postfix
instances don't do this. And due to "may" Postfix sender seems not to ask.

But even if it is not necessary to have a valid certificate installed for
sending, I at least want to have the status correct in the logfile, so I
can see a MITM attack in the log afterwards.

Any ideas what's wrong with my setup or how I can bring Postfix to log the
correct trust status even if "may" is used?

Two of the servers are the one for this mail: mail.stoecker.eu and another
one with a valid cert: josm.openstreetmap.de in case it helps to have a
look.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

[Wietse Venema]

Dirk St?cker:

> Hello,
>
> I'm lost and don't find any solution anymore, so I now need to ask.

If in doubt, turn off chroot. Some Linux distributions mistakenly
turn it on and make Postfix unnecessarily difficult to use.

Wietse

http://www.postfix.org/DEBUG_README.html#no_chroot

TRY TURNING OFF CHROOT OPERATION IN MASTER.CF

A common mistake is to turn on chroot operation in the master.cf
file without going through all the necessary steps to set up a
chroot environment. This causes Postfix daemon processes to fail
due to all kinds of missing files.

The example below shows an SMTP server that is configured with
chroot turned off:

/etc/postfix/master.cf:
# =============================================================
# service type private unpriv chroot wakeup maxproc command
# (yes) (yes) (yes) (never) (100)
# =============================================================
smtp inet n - n - - smtpd

Inspect master.cf for any processes that have chroot operation not
turned off. If you find any, save a copy of the master.cf file, and
edit the entries in question. After executing the command "postfix
reload", see if the problem has gone away.

If turning off chrooted operation made the problem go away, then
congratulations. Leaving Postfix running in this way is adequate
for most sites. If you prefer chrooted operation, see the Postfix
http://www.postfix.org/BASIC_CONFIGURATION_README.html file for
information about how to prepare Postfix for chrooted operation.

Wietse

[Viktor Dukhovni]

On Sun, Feb 23, 2014 at 02:28:07PM +0100, Dirk St?cker wrote:

> And whatever I do I'm unable to get any of these three to show a
> trusted connection to any of the others. It trusts Google and GMX
> and whatever, but not my own servers. That's disturbing.
>
> Here the configs I use essentially

Essentially, or actually?

> smtpd_tls_loglevel = 1
> smtpd_tls_received_header = yes
> smtpd_tls_security_level = may
> smtpd_tls_cert_file = ...cert file include cert and all related ca's...
> smtpd_tls_key_file = ...key...
> smtpd_tls_CApath = /etc/ssl/certs/
>
> smtp_tls_loglevel = 1
> smtp_tls_security_level = may
> smtpd_tls_CApath = /etc/ssl/certs/

Notice anything funny about the last line?

> also says that certificate chain is complete and valid. But Postfix
> tells me "Untrusted" when sending a mail to one of the others.
> Always. It's disturbing.

With opportunistic TLS, it really makes little difference, since
mail is delivered regardless of the verification status. You do
need to have the appropriate issuing CA in either smtp_tls_CAfile
(easier to get this right) or in smtp_tls_CApath (in which case
you need to run c_rehash from the same OpenSSL release as Postfix
is linked with).

> Using a higher loglevel for TLS it seems that the other servers like
> Google send the certificates in initial connection of TLS, but my
> Postfix instances don't do this. And due to "may" Postfix sender
> seems not to ask.

When both sides are Postfix, and the client is opportunistic, the
server and client typically agree to a cipher-suite without any
certificates. Why bother, if the client does not check anyway.

> But even if it is not necessary to have a valid certificate
> installed for sending, I at least want to have the status correct in
> the logfile, so I can see a MITM attack in the log afterwards.

If this is important to you, set:

smtp_tls_exclude_ciphers=aNULL

for the transport that delivers mail between your internal systems.

> Any ideas what's wrong with my setup or how I can bring Postfix to
> log the correct trust status even if "may" is used?
>
> Two of the servers are the one for this mail: mail.stoecker.eu and
> another one with a valid cert: josm.openstreetmap.de in case it
> helps to have a look.

$ posttls-finger -c -Lsummary -lmay "[josm.openstreetmap.de]"
posttls-finger: Untrusted TLS connection established to josm.openstreetmap.de[78.47.52.148]:25: TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)

This highlights a minor defect in the Postfix SMTP client TLS status
logging, it never actually logs the "Anonymous" case, that's only
done in the SMTP server.

PATCH:

diff --git a/src/tls/tls_client.c b/src/tls/tls_client.c
--- a/src/tls/tls_client.c
+++ b/src/tls/tls_client.c
@@ -1045,7 +1045,9 @@ TLS_SESS_STATE *tls_client_start(const TLS_CLIENT_START_PROPS *props)
*/
if (log_mask & TLS_LOG_SUMMARY)
msg_info("%s TLS connection established to %s: %s with cipher %s "
- "(%d/%d bits)", TLS_CERT_IS_MATCHED(TLScontext) ? "Verified" :
+ "(%d/%d bits)",
+ !TLS_CERT_IS_PRESENT(TLScontext) ? "Anonymous" :
+ TLS_CERT_IS_MATCHED(TLScontext) ? "Verified" :
TLS_CERT_IS_TRUSTED(TLScontext) ? "Trusted" : "Untrusted",
props->namaddr, TLScontext->protocol, TLScontext->cipher_name,
TLScontext->cipher_usebits, TLScontext->cipher_algbits);

With the patch I get:

$ posttls-finger -c -Lsummary -lmay "[josm.openstreetmap.de]"
posttls-finger: Anonymous TLS connection established to josm.openstreetmap.de[78.47.52.148]:25: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)

--
Viktor.

[Wietse Venema]

Viktor Dukhovni:

> diff --git a/src/tls/tls_client.c b/src/tls/tls_client.c
> --- a/src/tls/tls_client.c
> +++ b/src/tls/tls_client.c
> @@ -1045,7 +1045,9 @@ TLS_SESS_STATE *tls_client_start(const TLS_CLIENT_START_PROPS *props)
> */
> if (log_mask & TLS_LOG_SUMMARY)
> msg_info("%s TLS connection established to %s: %s with cipher %s "
> - "(%d/%d bits)", TLS_CERT_IS_MATCHED(TLScontext) ? "Verified" :
> + "(%d/%d bits)",
> + !TLS_CERT_IS_PRESENT(TLScontext) ? "Anonymous" :
> + TLS_CERT_IS_MATCHED(TLScontext) ? "Verified" :
> TLS_CERT_IS_TRUSTED(TLScontext) ? "Trusted" : "Untrusted",
> props->namaddr, TLScontext->protocol, TLScontext->cipher_name,
> TLScontext->cipher_usebits, TLScontext->cipher_algbits);

Applied to Postfix 2.8 and onwards.

Wietse

[Viktor Dukhovni]

On Sun, Feb 23, 2014 at 12:38:26PM -0500, Wietse Venema wrote:

> Applied to Postfix 2.8 and onwards.

Thanks. Returning to the OP's question, disabling anonymous
cipher-suites will no substantially help to (after the fact) detect
MITM attacks. All the attacker has to do is present some other
certificate from some trusted CA.

Without name checks (which don't apply for opportunistic connections)
the difference between "Trusted" and "Untrusted" is not in fact
that the former indicates absense of a man-in-the-middle. Rather,
with "Trusted" you can potentially enable a "secure-channel" for
later connections (tls policy table, ...) and get MITM protection,
for future connections (provided you don't trust any "rogue" CAs).

--
Viktor.

[Dirk Stöcker]

On Sun, 23 Feb 2014, Viktor Dukhovni wrote:

> On Sun, Feb 23, 2014 at 02:28:07PM +0100, Dirk St?cker wrote:
>
>> And whatever I do I'm unable to get any of these three to show a
>> trusted connection to any of the others. It trusts Google and GMX
>> and whatever, but not my own servers. That's disturbing.
>>
>> Here the configs I use essentially
>
> Essentially, or actually?

This should mean, that this was only an excerpt.

>> smtpd_tls_loglevel = 1
>> smtpd_tls_received_header = yes
>> smtpd_tls_security_level = may
>> smtpd_tls_cert_file = ...cert file include cert and all related ca's...
>> smtpd_tls_key_file = ...key...
>> smtpd_tls_CApath = /etc/ssl/certs/
>>
>> smtp_tls_loglevel = 1
>> smtp_tls_security_level = may
>> smtpd_tls_CApath = /etc/ssl/certs/
>
> Notice anything funny about the last line?

A typo, sorry. But text should have shown, that this part worked as
expected.

> When both sides are Postfix, and the client is opportunistic, the
> server and client typically agree to a cipher-suite without any
> certificates. Why bother, if the client does not check anyway.

Because it allows to at to least detect if connection has been broken. It
is a big difference for later investigation even if not for the mail
sending at that time.

Seems Postfix still need to learn a lot about secure connections. Your
text and my current experience seems to say it follows a total trust or
no trust. But there are at least two steps inbetween. E.G.

- Keep "may", but log much better status for later investigations
- Remember certs and report changes

> If this is important to you, set:
>
> smtp_tls_exclude_ciphers=aNULL
>
> for the transport that delivers mail between your internal systems.

Does not sound like what I want. I don't want to hardcode a specific
handling for some servers, I want that the "trusted" state is logged
properly in any possible case.

> This highlights a minor defect in the Postfix SMTP client TLS status
> logging, it never actually logs the "Anonymous" case, that's only
> done in the SMTP server.
>
> PATCH:
>

Would be an improvement, but essentially I search for a

smtp_tls_verify_certs=whenpossible

which improves the log, but does not affect sending. Maybe together with a

smtp_tls_remember_certs=yes

and a notice when Cert changed. I.e. with a note like
(Un)trusted (first seen at 12.01.2014, last change 23.02.2014).

That would greatly improve the usefulness of the TLS log messages.

Also a replacement for "may" which allows to enforce TLS for any
connection, where TLS worked at least once would improve security. That
way a system would get more secure the longer it is running.

A full woldwide TLS setup wont come very soon, so at least a step-by-step
migration would be fine.

Something like

smtp_tls_security_level = may_for_new_encrypt_otherwise_secure_for_validcert

I.e.
- use "may" by default
- When at least once TLS was supported use TLS from now on
- When at least once the cert was valid, verify it later as well

[li...@rhsoft.net]

Am 23.02.2014 23:57, schrieb Dirk Stöcker:
> Seems Postfix still need to learn a lot about secure connections

seems you need to do so

in case of opportunistic there is not real trust

trusted in case of a secure connection means both sides know each
other - opportunistic means the other side neeeds only whatever
certificate by a "trusted" CA and is counted as "trusted"

you can discuss about logging details but hardly about "secure connections"

[Dirk Stöcker]

As said, the question is whether you want to reach 100% security or "more"
security. E.g. remembering last state and reacting to that information can
be dangerous (but so can be trusting the whole SSL certificate system).
But when you assume that systems aren't compromised from the very
beginning but only sometimes - keeping a table and remembering will help a
lot.

Sure, you may be the one who is trapped, but you aren't the only one on
the world - hopefully someone else will notice it and publish that
information. But when everything is "untrusted" then nobody will notice.

Exactly this was how the fake certs for Google and other web-pages have
been detected.

[Dirk Stöcker]

On Sun, 23 Feb 2014, Dirk Stöcker wrote:

>> If this is important to you, set:
>>
>> smtp_tls_exclude_ciphers=aNULL
>>
>> for the transport that delivers mail between your internal systems.
>
> Does not sound like what I want. I don't want to hardcode a specific handling
> for some servers, I want that the "trusted" state is logged properly in any
> possible case.

Here I was wrong. At least it fixes the immediate trust issue. But if I'm
right it still does not even try to verify the hostname, right?

I hope there aren't any TLS capable mailservers, which fallback to
unencrypted transmission, when I use this.

[Viktor Dukhovni]

On Sun, Feb 23, 2014 at 11:57:35PM +0100, Dirk St?cker wrote:

> >When both sides are Postfix, and the client is opportunistic, the
> >server and client typically agree to a cipher-suite without any
> >certificates. Why bother, if the client does not check anyway.
>
> Because it allows to at to least detect if connection has been
> broken. It is a big difference for later investigation even if not
> for the mail sending at that time.

This is sadly useless. You either have too few CAs to make it
reliable or too many to make it trustworthy. Secure name checks
are not generally possible in the face of arbitrary MX records,
and without name checks validity of the certificate chain is
meaningless.

> Seems Postfix still need to learn a lot about secure connections.

[ Find a newbie to lecture on some other forum. ]

> >If this is important to you, set:
> >
> > smtp_tls_exclude_ciphers=aNULL
> >
> >for the transport that delivers mail between your internal systems.
>

> Does not sound like what I want. I don't want to hard-code a specific

> handling for some servers, I want that the "trusted" state is logged
> properly in any possible case.

In that case, make the setting global. That'll will provide the
desired false sense of security.

> smtp_tls_verify_certs=whenpossible

SMTP is not HTTP. Due to MX indirection, peer authentication is
not possible without explicit per-destination configuration. Once
you've gone to all that trouble, you may as well configure a "secure"
channel.

If you want scalable security for SMTP, become an early adopter of
DANE TLS, available in Postfix 2.11. Today, you'll be able to
opportunistically authenticate the handful of DNSSEC signed domains
that publish TLSA records for SMTP. Over time, I hope that handful
will grow to a decent fraction of SMTP sites.

https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane
http://www.postfix.org/TLS_README.html#client_tls_dane

> smtp_tls_remember_certs=yes

This is too brittle. If the TLS TACK draft becomes is adopted as
a standards track RFC, we could look into implementing that. It
requires a robust cache that persists across Postfix restarts, we
probably also need to let the Postfix LMDB support prove its
stability before venturing in that direction.

> and a notice when Cert changed. I.e. with a note like
> (Un)trusted (first seen at 12.01.2014, last change 23.02.2014).

Busy MTAs send mail to a lot of hosts and domains, and their
certificates change from time to time. Naive client-initiated
pinning is too unreliable.

> Also a replacement for "may" which allows to enforce TLS for any
> connection, where TLS worked at least once would improve security.
> That way a system would get more secure the longer it is running.

Ditto.

--
Viktor.

[Viktor Dukhovni]

On Mon, Feb 24, 2014 at 12:25:50AM +0100, Dirk St?cker wrote:

> >> smtp_tls_exclude_ciphers=aNULL
> >>
> >> for the transport that delivers mail between your internal systems.
> >

> >Does not sound like what I want. I don't want to hardcode a

> >specific handling for some servers, I want that the "trusted"
> >state is logged properly in any possible case.
>

> Here I was wrong. At least it fixes the immediate trust issue.

It forces the use of ciphersuites that employ server certificates.

> But if I'm right it still does not even try to verify the hostname,
> right?

As documented "may" does not attempt to authenticate the MX host,
it is not possible to do that generically without explicit peername
match settings. MX indirection makes this impractical and insecure.
SMTP is not HTTP.

> I hope there aren't any TLS capable mailservers, which fallback to
> unencrypted transmission, when I use this.

Fallback is up the client. I am not aware of any Internet facing
MX hosts that offer STARTTLS without any server certificate. Lots
of SMTP clients (not Postfix) don't support anonymous cipher-suites,
and such servers would have a lot of trouble receiving email.

--
Viktor.

[Dirk Stöcker]

On Sun, 23 Feb 2014, Viktor Dukhovni wrote:

>> smtp_tls_verify_certs=whenpossible
>
> SMTP is not HTTP. Due to MX indirection, peer authentication is
> not possible without explicit per-destination configuration. Once
> you've gone to all that trouble, you may as well configure a "secure"
> channel.

I know that there are many side-effects and things which don't work, but
that does not mean that one can at least try? For a lot of domains there
is a MX entry and only that server is responsible. So when a SMTP
connection is made, can't at least the logfile say that cert and MX match?

And I'm aware that even that wont help, as DNS is insecure.

> If you want scalable security for SMTP, become an early adopter of
> DANE TLS, available in Postfix 2.11. Today, you'll be able to
> opportunistically authenticate the handful of DNSSEC signed domains
> that publish TLSA records for SMTP. Over time, I hope that handful
> will grow to a decent fraction of SMTP sites.

Oh yes - DNSSEC. When will it come? In hundred years? Does that mean, that
when we can't have that, then we can't even try get the best security
available and always try the minimum?

> Busy MTAs send mail to a lot of hosts and domains, and their
> certificates change from time to time. Naive client-initiated
> pinning is too unreliable.

I know, I know. Using CertPatrol for Web pages showed me, that some
multi-homed sites change the certificate like after a few minutes, because
you move to another server with a different cert.

I only hate this "either we do it 100% secure or not at all" attitude.
What's the result? People still use mostly unencrypted transmission,
because they get told that encryption does not help, because it is SOOO
easy to circumvent. Even the NSA effect is already fading and there is no
real change.

Can't postfix simply try to detect what level of trust is possible and
report that?
1) unencrypted
2) encrypted
3) with a known cert
4) with a trusted cert matching the hostname
5) with a trusted cert matching the hostname + hostname == reverse DNS
6) DNSSEC
whatever else there is...

And step-by-step improve it?

Sorry, probably this is not the right place to complain, but I hear the
same arguments for so many years now and there is no progress. The
algorithms get better and better, but no progress in adopting useful
methods to use them. And seeing the big-money certificate system for SSL
which gives trust away to some uncontrollable companies and governments
also does not help a lot (probably even trying to prevent any wide
adoption of DNS based certs, because they will kill their model to earn
money).

[Dirk Stöcker]

On Sun, 23 Feb 2014, Viktor Dukhovni wrote:

>> I hope there aren't any TLS capable mailservers, which fallback to
>> unencrypted transmission, when I use this.
>
> Fallback is up the client. I am not aware of any Internet facing
> MX hosts that offer STARTTLS without any server certificate. Lots
> of SMTP clients (not Postfix) don't support anonymous cipher-suites,
> and such servers would have a lot of trouble receiving email.

Sorry for unclear text. I meant not the host itself to fallback, but the
client connecting to that host (like you describe).

[li...@rhsoft.net]

Am 24.02.2014 01:16, schrieb Dirk Stöcker:
> On Sun, 23 Feb 2014, Viktor Dukhovni wrote:

>>> smtp_tls_verify_certs=whenpossible
>>
>> SMTP is not HTTP. Due to MX indirection, peer authentication is
>> not possible without explicit per-destination configuration. Once
>> you've gone to all that trouble, you may as well configure a "secure"
>> channel.
>
> I know that there are many side-effects and things which don't work, but that does not mean that one can at least
> try? For a lot of domains there is a MX entry and only that server is responsible. So when a SMTP connection is
> made, can't at least the logfile say that cert and MX match?

which of the MX servers of a domain if there are more than one?
please understand as long as you don't *directl* verify a certificate
on both sides there is no trust and opportunistic means excatly that

who defines "trusted"?

if you can't answer that question you can't log that with any gain

[LuKreme]

On 23 Feb 2014, at 15:57 , Dirk Stöcker <pos...@dstoecker.de> wrote:
> Seems Postfix still need to learn a lot about secure connections. Your

No, you are simply not understanding the purpose of opportunistic TLS. The purpose is not to verify identity, but simply to encrypt the transmission channel. Identity is meaningless, and in this case, worthless.

Thinking of it as some sort of "secure email" is a mistake because email is not secure.

--
'Charity ain't giving people what you wants to give, it's giving people
what they need to get.'

[Wietse Venema]

Dirk St?cker:

> On Sun, 23 Feb 2014, Viktor Dukhovni wrote:
>

> >> I hope there aren't any TLS capable mailservers, which fallback to
> >> unencrypted transmission, when I use this.
> >
> > Fallback is up the client. I am not aware of any Internet facing
> > MX hosts that offer STARTTLS without any server certificate. Lots
> > of SMTP clients (not Postfix) don't support anonymous cipher-suites,
> > and such servers would have a lot of trouble receiving email.
>
> Sorry for unclear text. I meant not the host itself to fallback, but the
> client connecting to that host (like you describe).

When TLS is opportunistic but unusable, Postfix will certainly
deliver mail over a plaintext connection.

Wietse

[Viktor Dukhovni]

On Mon, Feb 24, 2014 at 01:16:39AM +0100, Dirk St?cker wrote:

> >SMTP is not HTTP. Due to MX indirection, peer authentication is
> >not possible without explicit per-destination configuration. Once
> >you've gone to all that trouble, you may as well configure a "secure"
> >channel.
>
> I know that there are many side-effects and things which don't work,
> but that does not mean that one can at least try?

Sorry, no half-assed solutions that work only sometimes and break
unpredictably.

> Oh yes - DNSSEC. When will it come? In hundred years?

Available today. Two of my domains are signed, the third will be
shortly. And you're complaining about people being complacent and
stuck in the past.

> Can't postfix simply try to detect what level of trust is possible
> and report that?

Without DNSSEC or explicit per-destination peer name match settings, no.

> 1) unencrypted
> 2) encrypted

Postfix already reports these.

> 3) with a known cert

Replace "known" with "valid trust chain", and Postfix logs this as
"Trusted".

> 4) with a trusted cert matching the hostname

This is meaningless. The MX host is insecure. Many MX hosts have
certs that don't match their name.

> 5) with a trusted cert matching the hostname + hostname == reverse DNS

This is even more meaningless.

> 6) DNSSEC
> whatever else there is...

Postfix 2.11 supports DANE, DANE actually scales, because policy
for each domain is published by that domain. DANE removes the
panoply of ~600 widely used CAs from the picture.

If you want secure SMTP transport, direct your efforts at DNSSEC,
and then publish TLSA records for your domain.

--
Viktor.

[Dirk Stöcker]

On Mon, 24 Feb 2014, Viktor Dukhovni wrote:

>> I know that there are many side-effects and things which don't work,
>> but that does not mean that one can at least try?
>
> Sorry, no half-assed solutions that work only sometimes and break
> unpredictably.

Yes, the same story again. When it does not work everywhere then we don't
do it at all.

>> Oh yes - DNSSEC. When will it come? In hundred years?
>
> Available today. Two of my domains are signed, the third will be
> shortly. And you're complaining about people being complacent and
> stuck in the past.

I don't want to have a perfection box which can't communicate with the
rest of the world, but something which helps with todays internet.

>> 3) with a known cert
>
> Replace "known" with "valid trust chain", and Postfix logs this as
> "Trusted".

As you already pointed out "Any known cert" is nearly as meaningless as
"unchecked".

>> 4) with a trusted cert matching the hostname
>
> This is meaningless. The MX host is insecure. Many MX hosts have
> certs that don't match their name.

And there are hosts where everything matches. Why not show it for these?

>> 5) with a trusted cert matching the hostname + hostname == reverse DNS
>
> This is even more meaningless.

It is an additional level of security. Only a very small bit, yes, but it
needs another thing an attacker needs to fix.

Couldn't postfix give something like a score for TLS security:
- 0% if unencrypted
- +5% when encrypted
- +5% if proper algorithm
- +5% if PFS is used
- +5% when cert is trusted
- +5% when cert also matches the MX
- ...
- 95% for DANE.

Yes, we stay below 30% for current setup, but at least you could evaluate
individual connections. What harm does it to call some checks and output
the results? They are already in the code, but only used in the perfect
environments.

I took a lot of time to figure out how to properly setup certificates
including ca chain, but actually I could have saved that time, because it
makes no difference.

I'm doing a lot in spamfiltering and there these score systems are a big
benefit.

>> 6) DNSSEC
>> whatever else there is...
>
> Postfix 2.11 supports DANE, DANE actually scales, because policy
> for each domain is published by that domain. DANE removes the
> panoply of ~600 widely used CAs from the picture.
>
> If you want secure SMTP transport, direct your efforts at DNSSEC,
> and then publish TLSA records for your domain.

Oh, I'll try, but I doubt I will get this done in the next 2 years.

My Registrar said today:
"Sorry, currently it is not possible to use DNSSec for domains registered
here."

But if I understand it right even if I do all perfect and hope that more
systems support that secure approach - I need to configure each system
supporting this individually by hand without any automatic aid in my own
system?

And then I need to hope that users start to use that information, because
all this work is completely useless until 100% deployed. My 100 years
guess aren't so bad I think. Very unlikely, that this approach will work.

[Dirk Stöcker]

On Mon, 24 Feb 2014, Viktor Dukhovni wrote:

>> I don't want to have a perfection box which can't communicate with
>> the rest of the world, but something which helps with todays
>> internet.
>

> Nonsense. Patrick Koetter's .de domain is DNSSEC signed. His
> mailserver has TLSA records. Enabling DNSSEC does not prevent you
> from communicating with the rest of the world. Furthermore, you
> can enable DNSSEC validation in your resolver before your own domain
> is signed. The two are independent.

So what do you think really - How long will it take until 10% of all mail
hosts use DANE/TLSA? Wouldn't it be a good idea to at least increase
security (even a little bit) for what we have now? I'd be happy when a
higher percentage would support TLS at all.

But you din't answer my question: What harm would it do, when the checks
implemented already to verify certs and domain names and maybe TLS
protocol quality are also executed for "Opportunistic TLS" and the
results printed in the log?

Would it really be bad when the line

Feb 24 18:56:04 merkur postfix/smtp[7701]: Trusted TLS connection established to mail.stoecker.eu[2a01:4f8:d13:3800::1:5]:25: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)

contains a note that the server certificate of the connection
actually also matched the domain name written there.

>> My Registrar said today:
>> "Sorry, currently it is not possible to use DNSSec for domains
>> registered here."
>

> Vote with your feet. I'm transferring my domains to a registrar
> with better DNSSEC support (and incidentally lower price).

I live in the "hightech country" Germany. Here a 16/1MB DSL line is
extreme highspeed internet, IPV4 is state of the art. I can only dream of
finding providers for more reliable Internet. DNSSEC is actually the
lowest of my problems.

>> And then I need to hope that users start to use that information,
>> because all this work is completely useless until 100% deployed. My
>> 100 years guess aren't so bad I think. Very unlikely, that this
>> approach will work.
>

> No, DANE secures SMTP transport between publishing servers and
> validating clients regardless of what everyone else is doing. The
> adoption model is incremental.

Is there a test server I can use to verify correct function? It does not
sound like a good idea to send some test mails to a server without a
permission to do so.

Even if it seems I can't get more security for my own server or get better
information out of postfix to evaluate the "low quality TLS" connections
it at least would be interesting to setup that support for sending. Maybe
in the next year there even will be an email to one of these servers.

[Robert Schetterer]

Hi Dirk

Be sure dnssec will spread fast at some point if massive attacks on dns
servers will rise more and more.

see

https://sys4.de/de/blog/2013/10/14/dns-fragment-angriffe-zeit-fur-dnssec/



Best Regards
MfG Robert Schetterer

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

[Viktor Dukhovni]

On Mon, Feb 24, 2014 at 07:03:21PM +0100, Dirk St?cker wrote:

> >Nonsense. Patrick Koetter's .de domain is DNSSEC signed. His
> >mailserver has TLSA records. Enabling DNSSEC does not prevent you
> >from communicating with the rest of the world. Furthermore, you
> >can enable DNSSEC validation in your resolver before your own domain
> >is signed. The two are independent.
>
> So what do you think really - How long will it take until 10% of all
> mail hosts use DANE/TLSA? Wouldn't it be a good idea to at least
> increase security (even a little bit) for what we have now? I'd be
> happy when a higher percentage would support TLS at all.

With a bit of luck roughly 5 years. Exim has not implemented DANE
yet, and the RFC for DANE TLS for SMTP has not yet been ratified
by the IETF. The first Postfix release with DANE just came out
last month, and is not in most O/S distributions.

We should see the RFC adopted in the next few months, and Exim
implementing this year. Getting a major provider like Gmail, Yahoo,
AOL, ... would be nice, this will take a bit longer, but will make
a big impact when it does.

I'm working with the OpenSSL team to add DANE support to OpenSSL
so that other applications can adopt DANE without doing all the
hard work from the ground up.

Changing the infrastructure on Internet scale takes time.

> But you din't answer my question: What harm would it do, when the
> checks implemented already to verify certs and domain names and
> maybe TLS protocol quality are also executed for "Opportunistic TLS"
> and the results printed in the log?

You're asking for a verification status that would indicate
conditional MITM protection:

- False negative: MITM protection is illusory when the MX
hostname is compromised through DNS record forgery.

- False positive: No claim of MITM protection when the MX
host's certificate does not match what was expected, even
though it is the right MX host.

- False negative: Your root CA list contains a rogue CA, or
an intermediate CA signed by a trusted CA is rogue.

- False positive: Your root CA list contains too few CAs.

Most Postfix users would be ill-served by such a confusing signal.

> >No, DANE secures SMTP transport between publishing servers and
> >validating clients regardless of what everyone else is doing. The
> >adoption model is incremental.
>
> Is there a test server I can use to verify correct function? It does
> not sound like a good idea to send some test mails to a server
> without a permission to do so.

Testing is possible without sending email. You just need to complete
a TLS handshake.

Since with DANE we know what an authenticated connection means, we
can and likely will soon add a setting which allows DANE to optionally
fall back to an MITM vulnerable mode ("encrypt" or "may") after
logging a warning, when authentication fails or TLS is unavailable
on the server. That will allow more cautious users to pilot DANE
without worrying about denial of service.

--
Viktor.

[/dev/rob0]

On Mon, Feb 24, 2014 at 01:16:39AM +0100, Dirk Stöcker wrote:

> On Sun, 23 Feb 2014, Viktor Dukhovni wrote:
> >If you want scalable security for SMTP, become an early adopter
> >of DANE TLS, available in Postfix 2.11. Today, you'll be able
> >to opportunistically authenticate the handful of DNSSEC signed
> >domains that publish TLSA records for SMTP. Over time, I hope
> >that handful will grow to a decent fraction of SMTP sites.
>

> Oh yes - DNSSEC. When will it come? In hundred years?

Dirk, do you mind explaining this? Are you having trouble finding
DNSSEC-enabled DNS hosting?

It's true that most of the numerous free DNS providers are not
DNSSEC-enabled, but I found a few:

http://www.frankb.us/dns/

Beware the services which do not support notify. When zones are
signed and automatically maintained, new signatures are published as
needed. With notify, slave NS hosts will pull the new data as soon as
it is available.

Self-hosting of DNS is not that difficult; in fact I think to set up
and maintain a Postfix MTA is much more challenging than BIND named.
But as with self-hosting mail, you get exposure to attacks and the
need to watch for security issues and patches.

I can suggest a cost effective way for SMBs with a moderately-capable
GNU/Linux admin on board to get unlimited DNSSEC-signed zones for
US$20/month: Linode.com. Run BIND named on your own VPS, then have
Linode's nameservers slave it. There may be other VPS providers
offering similar services, but I specifically mention Linode because
I know they support both notify and DNSSEC.

If you need enterprise-class hosting you are able and should be
willing to pay for it. Linode is low-end to be called "enterprise",
but I think they offer the geographic and network diversity that DNS
needs.

Of course there is no shortage of enterprise-class DNS hosting out
there, priced accordingly. My own employer is in that line, so I'll
avoid ethical questions by leaving off any specific mention of such
services.

> Sorry, probably this is not the right place to complain, but I hear
> the same arguments for so many years now and there is no progress.
> The algorithms get better and better, but no progress in adopting
> useful methods to use them. And seeing the big-money certificate
> system for SSL which gives trust away to some uncontrollable
> companies and governments also does not help a lot (probably even
> trying to prevent any wide adoption of DNS based certs, because
> they will kill their model to earn money).

Yep, I think DNSSEC and DANE will cheer you up quite well. :)
--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

[Dirk Stöcker]

On Mon, 24 Feb 2014, Viktor Dukhovni wrote:

> With a bit of luck roughly 5 years. Exim has not implemented DANE
> yet, and the RFC for DANE TLS for SMTP has not yet been ratified
> by the IETF. The first Postfix release with DANE just came out
> last month, and is not in most O/S distributions.

You're optimistic. Let's hope you're right, but I doubt it.

>> But you din't answer my question: What harm would it do, when the
>> checks implemented already to verify certs and domain names and
>> maybe TLS protocol quality are also executed for "Opportunistic TLS"
>> and the results printed in the log?
>
> You're asking for a verification status that would indicate
> conditional MITM protection:
>
> - False negative: MITM protection is illusory when the MX
> hostname is compromised through DNS record forgery.
>
> - False positive: No claim of MITM protection when the MX
> host's certificate does not match what was expected, even
> though it is the right MX host.
>
> - False negative: Your root CA list contains a rogue CA, or
> an intermediate CA signed by a trusted CA is rogue.
>
> - False positive: Your root CA list contains too few CAs.

Hmm, point 1,3,4 are already true for the current output. Adding the info
that Cert and hostname matched wont add additional drawbacks. Point 2 can
be addressed by the text. Don't write "VERIFIED", write "cert-match" or
whatever is suggesting less MITM protection level. Don't add any text,
when not matching or write the (first) certificate domain as reference.

If e.g. Google mail suddenly is sent to the mail.badguy.de it is much more
obvious in the log then if gmail-smtp-in.l.google.com gets a different IP.
Such an output would help to find second case easily.

>> Is there a test server I can use to verify correct function? It does
>> not sound like a good idea to send some test mails to a server
>> without a permission to do so.
>
> Testing is possible without sending email. You just need to complete
> a TLS handshake.

My setup should now be correct (at least according to docs). DNS responses
seem to be verified (positive and negative), so I assume it works.

But I have no idea how to use the postfix tools to start a TLS connection
to such an server without sending an email. This requires too much
internal knowledge I fear. Last time I tried to call smtp tool by hand it
told me not to do so and I took that advice.

I can use mail(x) or telnet or openssl, but this does not tell me if the
postfix settings are right.

> Since with DANE we know what an authenticated connection means, we
> can and likely will soon add a setting which allows DANE to optionally
> fall back to an MITM vulnerable mode ("encrypt" or "may") after
> logging a warning, when authentication fails or TLS is unavailable
> on the server. That will allow more cautious users to pilot DANE
> without worrying about denial of service.

This affects receiving servers with wrong configured TLSA/DNSSEC settings?
Actually I thought that stopping mail delivery in case DANE is detected
and defective is a very good idea.

Shouldn't that case be obvious in the "broken" server log - connection
aborts after the TLS phase?

[LuKreme]

On 24 Feb 2014, at 06:09 , Viktor Dukhovni <postfi...@dukhovni.org> wrote:

> On Mon, Feb 24, 2014 at 12:26:42PM +0100, Dirk St?cker wrote:
>
> Nonsense. Patrick Koetter's .de domain is DNSSEC signed. His
> mailserver has TLSA records. Enabling DNSSEC does not prevent you
> from communicating with the rest of the world. Furthermore, you
> can enable DNSSEC validation in your resolver before your own domain
> is signed. The two are independent.

Wait, what? You can?

Hmmm... Hover.com is still not supporting DNSSEC, but I can still validate my domains?

That's not exactly what you said, is it?

> It only takes a few minutes to configure a validating recursive
> resolver. Install unbound and make sure it performs automatic
> tracking of the root zone DNSKEY.

unbound is better than bind for this sort of thing? (I noticed freeBSD 10 has switched from bind to unbound, I expect they have good reason).

>> My Registrar said today:
>> "Sorry, currently it is not possible to use DNSSec for domains
>> registered here."
>
> Vote with your feet. I'm transferring my domains to a registrar
> with better DNSSEC support (and incidentally lower price).

Yes, well, in general registrars kind of suck, and hover doesn't suck. But yes, they need to get DNSSEC sorted.

>> But if I understand it right even if I do all perfect and hope that
>> more systems support that secure approach - I need to configure each
>> system supporting this individually by hand without any automatic
>> aid in my own system?
>

> No. DANE does not require per-destination configuration. That's the
> point.

DANE sounds nifty!

>> And then I need to hope that users start to use that information,
>> because all this work is completely useless until 100% deployed. My
>> 100 years guess aren't so bad I think. Very unlikely, that this
>> approach will work.
>

> No, DANE secures SMTP transport between publishing servers and
> validating clients regardless of what everyone else is doing. The
> adoption model is incremental.

Ibid.

--
Oh, he's just like any other man, only more so.

[Viktor Dukhovni]

On Mon, Feb 24, 2014 at 10:15:48PM +0100, Dirk St?cker wrote:

> >You're asking for a verification status that would indicate
> >conditional MITM protection:
> >
> > - False negative: MITM protection is illusory when the MX
> > hostname is compromised through DNS record forgery.
> >
> > - False positive: No claim of MITM protection when the MX
> > host's certificate does not match what was expected, even
> > though it is the right MX host.
> >
> > - False negative: Your root CA list contains a rogue CA, or
> > an intermediate CA signed by a trusted CA is rogue.
> >
> > - False positive: Your root CA list contains too few CAs.
>
> Hmm, point 1,3,4 are already true for the current output.

Actually, no. By default Postfix trusts no CAs, even when these
are bundled with the system. And Postfix does not use the insecure
MX hostname by default, it uses the nexthop domain. The intent is
to log "Anonymous" or "Untrusted" for all opportunistic connections.

If you add every CA on the planet to your trusted CA list, and
expect the result to mean something for connections to any random
receiving domain, that's your business.

Only for destinations where you have explicit policy that makes
secure-channels possible, should you get "Trusted" or "Verified",
relative to your carefully selected small set of CAs.

[ No follow-ups to the above. Thanks. ]

> But I have no idea how to use the postfix tools to start a TLS
> connection to such an server without sending an email. This requires
> too much internal knowledge I fear. Last time I tried to call smtp
> tool by hand it told me not to do so and I took that advice.

/usr/sbin/sendmail -f $(id -nu) -bv 'postm...@example.com'

or via the "posttls-finger" utility from Postfix 2.11 source tarball.

> >That will allow more cautious users to pilot DANE
> >without worrying about denial of service.
>
> This affects receiving servers with wrong configured TLSA/DNSSEC
> settings? Actually I thought that stopping mail delivery in case
> DANE is detected and defective is a very good idea.

When you first turn on DANE as a default policy, you have no way
to estimate the impact on your users in terms of deferred mail to
misconfigured sites they want to send to. Having a setting that
allows users to test-drive DANE without enforcement is probably
a good idea. I would prefer if users did not use DANE that way
indefinitely, rather it is a migration aid.

--
Viktor.

[/dev/rob0]

On Mon, Feb 24, 2014 at 02:36:46PM -0700, LuKreme wrote:
> On 24 Feb 2014, at 06:09 , Viktor Dukhovni
> <postfi...@dukhovni.org> wrote:
> > On Mon, Feb 24, 2014 at 12:26:42PM +0100, Dirk St?cker wrote:
> >
> > Nonsense. Patrick Koetter's .de domain is DNSSEC signed. His
> > mailserver has TLSA records. Enabling DNSSEC does not prevent
> > you from communicating with the rest of the world. Furthermore,
> > you can enable DNSSEC validation in your resolver before your
> > own domain is signed. The two are independent.
>
> Wait, what? You can?

My zone "nodns4.us" is signed. You can set up your resolver to verify
these signatures. Later on you might want to sign "kreme.com", and
indeed, this has nothing to do with your local resolver.

> Hmmm... Hover.com is still not supporting DNSSEC, but I can still
> validate my domains?
>
> That's not exactly what you said, is it?

Does your domain registrar control (or even ask to control) what you
list in your /etc/resolv.conf file? Mine doesn't. And my resolv.conf
points to "nameserver 127.0.0.1", my own local resolver, which does
perform DNSSEC validation.

> > It only takes a few minutes to configure a validating recursive
> > resolver. Install unbound and make sure it performs automatic
> > tracking of the root zone DNSKEY.
>
> unbound is better than bind for this sort of thing? (I noticed

"Better" is subjective. I doubt it. It is trivial to enable DNSSEC
validation in BIND. In fact it almost works out of the box. There's
only one thing to set, in the named.conf(5) options stanza, to wit:
options {
[ ... ]
dnssec-validation auto;
};
(Offer void where taxed or prohibited, or if your BIND version is
unsupported/EOL. Right now that means BIND 9.7 and earlier -- now
including the recently retired 9.6-ESV branch.)

> freeBSD 10 has switched from bind to unbound, I expect they have
> good reason).

And the FreeBSD BIND package has defined empty zones for years,
despite the BIND empty zones feature which has existed all along.
Perhaps their reasons are rooted in misunderstandings of BIND?

I can't say anything good or bad about unbound, never having used
anything other than BIND. I've had no reason to change.

> >> My Registrar said today:
> >> "Sorry, currently it is not possible to use DNSSec for domains
> >> registered here."
> >
> > Vote with your feet. I'm transferring my domains to a registrar
> > with better DNSSEC support (and incidentally lower price).
>
> Yes, well, in general registrars kind of suck, and hover doesn't
> suck. But yes, they need to get DNSSEC sorted.

I'd call lack of DNSSEC support a serious drawback. I'm on Godaddy
for now, but I'm probably going to jump ship to GKG.net. They make
the claim to be DNSSEC-friendly. It sounds like you can run your
master nameserver and sign your zone, and they will provide slave
(secondary) name service for free (included with the domain
registration cost.)

[li...@grootstyr.eu]

FreeBSD changed to unbound as a local resolver not as a replacement for
the DNS server BIND. It is explicitly stated in their release notes that
the change to unbound as a local resolver, not as a replacement for
providing the DNS service.

[Dirk Stöcker]

Hello,

>> But I have no idea how to use the postfix tools to start a TLS
>> connection to such an server without sending an email. This requires
>> too much internal knowledge I fear. Last time I tried to call smtp
>> tool by hand it told me not to do so and I took that advice.
>
> /usr/sbin/sendmail -f $(id -nu) -bv 'postm...@example.com'
>
> or via the "posttls-finger" utility from Postfix 2.11 source tarball.

Hmpf. It says "dane configured with dnssec lookups disabled". Seems I need
to fix the RPM first.

[Dirk Stöcker]

On Tue, 25 Feb 2014, Dirk Stöcker wrote:

> Hmpf. It says "dane configured with dnssec lookups disabled". Seems I need to
> fix the RPM first.

No, a

smtp_dns_support_level = dnssec

was enough to fix this. I'll see how many servers will have a "Verified"
connection in the future.

[Viktor Dukhovni]

On Tue, Feb 25, 2014 at 09:57:13AM +0100, Dirk St?cker wrote:

> smtp_dns_support_level = dnssec
>
> was enough to fix this. I'll see how many servers will have a
> "Verified" connection in the future.

I hope you read the note about the importance of having 127.0.0.1
and/or ::1 as the only nameservers listed in /etc/resolv.conf, and
of course the local recursive resolver needs to be configured to
do DNSSEC validation.

With that in place, and with:

smtp_tls_security_level = dane

you'll be able to send validated email to debian.org, nlnetlabs.nl
(the unbound maintainers), Patrick Koetter and personal domains of
some of the members of the DANE working group.

Today, adoption is at 0.00%, but I'm hoping to see the needle start
moving this year.

--
Viktor.

[Patrick Ben Koetter]

* Viktor Dukhovni <postfi...@postfix.org>:

> On Tue, Feb 25, 2014 at 09:57:13AM +0100, Dirk St?cker wrote:
>
> > smtp_dns_support_level = dnssec
> >
> > was enough to fix this. I'll see how many servers will have a
> > "Verified" connection in the future.
>
> I hope you read the note about the importance of having 127.0.0.1
> and/or ::1 as the only nameservers listed in /etc/resolv.conf, and
> of course the local recursive resolver needs to be configured to
> do DNSSEC validation.
>
> With that in place, and with:
>
> smtp_tls_security_level = dane
>
> you'll be able to send validated email to debian.org, nlnetlabs.nl
> (the unbound maintainers), Patrick Koetter and personal domains of
> some of the members of the DANE working group.

Patrick_Koetter =
sys4.de
state-of-mind.de

--
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64

[Dirk Stöcker]

On Tue, 25 Feb 2014, Viktor Dukhovni wrote:

>> smtp_dns_support_level = dnssec
>>
>> was enough to fix this. I'll see how many servers will have a
>> "Verified" connection in the future.
>
> I hope you read the note about the importance of having 127.0.0.1
> and/or ::1 as the only nameservers listed in /etc/resolv.conf, and

No, did not read it, but this was obvious :-)

> of course the local recursive resolver needs to be configured to
> do DNSSEC validation.

Was much easier to do the positive test, than the negative one.

A note to others having the same problem: Resolving www.dnssec-failed.org
(e.g. "dig www.dnssec-failed.org") should NOT result in a answer for the A
record.

[li...@rhsoft.net]

Am 25.02.2014 17:41, schrieb Dirk Stöcker:
> On Tue, 25 Feb 2014, Viktor Dukhovni wrote:
>>> smtp_dns_support_level = dnssec
>>>
>>> was enough to fix this. I'll see how many servers will have a
>>> "Verified" connection in the future.
>>
>> I hope you read the note about the importance of having 127.0.0.1
>> and/or ::1 as the only nameservers listed in /etc/resolv.conf, and
>
> No, did not read it, but this was obvious :-)

why and how should this work for real networks where
you have two DNS servers for failover in the LAN and
typically no one on the mailserver?

if 192.168.196.1 and 192.168.196.2 support DNSSEC it
has to work if both of them in resolv.conf, otherwise
DANE will not happen in the real world

[DTNX Postmaster]

The local resolver can have the resolvers on the LAN configured as
forwarders, but you need the local stub resolver. No reason not to have
one, really, especially on a busy mail server.

Mvg,
Joni

[li...@rhsoft.net]

yes, you normally have a local resolver on the mailserver
but you hardly trust that one alone and in case it crashs
you typically have another one on the LAN

mailserver's /etc/resolv.conf:
127.0.0.1
192.168.196.1
192.168.192.2

[DTNX Postmaster]

If you cannot trust a local resolver by itself, as the only resolver
configured at the system level, you have a different problem that has
nothing to with DANE, or Postfix.

For DANE to work properly and reliable, local only is a requirement.

Mvg,
Joni

[Viktor Dukhovni]

On Wed, Feb 26, 2014 at 12:54:37AM +0100, li...@rhsoft.net wrote:

> > The local resolver can have the resolvers on the LAN configured as
> > forwarders, but you need the local stub resolver. No reason not to have
> > one, really, especially on a busy mail server
>
> yes, you normally have a local resolver on the mailserver
> but you hardly trust that one alone and in case it crashs
> you typically have another one on the LAN

1. In a decade of running BIND caching resolvers of various
antiquities on Morgan Stanley MTAs handling ~2 million
messages a day, I've never seen a local resolver crash.

2. If yours do, arrange for automated re-start and send an alert.

The postmaste master(8) daemon might be killed, which also stops
mail flow. How is that different? The requirement for a local
caching resolver is not a real impediment.

With a caching local resolver, all the DNSSEC validation code is
where it should be, in a DNSSEC application.

If you know how to configure TSIG DNS transport security, you can
use remote resolvers with which you've configured a trusted channel.

If the LAN housing the MTAs and multiple caching nameservers is
physically secure and well firewalled, you could potentially rely
on that physical security and firewall anti-spoofing rules.

All of the above are much more complex than a local validating stub
resolver.

--
Viktor.

[Erwan David]

On Wed, Feb 26, 2014 at 12:46:13AM CET, DTNX Postmaster <postm...@dtnx.net> said:
> On 26 Feb 2014, at 00:29, li...@rhsoft.net wrote:
>
> > Am 25.02.2014 17:41, schrieb Dirk Stöcker:
> >> On Tue, 25 Feb 2014, Viktor Dukhovni wrote:
> >>>> smtp_dns_support_level = dnssec
> >>>>
> >>>> was enough to fix this. I'll see how many servers will have a
> >>>> "Verified" connection in the future.
> >>>
> >>> I hope you read the note about the importance of having 127.0.0.1
> >>> and/or ::1 as the only nameservers listed in /etc/resolv.conf, and
> >>
> >> No, did not read it, but this was obvious :-)
> >
> > why and how should this work for real networks where
> > you have two DNS servers for failover in the LAN and
> > typically no one on the mailserver?
> >
> > if 192.168.196.1 and 192.168.196.2 support DNSSEC it
> > has to work if both of them in resolv.conf, otherwise
> > DANE will not happen in the real world
>

> The local resolver can have the resolvers on the LAN configured as
> forwarders, but you need the local stub resolver. No reason not to have

> one, really, especially on a busy mail server.

However your "local" resolver could be in another jail/zone/container
(depending on your OS) with another IP address and not the loopback.

You could also have an IPSEC link to your resolver to get you trust
you use the right one. This 127.0.0.1 (or ::1) is in my sense too
restrictive, but you need a trusted link between your postfix and your
resolver.

[Viktor Dukhovni]

On Wed, Feb 26, 2014 at 07:43:25AM +0100, Erwan David wrote:

> > The local resolver can have the resolvers on the LAN configured as
> > forwarders, but you need the local stub resolver. No reason not to have
> > one, really, especially on a busy mail server.
>
> However your "local" resolver could be in another jail/zone/container
> (depending on your OS) with another IP address and not the loopback.
>
> You could also have an IPSEC link to your resolver to get you trust
> you use the right one. This 127.0.0.1 (or ::1) is in my sense too
> restrictive, but you need a trusted link between your postfix and your
> resolver.

Yes, of course. In practice, for most users, the local resolver
is by far the simplest configuration.

--
Viktor.

[DTNX Postmaster]

And therefore the most reliable and predictable in the vast majority of
cases, because it is not dependent on ifs and buts. It also has the
smallest attack surface, and is most likely to survive any 'changing of
the guards' over the lifetime of a setup.

Restrictive is a Good Thing, IMO; there's already much of the stack
that is viewed as open for interpretation because people think they
know better, or because someone's edge case was interpreted as
applicable to everything.

So please, let's stick with the clear-cut, restrictive advice; it's
what a lot of people will be digging up from the archives for years to
come, as DNSSEC and DANE go mainstream :-)

Mvg,
Joni

[li...@rhsoft.net]

Am 26.02.2014 02:25, schrieb DTNX Postmaster:
> On 26 Feb 2014, at 00:54, li...@rhsoft.net wrote:
>> Am 26.02.2014 00:46, schrieb DTNX Postmaster:

>>> On 26 Feb 2014, at 00:29, li...@rhsoft.net wrote:
>>>> Am 25.02.2014 17:41, schrieb Dirk Stöcker:
>>>>> On Tue, 25 Feb 2014, Viktor Dukhovni wrote:
>>>>>>> smtp_dns_support_level = dnssec
>>>>>>>
>>>>>>> was enough to fix this. I'll see how many servers will have a
>>>>>>> "Verified" connection in the future.
>>>>>>
>>>>>> I hope you read the note about the importance of having 127.0.0.1
>>>>>> and/or ::1 as the only nameservers listed in /etc/resolv.conf, and
>>>>>
>>>>> No, did not read it, but this was obvious :-)
>>>>
>>>> why and how should this work for real networks where
>>>> you have two DNS servers for failover in the LAN and
>>>> typically no one on the mailserver?
>>>>
>>>> if 192.168.196.1 and 192.168.196.2 support DNSSEC it
>>>> has to work if both of them in resolv.conf, otherwise
>>>> DANE will not happen in the real world
>>>

>>> The local resolver can have the resolvers on the LAN configured as
>>> forwarders, but you need the local stub resolver. No reason not to have

>>> one, really, especially on a busy mail server
>>
>> yes, you normally have a local resolver on the mailserver
>> but you hardly trust that one alone and in case it crashs
>> you typically have another one on the LAN
>>

>> mailserver's /etc/resolv.conf:
>> 127.0.0.1
>> 192.168.196.1
>> 192.168.192.2
>
> If you cannot trust a local resolver by itself

redundancy has nothing to do with trust as well as RAID is not a backup

> as the only resolver configured at the system level, you have a
> different problem that has nothing to with DANE, or Postfix

see above

> For DANE to work properly and reliable, local only is a requirement

if you can not trust your resolvers in the own network you have a
problem and if your localhost resolver does nothing else than
ask these resolvers you gain noting

in case you have a postfix relay on any machine and if you
start to implement DANE network wirde it is nonsense run on
20, 30, 100 machines on top of the same virtualization host
a local resolver asking another VM on the same host

[li...@rhsoft.net]

Am 26.02.2014 07:33, schrieb Viktor Dukhovni:
> On Wed, Feb 26, 2014 at 12:54:37AM +0100, li...@rhsoft.net wrote:
>

>>> The local resolver can have the resolvers on the LAN configured as
>>> forwarders, but you need the local stub resolver. No reason not to have
>>> one, really, especially on a busy mail server
>>
>> yes, you normally have a local resolver on the mailserver
>> but you hardly trust that one alone and in case it crashs
>> you typically have another one on the LAN
>

> 1. In a decade of running BIND caching resolvers of various
> antiquities on Morgan Stanley MTAs handling ~2 million
> messages a day, I've never seen a local resolver crash.

that is not the point, having on every VM running postfix
a local resolver is overkill - that is the point and
redundancy is always a good idea

> 2. If yours do, arrange for automated re-start and send an alert.
>
> The postmaste master(8) daemon might be killed, which also stops
> mail flow. How is that different? The requirement for a local
> caching resolver is not a real impediment.

it is overkill

> With a caching local resolver, all the DNSSEC validation code is
> where it should be, in a DNSSEC application.

which are the two dedicated nameservers in the LAN

http://www.avolio.com/columns/e-mailServerSecurity.html
"Turn off all services except for those required and limit these"

having two *dedicated* nameservers doing nothing else than
DNS and SSH for administartion in the LAN has to be enough

> If the LAN housing the MTAs and multiple caching nameservers is
> physically secure and well firewalled, you could potentially rely
> on that physical security and firewall anti-spoofing rules.

that is the point: if i do not trust my dedicated nameservers
in my own network i can also not trust the one running on
the MTA and asking the both as forwarders

so the only relevant question: is "127.0.0.1 (or ::1)" a hard
requirement or something recommended

> All of the above are much more complex than a local
> validating stub resolver

no - the two dns servers are already in the LAN and working

they are trusted and if i do not trust my own LAN i also can
not trust a forwarder running on 127.0.0.1 asking them

[Wietse Venema]

lst_...@kwsoft.de:

> > Yes, of course. In practice, for most users, the local resolver
> > is by far the simplest configuration.
>

> Is or will this be "enforced" by Postfix in some way for DANE?

Postfix does not parse /etc/resolv.conf.

Wietse

[li...@rhsoft.net]

so can we then stop to pretend having 127.0.0.1 and/or ::1 as the
only nameservers listed in /etc/resolv.conf and speak about that
it is recommended in doubt but not need if someone is knowing
what he is doing in his own trusted network?

[Wietse Venema]

li...@rhsoft.net:

Postfix examples should present simple configurations. Those simple
configurations can then serve as a starting point for more complex
ones. A localhost resolver is a simple configuration. A configuration
with dozens of hosts running Postfix is not simple.

Wietse

[li...@rhsoft.net]

nobody said anything else

but "as the only nameservers listed in /etc/resolv.conf" implies
that the environments with complex setups and working DNS across
the network need to review their complete name resolution instead
implement DANE in the already present nameservers

the problem is the word "only" and this was statet more than once
in the last few months on that list which spreads fear and in doubt
results in "no interest to look at DANE if i have to change and my
review complete network" - i would even go so far and say that the
"only 127.0.0.1 in /etc/resolv.conf" comes near to FUD

[Viktor Dukhovni]

On Wed, Feb 26, 2014 at 10:42:29AM +0100, li...@rhsoft.net wrote:

> > If the LAN housing the MTAs and multiple caching nameservers is
> > physically secure and well firewalled, you could potentially rely
> > on that physical security and firewall anti-spoofing rules.
>
> that is the point: if i do not trust my dedicated nameservers
> in my own network i can also not trust the one running on
> the MTA and asking the both as forwarders
>
> so the only relevant question: is "127.0.0.1 (or ::1)" a hard
> requirement or something recommended

Postfix does not know what is in your /etc/resolv.conf file.
If you use an insecure nameserver (whose replies are subject
to potential spoofing) you get insecure results.

You've been warned. If you think a local resolver is "overkill"
(I disagree) that's your call. Context switching to a process in
the same VM is certainly much cheaper than context switching to a
different VM for exmaple. With a local resolver, the MTA administrator
knows whether it in fact performs DNSSEC validation, and can check
or adjust the trust anchor settings (e.g. to include some non-root
trust-anchors).

> > All of the above are much more complex than a local
> > validating stub resolver
>
> no - the two dns servers are already in the LAN and working
>
> they are trusted and if i do not trust my own LAN i also can
> not trust a forwarder running on 127.0.0.1 asking them

Without an anti-spoofing firewall, remote name servers may be able
to forge DNS replies that appear to come from your LAN. It is not
always obvious whether such protection is in place and is robust.

--
Viktor.

[li...@rhsoft.net]

Am 26.02.2014 17:30, schrieb Viktor Dukhovni:
>> no - the two dns servers are already in the LAN and working
>>
>> they are trusted and if i do not trust my own LAN i also can
>> not trust a forwarder running on 127.0.0.1 asking them
>
> Without an anti-spoofing firewall, remote name servers may be able
> to forge DNS replies that appear to come from your LAN. It is not
> always obvious whether such protection is in place and is robust

in my case the LAN nameservers are not reachable from the WAN at all
and they are doing recursion / caching without any foreign forwarder

the firewall in front of the mailserver does not allow addresses
with a LAN IP coming in trough the WAN interface

that's why I wanted to make clear if the limitation is a
strong technical one or "only" highly recommended

[Viktor Dukhovni]

On Wed, Feb 26, 2014 at 05:40:38PM +0100, li...@rhsoft.net wrote:

> that's why I wanted to make clear if the limitation is a
> strong technical one or "only" highly recommended

Strongly recommended for all but the most determined DIY users who
are at the mercy of their own skills and attention to detail.

--
Viktor.