Subject: [dnsext] 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: "John Levine" <[email-masked]>
Date: 26 Jun 2011 20:43:51 -0000

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

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

R's,
John

---

From: Phil Regnauld <[email-masked]>
Date: Mon, 27 Jun 2011 09:03:29 +1200

> dependent on the DNS than that.

	That's susually not the case.  Increasingly, SSL issuers will require
	ssladmin@ or hostmaster@ domain to be active.  Still depends on the
	DNS for sending the mail of course.  Assumption is that DNS can be
	trusted for cheap certificates.  EV will require something else.

	And whois, if it's available, is not DNS specific, and may not have the
	email address of the registrant.

	Cheers,
	Phil

---

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

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

> 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

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: 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:
> [ 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"

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.

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

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: 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: "John R. Levine" <[email-masked]>
Date: 26 Jun 2011 18:19:57 -0400

> 	ssladmin@ or hostmaster@ domain to be active.

That's not what I've found, but in any event, as you note sending the mail 
still depends on DNS.

> 	trusted for cheap certificates.  EV will require something else.

It appears to me that for the $99 EV, they scrape corporate registration 
off state DOS websites.  DNS again.

> 	email address of the registrant.

How do you find a WHOIS server other than by looking up its name in the 
DNS?

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.

---

From: "John Levine" <[email-masked]>
Date: 27 Jun 2011 03:30:42 -0000

I get the impression that there are a lot of questions that start with
"well, what happens if ..." to which the answer is "don't do that."

R's,
John

---

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

> "well, what happens if ..." to which the answer is "don't do that."

Sure, but many of those questions:

1. Do not come from people that have experience from running DNSSEC operationally in a registry/registrar/dns hosting provider environment

2. Are theoretical mind games (i.e. not wrong at all, but we have to be realistic)

3. Come from people that do not separate enough theory and practice

4. Creates a correct and good exercise in re-calculation of risk versus benefit, but not more than that (the answer to the calculation is still the same ---> it is better to anchor SSL cert in DNSSEC trust than other trust)

Etc...

Specifically, many of the issues I have seen brought up lately builds on the case that the registrant is completely clueless and explicitly chooses to buy services from someone that intentionally or non intentionally screws up.

I am sorry, but to some degree we can not protect people from doing wrong things. We might be able to minimize the risk third parties are not impacted though. For example, if I screw up with my zone, you should still be able to communicate in a secure way with Paul.

Instead I say that IF the registrant is just clueful enough on getting registrar and DNS hosting service from entities (note, does not have to be the same) so that the zone is signed correctly, then we have "go". There are many other ways a registrant can shoot himself in the foot, or both feet...

And I am in support of systems that first of all helps the ones that DO know what they want.

   Patrik

---

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

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 27 Jun 2011 23:11:26 +0900

Matt McCutchen wrote:

> increase the degree of exposure to malfeasance by the DNS operator

It is merely that PKIs, in general, are untrustworthy, because
trusted third parties (CAs, DNS operators, etc.) are not really
trustworthy.

As you recognize TLS, a PKI, untrustworthy, you hope DNS, another
PKI, can make it trustworthy, only to find that a combination of
untrustworthy PKIs is still untrustworthy.

If you define weak security feeling of security achieved by blindly
believing some infrastructure (CAs, DNS operators, etc.) secure,
PKIs (including TLS and DNSSEC) are merely weakly secure, that is,
as secure as plain DNS.

						Masataka Ohta

---

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: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 27 Jun 2011 11:17:46 -0400

Security is risk reduction, not risk elimination.

Lots of people who comment on PKI and PK based security fail to understand
that fact.

There is no point in spending $100 million to protect an asset worth $1.

And there is little point in protecting the content of political messages if
you don't also have a mechanism to prevent traffic analysis.

The existing PKI was designed to perform a particular task and it has served
that precise function with almost 100% success. I am not aware of any breach
of any PKI infrastructure that has lead to an actual monetary loss. The
losses that we have seen have come from end entity keys being compromised
(e.g. stuxnet)

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 28 Jun 2011 22:49:18 +0900

> Lots of people who comment on PKI and PK based security fail to understand

The important point you fail to understand is that such people
want to have the end to end security not relying on intelligent
intermediate entities such as CAs.

PK is secure end to end, as long as an end obtains a public key
of its peer directly from the peer.

> There is no point in spending $100 million to protect an asset worth $1.

That's exactly why DNSSEC has no point.

> losses that we have seen have come from end entity keys being compromised

With stuxnet, you are saying any server less protected than servers
in nuclear plants will be compromised, which means most PKI is just
insecure.

						Masataka Ohta