Subject: [dane] DANE works, thanks

From: "A. Schulze" <[email-masked]>
Date: Tue, 09 Jun 2015 18:26:27 +0200

Hello,

Barry Leiba encourage me to write this "it works" message.

We're a ISP in Germany. Since years we run validating DNS resolvers in  
our infrastructure.
Using postfix as MTA any outbound messages benefits from DANE.

OK, the total number of DNSSEC enabled destinations is small. Really small.
But for these destinations we're simply sure we transfer message  
securely to the right receiver.

YES,
  - it works
  - it does not hurt

Thanks for DANE!
Andreas

---

From: Leif Johansson <[email-masked]>
Date: Tue, 9 Jun 2015 18:39:10 +0200

> 9 jun 2015 kl. 18:26 skrev A. Schulze <[email-masked]>:
> 
> 
> Hello,
> 
> We're a ISP in Germany. Since years we run validating DNS resolvers in our infrastructure.
> But for these destinations we're simply sure we transfer message securely to the right receiver.
> 
> YES,
> - it works
> - it does not hurt
> 
> Thanks for DANE!
> Andreas
> 

nice!

> 
> 
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 9 Jun 2015 16:42:57 +0000

> Barry Leiba encourage me to write this "it works" message.

Thanks for the confirmation.

> But for these destinations we're simply sure we transfer message securely to

Still increasing gradually.  I have curated ~1400 domains now, but
only 19 of them are "large enough" to be listed in the TLS statistics
in Google's email transparency report.  That much smaller number
is also rising gradually, just a few months ago it was 13.

I hope that once the SMTP, SRV and "ops" drafts are published RFCs,
the adoption rate will pick up.

It would also be nice to see even fewer of the early adopters
messing up key rotation (forgetting to update TLSA RRs when
replacing certs).

The number of broken domains is only small, because I send alerts
now and then to the domains that get it wrong.  Fully automating this
is on the TODO list, but cycles are scarce.

-- 
	Viktor.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 9 Jun 2015 13:40:00 -0400

> messing up key rotation (forgetting to update TLSA RRs when

Something that I have found is useful for things like this is to inset
a large comment in the MTA config file saying something like:
# *************************************************
# NOTE NOTE NOTE NOTE NOTE NOTE
#
# Don't forget to update the TLSA record
# when replacing this certificate, or you will
# look like a dumdum...
#*************************************************
right above the smtpd_tls_cert_file = (or equivalent) line.

That way I'm (hopefully!) sure to notice and remember...

> now and then to the domains that get it wrong.

Thank you -- this seems to have made a significant difference.

>  Fully automating this

Fair enough,
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 9 Jun 2015 18:06:55 +0000

> a large comment in the MTA config file saying something like:

My inclination is to recommend placing this in the certificate file
itself (PEM certificate files can contain ignored text above the
"-----BEGIN/END...." blocks) as well a CERT_UPDATE_README file in
the directory containing the certificate file and keys.

We can also recommend that the user insert similar text near the
certificate settings infthe MTA configuration file, but we can't
do it for them.  There are too many different tools for managing
the config files.

-- 
	Viktor.

---

From: Sebastian Wiesinger <[email-masked]>
Date: Tue, 9 Jun 2015 21:34:34 +0200

> the directory containing the certificate file and keys.

What would help a lot of people would be a drop-in nagios check which
compares TLSA to actual cert. Probably easy to do for connections
which start with TLS, not so trivial for STARTTLS types of
connections.

Regards

Sebastian

-- 
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
            -- Terry Pratchett, The Fifth Elephant

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 9 Jun 2015 19:48:12 +0000

> which start with TLS, not so trivial for STARTTLS types of

STARTTLS is not difficult to test.

We were thinking of having folks sign up for monitoring by sys4.de,
with the results published via DNS, and nagios can then just do a
quick DNS lookup.

The advantage of a remote monitoring service, is that it can may
see DNS issues that are only apparent from outside the site's own
network.

The remote service can also make it easier for sites connecting
to a domain that has problems to check whether others are also
having the same issue.

This has not moved past the discussion stage yet.

-- 
	Viktor.

---

From: John Gilmore <[email-masked]>
Date: Tue, 09 Jun 2015 13:46:07 -0700

> is also rising gradually, just a few months ago it was 13.

It sounds like the number of domains you have curated using DNSSEC and
DANE is larger than the number of domains on the ARPANET.  And look
what that grew into!

	John   :-)

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 9 Jun 2015 17:00:34 -0400

> On Jun 9, 2015, at 12:42 PM, Viktor Dukhovni <[email-masked]> wrote:
> 

I have some spare cycles to do development. Can I assist?

Tom

---

From: Sebastian Wiesinger <[email-masked]>
Date: Thu, 11 Jun 2015 14:41:27 +0200

> see DNS issues that are only apparent from outside the site's own

I see that but I would prefer to have my monitoring in-house and not
dependent on external services. What DNS issues with DANE would only
be apparent from the outside? Different views? Even so, I have an
external monitoring point running Nagios for exactly these reasons. :)
So for me a nagios check would be better. But perhaps I'll have some
time and do it myself.

Regards

Sebastian

---

From: Warren Kumari <[email-masked]>
Date: Thu, 11 Jun 2015 11:26:35 -0400

> So for me a nagios check would be better. But perhaps I'll have some

If you do, please share it with the list / community. Good / multiple
ways of monitoring is really useful for deployment - one of the things
that has hurt DNSSEC deployment is the public outages - it would be
great to not have DANE suffer from this too.

W