Subject: [dnsext] Announcing public suffixes as a DNS record

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 1 Feb 2013 11:30:26 -0500

Over the years several people have proposed a record that would be used to
specify a public suffix. For example:

   .com    PUBLIC
   .co.uk  PUBLIC
   .ac.uk  PUBLIC
   .net     PUBLIC

The idea here being to provide a mechanism in the DNS to advertise the fact
that a zone is considered to be a public delegation point and that features
such as Cookies, JavaScript, CA cert issue, etc. can then avoid security
issues that arise from the assumption that the domains A.X.Y and B.X.Y or
X.Y are in the same 'zone of trust'.

DNS deployment constraints mean that it is not possible for applications to
use this information directly as there is no guarantee that the application
will have access to the necessary records. So each application would still
need to maintain a public suffix list but it would be a public suffix list
that can be maintained using an automatic script run as part of the build
process rather than a list that is maintained by hand and in the most error
prone way imaginable.

I do not want to get into a discussion of the design decisions made by
Netscape without any consultation fifteen years ago at this point. The
public suffix list was a design botch then and it is a design botch now. It
is also legacy that we cannot change. The choice therefore is whether we
live with the current situation where there are multiple unofficial public
suffix lists or move to a scheme which at least permits the information to
be published by the authoritative source for the domain in question.

The forcing function that I believe is going to make the current situation
untenable is the introduction of new TLDs by ICANN. I do not believe that
the current system of unofficial public prefix lists with multiple
maintainers is capable of reacting to change. It only works at all because
the changes to the public prefixes have been gradual and most have been
zones that have a two level hierarchy going to a flat TLD scheme.

Has anyone written a draft to propose such a record or is interested in
helping to make such a proposal?

Since the objective is to expose a single bit of information per domain,
the design space is not large. I see only two real design options.

Option 1:

All zones are considered private by default unless the zone publishes
PUBLIC record in that zone which makes it a public delegation point.

Con: This requires all TLDs to comply before the registry is effective.

Option 2:

The PUBLIC record takes an integer parameter as follows:

PUBLIC 0 : Domain is NOT a public suffix
PUBLIC 1 : Domain in which it is published is public suffix, default for
subdomains is not public suffix
PUBLIC 2 : Domain in which it is published is public suffix, default for
subdomains is public sufix

A domain is a public suffix if and only if

* There is a PUBLIC RR with the parameter 1 or 2 published in the domain OR
* There is no PUBLIC RR published in the domain AND (it is a TLD OR the
parent domain has a PUBLIC RR with a parameter of 2)

In the second option it would be sufficient for the small number of second
level public delegation points to publish the appropriate records and for
ICANN to require new TLDs to take the appropriate action if they are
supporting public delegation points at levels lower than the TLD.

The proposal could even be tweaked further to explicitly grandfather
existing domains, though the public suffix list is actually rather large.
Consider the Mozilla version:

http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1

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

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 1 Feb 2013 08:58:01 -0800

On Feb 1, 2013, at 8:30 AM, Phillip Hallam-Baker <[email-masked]> wrote:

> Has anyone written a draft to propose such a record or is interested in helping to make such a proposal?

draft-sullivan-domain-origin-assert deals with the core issue, and does so in healthier way than simply reproducing the Mozilla list (which is often wrong due to insufficient input and validation).

I still would like to see draft-sullivan-domain-origin-assert adopted as a standard.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 1 Feb 2013 12:32:12 -0500

On Fri, Feb 1, 2013 at 11:58 AM, Paul Hoffman <[email-masked]> wrote:

> draft-sullivan-domain-origin-assert deals with the core issue, and does so
> in healthier way than simply reproducing the Mozilla list (which is often
> wrong due to insufficient input and validation).
>

