Subject: [dnsext] Charter discussion - Use of DNSSEC in applications

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 30 Jul 2010 12:16:48 -0400

One issue missing from the charter is the question of use of DNSSEC in
applications. I think that this is an area that has to be looked at
very carefully, even if the result is an RFC that says 'bad idea'.

In particular, now that we can start to assume that there is going to
be a DNSSEC capability we can think about moving network configuration
data out into the DNS as a matter of course.

I would like to see documents of the type 'how to easily and securely
hook up a mail client to a server by means of DNSSEC secured RRs'.
Part of that effort may be something that the application concerned
has to deal with, but I see a need for additional DNS RRs and I would
like the approach taken by email and the web and jabber to be
relatively consistent.

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

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 30 Jul 2010 10:09:55 -0700

> very carefully, even if the result is an RFC that says 'bad idea'.

Actually, its the exact opposite, its not just a brilliant idea, but the only real use:

DNSSEC for securing name->address mappings is worse than useless: its actually dangerous to network stability (I'll spare everyone a repeat of my long rant on the subject).

The real use for DNSSEC is for DNSSEC-aware applications to obtain through the DNSSEC "PKI" a name->(key material/fingerprint/certificate) mapping which has two substantially better properties than ALL other widely deployed PKIs:

1:  There exists only a single path of trust that can produce a compromised certificate (Contrast this with SSL where there are 66! certificates in Firefox, ALL of which are equally trusted!).  This is a huge issue when SSL sniffers that rely on a cooperative CA are commercially available.

2:  All these PKIs overcharge for wildcard certificates.  EG, even GoDaddy, king of undercut, cut rate pricing, charges $200 for a wildcard certificate for a domain!  DNSSEC is designed to give wildcard certificates, so DNSSEC eliminates a huge amount of price gouging on the part of PKI vendors.  Not to mention, by being wildcard certificates, this makes multihosting cryptographic services much easier.

This is, in the end, the beauty of DNSSEC: it is a cheaper to use (free wildcarding) AND more secure (only one path of trust rather than dozens/hundreds) PKI when compared with the alternatives, 

> like the approach taken by email and the web and jabber to be

RRSET for (self-signed, PKI'ed, either one) X509 certs secured by the DNSSEC ZSK.  

Thus a DNSSEC-unaware application can fetch the X509 cert and treat it like any other cert, but a DNSSEC-aware and validating application can not only fetch but fully validate the signature chain.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 30 Jul 2010 17:08:59 -0400

Folks who have actual security concerns may not be satisfied with a
model that only provides one root of trust.

That is why there is a requirement for guidance to app writers.

Since I am an employee of a CA, I am not going to comment on the issue
of pricing except to point out that the assumption this is a
competitive threat is misguided and creates needless antagonism.

At the moment we have a world where only a tiny proportion of Internet
traffic uses encryption but Third Party issued certificates are used
for the vast majority of those transactions. Let us imagine that we
have a world where it becomes really easy to use cryptography and
cryptography is now used for the vast majority of Internet
transactions and Third Party Issued certs are only required for a
minority of purposes. The number of Third Party issued certs would
likely be considerably higher in the second case than the first even
so.

In my view of PKI security, the only case where a single root of trust
is acceptable is when I choose the root.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 30 Jul 2010 18:18:01 -0400 (EDT)

> Thus a DNSSEC-unaware application can fetch the X509 cert and treat it like any other cert, but a DNSSEC-aware and validating application can not only fetch but fully validate the signature chain.

I'd rather see you extract the public key from the cert and put a hash
of that in DNS. If you then add a new EDNS option for "give me a hash of
pubkey of https service if you have one", we can integrate HTTPS much
better, and without stuffing all these uselesss X.509 fields into the
DNS - avoiding larger packets full of
cruft.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 30 Jul 2010 18:23:04 -0400 (EDT)

> is acceptable is when I choose the root.

This implies of the 66 roots in the browser, you only need to trust one. That's
not the case - you need to trust 66 of them. That does not scale. The federated
DNS approach has a big advantadge. Trust moves from larger to smaller groups,
you can override it at any point for your personal 1 trust anchor, and you are
guaranteed the entire world sees the same view as you, making it extremely likely
abuse or compromise is found really quickly.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 30 Jul 2010 18:55:12 -0400

My point here is related to the charter, there are issues to discuss here.

There are not 66 roots in the browser. There is only one.

Think about it, the root of trust is the selection process for the
browser CA 'roots'. In the case of IE that is a meta-root established
through use of CTLs etc. At the moment that root is chosen for you by
Microsoft or Google and there are certain business constraints there
that are relevant.

What I am saying is choose your own root of trust. Either edit the
root store yourself or have someone you trust to do a good job edit it
for you.

And yes, it is a good idea to do some impedance matching between SSL
and DNSSEC. But all that most people are talking about here is how to
duplicate the function of the lowest tier product, Domain Validated
certs. They do not provide accountability, for that you need an EV
cert.

As I have argued for years, any cert, even an expired self-signed one
is acceptable for turning on encryption in what would otherwise be an
unencrypted channel. Just don't tell the user that it is trustworthy
if it is not.

Lets not restrict this discussion to 'how can we use DNSSEC to replace
the lowest tier in the existing PKI model'.  Rather more interesting
in my view is using DNSSEC to compliment EV certs.

The PKI we have today was originally designed to allow for much, much
more than was ever done with it. The original idea was to use PKI to
secure digital commerce transactions. That is one of the problems that
I would like to return to.

As for whether you put certs or cert hashes in the DNS, my preference
is to allow for both. As a practical matter, it is easier to restrict
the use of DNS to publishing a URI and a hash rather than publish the
full cert since they can be rather large in DNS terms.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 30 Jul 2010 19:41:39 -0400 (EDT)

> There are not 66 roots in the browser. There is only one.

There are 66 CA's that can sign a bogus certificate you will trust
for ANY usage..... It does not much matter its one entity that
originally selected them.

eg see the recent disaster with the signed realtek driver malware.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 30 Jul 2010 20:43:04 -0400

Exactly, the basic problem is that there is one root of trust -- which
you do not control.

This has developed because there are a range of uses for SSL. Some of
which do not need any particular degree of security, others of which
need more. And there is a one-size-fits-all trust management scheme.

You can in fact edit the trust store, if you choose to. But there are
other approaches.

We should be looking beyond SSL and Web browser security.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 30 Jul 2010 20:54:55 -0400

On Fri, Jul 30, 2010 at 12:16:48PM -0400, Phillip Hallam-Baker wrote:
> applications.

It certainly is not missing from the charter in the sense that it is
our problem, and we need to tackle it.

We are narrowly focussed on issues of the DNS protocol.  Nothing about
how applications get to DNS results, &c, are our problem.  Indeed,
they're not even the problem of the _area_ we are in: they're more
likely to be APP than INT.

All of that said, I encourage people who think there are
application-level issues here to submit individual drafts.  If there
were three or four such drafts that talked about application-level
interaction with DNSSEC, it might strike people who are inclined to
try to organize IETF work (i.e. all of us, right?!) that we could take
steps to co-ordinate that work (i.e. form a working group).  Of
course, we already have some efforts in that direction.  But the key
thing, under the current process rules, is to have a manifest
community of interested parties.  Let's see those internet drafts!  I
am sure that, though this sort of work be out of our charter, your
chairs will not object to the occasional announcement about such
drafts.  When it gets heavy, we'll ask for a separate IETF mail list.
Alternatively, ask for one (perhaps M. Sury wull suggest that you
should use the one he is setting up.)

Best,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: [email-masked]
Date: Sat, 31 Jul 2010 02:21:05 +0000

> 1:  There exists only a single path of trust that can produce a compromised certificate (Contrast this with SSL where there are 66! certificates in Firefox, ALL of which are equally trusted!).  Thi…

	this is patently false.  there are at least -two- trust paths. the place
	where they converge is only at the root.

	the one thing that worries me is that trust is not transitive, the DNS admin
	is generally not the sysadmin of the node in question and so syncronization
	between the sysadmin and the DNS admin(s) is an exploitable channel.

--bill

---

From: Jelte Jansen <[email-masked]>
Date: Sat, 31 Jul 2010 12:33:36 +0200

> our problem, and we need to tackle it.

stop pushing more work to this wg :p

> likely to be APP than INT.

hmm, that almost sounds we have the need for a third wg that will never die;
apart from dnsext (protocol), and dnsop (operations), there could be a dnsapp
(how to actually *use* dns, not only in apps but also in other protocols, one of
the reasons this wg was kept alive before more work was dumped on it)

note that I don't think i am a proponent of this approach, but I do think this
is not dns protocol work and is out of scope for dnsext.

> should use the one he is setting up.)

Since this thread so far mostly focused on ssl/tls, let me do that for him:
there has been a meeting on TLS@DNSSEC at IETF78 and it sounds highly relevant
to this discussion, please sign up there if that work is continued :)

As far as TLS is concerned, DNSSEC will only give you assurance that the data
you get really comes from the source the parent zone delegated it to, not who or
what that source actually is. With the way the CA structure has grown, right now
TLS gives you assurance that that source controlled the MX record of the domain
in question at some point in the past (or the mailserver behind it). If you
routinely check the certificate, the issuer, the validation level and the policy
for that level, you might have some more information, but that only works for
interactive activities and is ignored by most people anyway.

So I think DNSSEC can be of big value there, while the market for CA's remains
(albeit perhaps a bit smaller).

It has been mentioned that this goes beyond TLS, and I agree. So perhaps
whatever will come out of Ondrej's initiative should not only be how to use
DNSSEC in TLS, but a more general way that protocols or applications handle
DNSSEC, with TLS being changed to the first protocol that actually implements that.

Jelte