Subject: [dane] List of incidents that DANE would have blocked?

From: William Stouder-Studenmund <[email-masked]>
Date: Wed, 01 Oct 2014 09:37:08 -0700

I learned about DANE recently and was excitedly talking to some operations friends of mine about it. Some of them work in shops that aren’t using DNSSEC yet, and DANE’s requirement of it would trigger push-back from management. *I* think they should be doing DNSSEC, but I’m not management. Making a case for DANE means making a case for DNSSEC.

I get that DANE can detect a large class of MITM attacks. Saying that isn’t as convincing as handing over a list of, “DANE is designed to stop this, DANE would have stopped that one,” and so on.

If the answer is lurking in the list archives, feel free to just point me at a date and I’ll look at that too.

Take care,

Bill

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 2 Oct 2014 02:03:37 -0400

Bill, 
short answer. 

Dane is about placing high value information in the DNS, 
with out DNSSEC that is non-sensical. 

Yes we had this discussion a long time ago (most of second half of  2011), the deciding point was around November 2011. 
starting with this message: 
http://www.ietf.org/mail-archive/web/dane/current/msg03748.html

and this one is a followup to gather consensus
http://www.ietf.org/mail-archive/web/dane/current/msg03864.html

	Olafur

On Oct 1, 2014, at 12:37 PM, William Stouder-Studenmund <[email-masked]> wrote:

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 2 Oct 2014 16:15:41 +0000

On Wed, Oct 01, 2014 at 09:37:08AM -0700, William Stouder-Studenmund wrote:

> Making a case for DANE means making a case for DNSSEC.

Yes.

> I get that DANE can detect a large class of MITM attacks.

No, DANE can public associations between service end-points and
public key material.  Protecting against MITM attacks is a matter
for the protocols that use that key material.  DNSSEC hardens the
lookups of that key material against MITM attacks.

> Saying that
> isn't as convincing as handing over a list of, "DANE is designed to stop
> this, DANE would have stopped that one," and so on.

DANE can enable opportunistic security protocol designs that are
capable of resisting MITM attacks.  This is in use with SMTP and
XMPP.

DANE for the web is some time away.  None of the browsers are
planning DANE support at this time.  My hope is that at some point
in the future the new "h2" URI scheme will support opportunistic
DANE TLS, rather than just opportunistic unauthenticated encryption.

DANE replacing public CAs with "https" seems unlikely so long as
there is perceived value in "EV" certificates.

-- 
	Viktor.

---

From: William Stouder-Studenmund <[email-masked]>
Date: Thu, 02 Oct 2014 10:21:13 -0700

> On Oct 2, 2014, at 9:15 AM, Viktor Dukhovni <[email-masked]> wrote:
> 

Thank you! These are the things I was hoping to hear.

Take care,

Bill

---

From: William Stouder-Studenmund <[email-masked]>
Date: Thu, 02 Oct 2014 10:21:28 -0700

> On Oct 1, 2014, at 11:03 PM, Olafur Gudmundsson <[email-masked]> wrote:
> 
> Bill, 
> short answer. 
> 
> http://www.ietf.org/mail-archive/web/dane/current/msg03864.html <http://www.ietf.org/mail-archive/web/dane/current/msg03864.html>
Thank you!

Take care,

Bill

---

From: Rene Bartsch <[email-masked]>
Date: Fri, 03 Oct 2014 11:38:33 +0200

Am 2014-10-01 18:37, schrieb William Stouder-Studenmund:
> I learned about DANE recently and was excitedly talking to some
> operations friends of mine about it. Some of them work in shops that
> aren’t using DNSSEC yet, and DANE’s requirement of it would trigger
> push-back from management.

Primary nameservers like BIND or PowerDNS generate DNSSEC-resource 
records automagically. All you need to do is to handover your DSKEY/ZSK 
to your domain registry periodically. Usually you just have to 
Copy&Paste the new keys into your registrar's web-interface per quarter, 
half-year or year. Even my private domains are secured with DNSSEC/DANE 
by using a DNS-operator with managed DNSSEC. I only generate the 
TLSA-RRs myself when I change the TLS-certs every two years.

As a quick-start I suggest to use Shumon Huque's web-generator for 
TLSA-RRs (https://www.huque.com/bin/gen_tlsa). To reduce effort of 
changing TLSA-RRs when changing the TLS-certificate you can use CNAMES 
and wildcard-RRs pointing to ONE single TLSA-RR. For client-side I 
suggest a warning message in your shops to encourage users to install 
the CZNIC DNSSEC/TLSA Validator web browser add-on 
(https://www.dnssec-validator.cz/).

Renne

-- 
Best regards,

Rene Bartsch, B. Sc. Informatics

---

From: Warren Kumari <[email-masked]>
Date: Fri, 3 Oct 2014 16:45:44 -0400

On Fri, Oct 3, 2014 at 5:38 AM, Rene Bartsch <[email-masked]> wrote:
> Primary nameservers like BIND or PowerDNS generate DNSSEC-resource records
> automagically.

Yup.

> All you need to do is to handover your DSKEY/ZSK to your
> domain registry periodically.

Yup.

> Usually you just have to Copy&Paste the new
> keys into your registrar's web-interface per quarter, half-year or year.

Which gets annoying *really* fast.
May I introduce you to RFC7344 - Automating DNSSEC Delegation Trust
Maintenance (http://tools.ietf.org/html/rfc7344)

Ask your favorite name server vendor to implement this -- basically it
automates rolling over of your keys, by having the old key introduce
the new one.

W

> Even my private domains are secured with DNSSEC/DANE by using a DNS-operator
> with managed DNSSEC. I only generate the TLSA-RRs myself when I change the
> TLS-certs every two years.
>
> As a quick-start I suggest to use Shumon Huque's web-generator for TLSA-RRs
> (https://www.huque.com/bin/gen_tlsa). To reduce effort of changing TLSA-RRs
> when changing the TLS-certificate you can use CNAMES and wildcard-RRs
> pointing to ONE single TLSA-RR. For client-side I suggest a warning message
> in your shops to encourage users to install the CZNIC DNSSEC/TLSA Validator
> web browser add-on (https://www.dnssec-validator.cz/).
>
>
> Renne
>
>
> --
> Best regards,
>

-- 
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