Well it is not just a question of 'the Mozilla list' there are multiple
lists in use maintained separately :(

The idea would be to migrate away from that position and do so by pushing
the responsibility for maintaining these lists onto ICANN and the operators
of large public spaces like blogspot.com

> I still would like to see draft-sullivan-domain-origin-assert adopted as a

Andrew's proposal is essentially the opposite of mine. Instead of
assertions of the form 'this is a gap in the trust model', Andrew proposes
that the default is disconnected and trust is only established if there is
an explicit link.

That is definitely the right way to do this particular feature for
JavaScript if starting from scratch. (OK no the right way is not to do it
at all but..) But I don't see a viable transition strategy from where we
are to where we want to be.

Happy to be proved wrong here...

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 1 Feb 2013 13:01:48 -0500

> helping to make such a proposal?

Yes, and in fact you have commented on it.

http://tools.ietf.org/html/draft-sullivan-domain-origin-assert-02

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 2 Feb 2013 02:02:26 -0500

In case it wasn't clear, no hat.

> are to where we want to be.

I don't see why.  First, it seems to me that it is the only reasonable
security model at all.  Moreover, the mechanism I propose fully
subsumes your proposal, because ICANN and others could make an
equivalent to the PUBLIC proposal you offer, just by publishing a
record that says nobody lives in the same administrative realm.  (This
is the SOPA with root-target record.)  Indeed, the reason I had a
default-don't-trust _plus_ a mechanism to state don't-trust explicitly
was exactly so that we could start out by making such don't-trust
statements; that way, you could "fail hard" on the root-target
statements and still play games guessing with domain names, until the
new mechanism can be adopted widely.  Anyway, that's the intention, so
if it's not clear discussion is welcome.

I was hoping to have that discussion on apps-discuss, mostly because
that's where the consumers of this data are, and previous attempts to
work out this stuff in the DNS community (and then present it to
consumers as finished) have failed.  Maybe we could move this there?
Also, I'd be delighted to have a tag-team discussion of these two
competing proposals in Orlando, if you think it's worth pursuing.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 2 Feb 2013 09:06:14 -0800

+1 to this being a discussion for AppsArea (the consumer of the proposals). It might be worth asking Pete and Barry for some time to introduce the two different approaches to the area in advance of the list discussion.

--Paul Hoffman

---

From: Florian Weimer <[email-masked]>
Date: Tue, 05 Feb 2013 15:15:26 +0100

> specify a public suffix. For example:

ISC recommends a configuration for the BIND resolver which suppresses
such RRs in the COM and NET zones (and others), so it's not clear to
me if such records would make it to clients in practice.

---

From: Chris Thompson <[email-masked]>
Date: 05 Feb 2013 16:38:59 +0000

>me if such records would make it to clients in practice.

This refers (I assume) to the "delegation-only" and "root-delegation-only"
options in BIND. None of that is turned on by default, so "recommends" may
be a bit of an overstatement. The BIND ARM is pretty cautious about them.

You could probably get ISC to exclude a new record type from being converted
to NXDOMAIN by this facility, as (for example) DS records already are.

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 06 Feb 2013 10:23:15 +1100

In message <[email-masked]>, Chris Tho
> to NXDOMAIN by this facility, as (for example) DS records already are.

The delegation-only code does not care what is at the zone apex which deals
with most zone for which people set delegation only.

        /*
         * Enforce delegations only zones like NET and COM.
         */
        if (!ISFORWARDER(query->addrinfo) &&
            dns_view_isdelegationonly(fctx->res->view, &fctx->domain) &&
            !dns_name_equal(&fctx->domain, &fctx->name) &&
            fix_mustbedelegationornxdomain(message, fctx)) {

PUBLIC would also be added to the list of execptions for the case
where the check gets past !dns_name_equal(&fctx->domain, &fctx->name)
check.

> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 10 Feb 2013 14:01:54 -0500

> me if such records would make it to clients in practice.

That is irrelevant because

1) The proposal is designed to allow the parties who maintain public suffix
lists a means of gathering the data rather than this being something
clients would consume directly.

It is not going to be practical for clients to consume this information
directly for a long time.

2) ISC's advice on configuration does not determine the DNS standard. It is
at any rate mutable. So even if it was an issue I would take it as
indicating that ISC should be asked to change their config advice rather
than anything more.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 10 Feb 2013 14:27:33 -0500

Yeah, I knew someone had raised it but could not remember who it was.

> if it's not clear discussion is welcome.

I think it has to be two separate tracks. In the short term we need to do
something to help the maintainers of the public suffix lists while ICANN is
busy increasing the number of TLDs. The objective there is to get the new
TLDs to do no harm and not make the problem worse. This is easiest to do
when the TLD applicants are bidding to get names and most willing to agree
to do things to get their name.

As far as the CA business goes, what we need to know about are the public
delegation points. The security concerns are significant but not quite the
same as for Javascript. In fact the default permit/default deny are
arguably reversed.

Fixing the insane security model for Javascript and cookies would be good
but I see that as secondary and something that will take quite a while to
feed through.

> competing proposals in Orlando, if you think it's worth pursuing.

Yeah lets plan on doing that, I was not sure whether to go to Orlando but
that would be a reason to do it.

I think it is a DNS community discussion, not just apps area as the forcing
function here is the introduction of the new TLDs that will call the
sclability of the existing scheme into question.