Subject: Re: [dane] [dnsext] Trustworthiness of DNSSEC data

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

On Sun, 2011-06-26 at 20:43 +0000, John Levine wrote:
> > 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.
> 
> Current practice for SSL signers is to scrape e-mail addresses from
> the domain's WHOIS, and send a confirmation message with a URL the
> applicant clicks on.  It's hard for me to imagine a process more
> dependent on the DNS than that.

Not if you asked for paypal.com.  We already went through this on the
dane list
(https://www.ietf.org/mail-archive/web/dane/current/msg02736.html).

> > 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?
> 
> I think the answer to this question is "no".  Let's say, I'm the
> registrant of examp1e.com.

A strange example, given that the schemes I'm talking about address only
the security of interactions with a DNS name given as input and not how
the name is chosen, but sure.

> What, exactly, am I supposed to do to
> persuade the registrar and/or registry that I have established proper
> governance. Or if I suspect that someone else's zone is improperly
> governed, how do I denounce them, and to whom?

Maybe the question wasn't clear.  The registrant (in effect, the holder
of the login information with the registrar, or the WHOIS contacts) is
authoritative for the zone.  The question is whether the zone data
carries the full authority of the registrant.  If she says it does, it
does.  I.e., this would be a box you check on the registrar control
panel, next to where you enter the DS records.

Suppose you're the registrant of myhighvaluesite.com and have special
agreements with your registrar and all the public CAs so they visit your
headquarters before doing anything to your domain.  To cut costs, you
outsource the DNS to your friend.  You figure you might as well enable
DNSSEC too.  But now if clients start to accept DANE positive
assertions, your friend can MITM your customers.

With my proposal, clients would not accept positive assertions from your
zone unless and until you ask your registrar to check the box, and you
wouldn't do that unless you were using a DNSSEC service provider you
fully trust with your site.

-- 
Matt

---

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

> fully trust with your site.

To restate my question: is an opt-in process necessary, or could we just
give registrants with signed zones a deadline to get their house in
order?  If it is necessary, is what I described viable?  Is there an
alternative?  Otherwise we'll never realize the full benefit of DNSSEC.

-- 
Matt

---

From: "John R. Levine" <[email-masked]>
Date: 26 Jun 2011 17:31:06 -0400

[ note to people on the dane list: I just noticed this is cross-posted
  there, so my apologies if this is a dead horse. I'll go read some
  archives before arguing further]

> order?

Who is "we" and how do "we" enforce the deadline?

> fully trust with your site.

I'm trying to imagine the utility of a feature that allows zone managers
to say "well, yes, I signed this, but I was just kidding."  The track
records of policy assertions is not good.  If the plan is that this makes 
it easier to debug your DNSSEC setup, the track record of client-visible 
debug flags is no better.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

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

On Sun, 2011-06-26 at 17:31 -0400, John R. Levine wrote:
> Who is "we"

The Internet community, with IETF playing its customary leadership role.

> and how do "we" enforce the deadline?

It would be enforced in the sense that IETF encourages clients to start
honoring DNSSEC-signed positive assertions on that date and no sooner,
so sites that still have untrustworthy DNSSEC providers will become
vulnerable.

> to say "well, yes, I signed this, but I was just kidding."

Absolutely, this should not be necessary, but in practice it might be
the only way to make a safe transition from the present state, which we
have fallen into as a result of DANE not being on everyone's mind as
DNSSEC was first deployed.  At this point I don't have any data on how
bad the situation is.  I would like nothing better to find out that
nobody is using untrustworthy DNSSEC providers.  But I know if I don't
raise this concern now, the public CAs will.

-- 
Matt

---

From: "John R Levine" <[email-masked]>
Date: 26 Jun 2011 18:20:21 -0400

> The Internet community, with IETF playing its customary leadership role.

Ah. Never mind, then.

R's,
John

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 27 Jun 2011 05:22:13 +0200

On 26 jun 2011, at 23.05, Matt McCutchen wrote:

> But now if clients start to accept DANE positive

Yes, but you did choose your friend as a DNS operator. And you will always be giving your DNS hosting provider that ability.

> fully trust with your site.

You can not ask the registrar to keep track of who is your DNS hosting provider. That has been tried and only leads to problems.

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 27 Jun 2011 05:23:23 +0200

> give registrants with signed zones a deadline to get their house in

My take is that opt-in is not needed. The opt-in happens when zone gets signed and the DS is published in the parent zone.

   Patrik

---

From: Paul Vixie <[email-masked]>
Date: Mon, 27 Jun 2011 03:30:44 +0000

> From: Patrik Fältström <[email-masked]>
> Date: Mon, 27 Jun 2011 05:23:23 +0200
> 
> My take is that opt-in is not needed. The opt-in happens when zone
> gets signed and the DS is published in the parent zone.

+1.