Subject: [dane] Trustworthiness of DNSSEC data

From: Matt McCutchen <[email-masked]>
Date: Sun, 26 Jun 2011 15:11:44 -0400

DNSSEC folks,

I'm looking forward to DANE positive assertions making TLS server
deployment significantly more convenient.  More generally, DNSSEC holds
enormous potential utility as a repository of integrity-protected
authoritative information about DNS names, including configuration for
new opt-in security schemes.  However, each of these schemes may
increase the degree of exposure to malfeasance by the DNS operator (who
may not be the same entity as the authoritative holder of the domain) in
some or all cases, compared to traditional practice.  Proper governance
of DNSSEC data to ensure that it reflects authoritative intent is
essential to be able to use these schemes and realize their compelling
benefits.

I would much rather resolve this issue once in a principled way than
come to an unsatisfactory compromise in the context of each individual
scheme.  Is it viable to put registrants with signed zones on notice
that clients will begin to assume the data is fully authoritative, and
give them a deadline by which they should establish proper governance or
revert the zone to unsigned?  Alternatively, do we want a flag in the DS
record (which can only be set by the parent at the registrant's request)
that indicates the data is fully authoritative?

Note well, I propose only to enable the ascription of strong security
semantics to new RR types (or subtypes) such as DANE's TLSA and not to
ascribe new semantics to existing types such as CNAME or CERT, because
then signing a zone could suddenly introduce vulnerabilities.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Sun, 26 Jun 2011 18:17:25 -0400

On Sun, 2011-06-26 at 15:11 -0400, Matt McCutchen wrote:
> Proper governance

To restate, the upshot of DANE and similar schemes to come is that
Alice, a registrant with a signed zone, will need to apply the same
standard of governance to their zones as she currently does to her
relationships with public CAs.  This common standard may be anything
from a subscriber username and password on a sticky note on the monitor
to multiple two-factor-authenticated approvals of each change.

Alice may consider that the best way to achieve the above is to
outsource the DNS to a company she trusts, with an interface for
submitting DNS changes comparable to those for obtaining certificates
from public CAs.  Maybe the company can also get her publicly-recognized
certs for legacy clients; maybe her registrar even provides this
service.  That's great.  But now she will also have the option to manage
the certs herself and still have the world recognize them as
authoritative for her domain.  It's her choice, and thereby the ideal of
DNS delegation will finally be realized with respect to authentication
of TLS services bound to DNS names.

-- 
Matt

---

From: Florian Weimer <[email-masked]>
Date: Mon, 27 Jun 2011 08:30:53 +0000

* Matt McCutchen:

> relationships with public CAs.

This is already a requirement without DANE, and with or without DNSSEC.

There seems to be a persistent myth that DNS is just there and you don't
have to take care.  I don't know where this comes from.  For most
organizations, DNS is an important part of the infrastructure, one of
the things where breakage is widely noticeable to users and beyond.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Florian Weimer <[email-masked]>
Date: Mon, 27 Jun 2011 08:33:28 +0000

* Matt McCutchen:

> deployment significantly more convenient.

Is there any browser vendor buy-in for this type of functionality?

My gut feeling is that this is extremely unrealistic and will not
happen.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 27 Jun 2011 21:04:29 +1200

Florian Weimer <[email-masked]> writes:
>My gut feeling is that this is extremely unrealistic and will not happen.

I was tempted to reply to the orignial message with "And I'm looking forward 
to Cindy Crawford popping out of thin air and falling into my lap.  I guess 
we're both in for some disappointment" :-), but felt I'd wait for someone else 
to say something...

Peter.

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 27 Jun 2011 06:37:45 -0400

> My gut feeling is that this is extremely unrealistic and will not

Chromium accepts stapled CAA-RP RRsets
(http://www.imperialviolet.org/2011/06/16/dnssecchrome.html), and
Mozilla is planning to follow suit
(https://bugzilla.mozilla.org/show_bug.cgi?id=589537).  Hopefully they
switch to the DANE TLSA format when it is standardized.  The stapling is
an important implementation question but irrelevant to the security of
positive assertions.

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 27 Jun 2011 09:13:07 -0400

What I see there is a tracking bug.

Stating that 'Mozilla intends to do X' is pretty much like saying 'IETF
intends to do X', The facts behind the statement can range from one person
involved in the organization intending to do something and an actual
commitment to actual code.

Getting stuff done in browsers is hard. There a billions of them out there.
That is why I still think that Web Services is the place to start. There are
lots of Web Services, there are new ones being developed all the time and
very few of them have any real security model at all.

On Mon, Jun 27, 2011 at 6:37 AM, Matt McCutchen <[email-masked]>wrote:

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

-- 
Website: http://hallambaker.com/