Subject: [apps-discuss] Comments on draft-sullivan-domain-policy-authority

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 19 Jul 2013 11:48:29 -0700

As someone who's involved in email authentication work, identifying the
apex of authority given an arbitrary domain name has long been a valuable
goal.  The current way to do this (the public suffix list) is undesirable,
but it's currently the only way to do this.

This draft proposes a new solution to this problem and also takes into
scope several other related problem statements.  It does a very good job
describing the problem spaces and also is very up front of its various (and
in a couple of cases, daunting) limitations.  I'd love to be part of a
conversation that talks about how to mitigate some or all of those.

One thing it doesn't mention is that it will require a SOPA record to be
created at every extant node in the DNS tree for a domain that wishes to
make use of it.  Unless I've misread something, the document does indicate
that a node can indicate it is in the same policy realm as all of its
descendants, but it also says this relationship needs to be confirmed to be
believed.  That means all of the descendant nodes also have to have SOPA
records pointing back to that parent node.  If I'm understanding that
correctly, the document should probably call this out as a constraint as
well.

There's another related document, draft-levine-orgboundary, about which
I'll comment separately.  I wonder, though, since we have time on the
APPSAWG/APPAREA agenda, if the authors of both drafts would be interested
in talking to that audience about their ideas in Berlin.

-MSK

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 19 Jul 2013 12:00:49 -0700

On Jul 19, 2013, at 11:48 AM, Murray S. Kucherawy <[email-masked]> wrote:

> There's another related document, draft-levine-orgboundary, about which I'll comment separately.  I wonder, though, since we have time on the APPSAWG/APPAREA agenda, if the authors of both drafts would be interested in talking to that audience about their ideas in Berlin.

+1. Fortunately, both authors will be in Berlin.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 19 Jul 2013 15:45:23 -0400

Hi,

> correctly, the document should probably call this out as a constraint as

In the inclusion case, yes.  

This is an unhappy consequence of my worry about certain security
implications of the relationship, but thinking about it after John
Levine made the same argument to me off-list I'm wondering whether we
just need to invent a new relation class that asserts "mail policy
apex", which can assert mail control over everything beneath it.  The
problem with this is the same security problem we have with just doing
inclusion without a corresponding inclusion record at the target.
However, as several people have argued, a parent has the ultimate
authority to redirect the name, so maybe the best way to handle this
is just contracts.

> in talking to that audience about their ideas in Berlin.

I'm prepared to discuss this if others think it would be useful.

Best, 

A

-- 
Andrew Sullivan
[email-masked]