Subject: [Dbound] Richard Barnes' Block on charter-ietf-dbound-00-01: (with BLOCK)

From: "Richard Barnes" <[email-masked]>
Date: Wed, 21 Jan 2015 22:48:42 -0800

Richard Barnes has entered the following ballot position for
charter-ietf-dbound-00-01: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/charter-ietf-dbound/

----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

I find this paragraph really troubling:
"""
The DBOUND working group will develop a unified solution, if possible,
for determining organizational domain boundaries.  However, the working
group may discover that different solutions are needed to solve
different
usage requirements.  Should that happen, the working group will
develop those different solutions, using as many common pieces as it
can.
"""

That says to me that this group hasn't yet figured out a specific problem
that they're solving.  

The inclusion of the "science fiction" use cases in the problem statement
draft doesn't help either.  While the PSL-like cases all seem to hang
together in terms of setting boundaries along hierarchical lines, the
DMARC case envisions "domains that were somehow associated via a policy
authority", which sounds like a facility for associating arbitrary things
across the DNS.  Those two don't sound like part of the same WG to me.

I would like to have some discussion on the call of whether this is
really properly scoped before we send it forth.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 22 Jan 2015 08:08:40 +0100

> http://datatracker.ietf.org/doc/charter-ietf-dbound/

Or that this problem manifests itself in different ways depending on the
application.

Eliot

---

From: Richard Barnes <[email-masked]>
Date: Thu, 22 Jan 2015 08:57:17 -0500

> Or that this problem manifests itself in different ways depending on the

In which case, I would hope that the charter would list the applications
that it's hoping to address and the solution approaches for each case.

--Richard

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 22 Jan 2015 10:37:30 -0500

> That says to me that this group hasn't yet figured out a specific problem

It says that there is a set of problems, all of which are using a
common solution that is inadequate to solve _any_ of them, and the WG
recognizes that it might be that the real solutions to those different
problems might turn out to be different solutions too.  It is simply
false that WGs have to have exactly one specific problem to be solved;
if that were the case, we'd have to close half the WGs in the IETF.  

The specific problem, then, is the PSL and other static lists of the
same sort.  If that mechanism is to be replaced, then we need to
address the different ways people are using it.  And in order to do
that, we might end up with more than one mechanism.  What is wrong
with that?

> across the DNS.  Those two don't sound like part of the same WG to me.

Why not?  The assertion that there is a common policy thread that
links ancestors to descendents in the DNS hierarchy is in practice
wishful thinking.  It isn't even the case that you can practically
enforce the rules that you make up if you're delegating authority over
a subordinate namespace, because to do that you'd have to know what
else was going on under there, and you might not even have access to
the zone in question.  It is true that a superordinate name operator
has quite a lot of power over subordinate names in theory (because the
superordinate operator can remove the subordinate name or the
delegation of the namespace).  But the power, while very strong in one
dimension, is pathetically weak in the other: you don't have a
practical way of knowing.

And cross-tree linkages in the DNS are in fact important if we're
going to use the DNS as an elementary element of security policies.
As more mail operations are outsourced, one needs to be able to apply
security policies of different named entities.  Corporate mergers and
acquitions, as well as name changes, are a fact of life.  The
inability to tell whether two names are related in any way, whether in
an ancestor-descendent relationship or not, is a common issue both
down the tree and across it.  

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Richard Barnes <[email-masked]>
Date: Thu, 22 Jan 2015 11:32:52 -0500

On Thu, Jan 22, 2015 at 10:37 AM, Andrew Sullivan <[email-masked]>
wrote:

> common solution that is inadequate to solve _any_ of them,

Is this really true?  Are people using static lists to encode delegations
across the tree?

> and the WG

I'm not saying there has to be exactly one, but I hope we share the
objective of not leaving open ratholes for the WG to fall into.

> that, we might end up with more than one mechanism.  What is wrong

What are these other static lists?  The only thing I see listed in the
charter or the problem statement is the PSL.

> down the tree and across it.

I think where we disconnect here is that to me, it does seem like there is
a Really Big Difference between talking about delegations down the DNS
hierarchy and delegations across the tree.

When you're talking about the DNS hierarchy, you're adding metadata to an
existing delegation system.  The relationship is already defined -- parent
delegated part of the zone to child.  The delegation relationships already
exist, and we're just adding a bit of information about the degree of
delegation that has occurred.  This seems tractable.

Talking about arbitrary association of DNS names is a very different
question.  Now you have to talk about what sorts of relationships you want
to encode, which plunges you into a whole world of application-layer
semantics.  I want to delegate my email to Provider X, but not my web or
XMPP services.  Do I use this DBOUND thing, or can I only delegate the
whole domain with that?  This seems like a very deep and attractive rathole.

It seems like the PSL / within-the-tree case is well understood and
described in the charter, and the only "across-the-tree" stuff is the one
hand-wavy paragraph in the problem statement.  (Seriously, "somehow
associated"?)  Can that part simply be excised for now, and maybe brought
back in a re-charter when there's a clearer idea of what "somehow
associated" means?

--Richard

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 22 Jan 2015 11:50:21 -0500

> Is this really true?  Are people using static lists to encode delegations

You can't do delegations across the tree (if we mean the same thing by
"delegations").  But DMARC basically waves its hand about this
problem, even though it seems to be critical for its operational
model.  And certainly, CAs spend an awful lot of time (or, anyway,
charge one a pile of money and claim to spend time on this effort)
developing a picture of how different names are related to one another.

> charter or the problem statement is the PSL.

Suzanne and Jothan suggested language to fix that, because the PSL is
the most visible one but others are maintaining their own.  Certainly
some CAs have claimed to have their own private lists.
 
> hierarchy and delegations across the tree.

That's because you think this is related to delegations.  It's _not_.
Dyndns.com makes no delegations, and yet it is a "public suffix" and
names beneath it are officially unrelated to one another.
Blogspot.com is in the same boat.  Hkg1.afilias-nst.info and
yyz1.afilias-nst.info are different delegations (there's an SOA at
each) and are yet completely within the same administrative control
and in fact represent pieces of the very same sub-organization's
internal hierarchy.  The DNS hierarchy is _accidental_ to this
problem; that was the original sin in the Netscape cookies
specification.  

> semantics. 

I am claiming, and have been claiming for some time, that the
inference from the parent-child relationship is _exactly_ the mistake,
and in any case it doesn't help you with things like anti-abuse in
messaging because the location in the hierarchy isn't necessarily
"parent."  So you actually have all this application-layer semantics
already, and we're just pretending it's not there.

> I want to delegate my email to Provider X, but not my web or

And we had a discssion about it in the past, and will need to talk
about it over again, but SRV records and other such friends already
give us some hints about the way to proceed.

If the goal is to get a sentence in the charter that basically says,
"The WG will maximise its use of existing techniques," I'm all on
board for it.

> It seems like the PSL / within-the-tree case is well understood and

Apparently not, or you wouldn't be focussing on delegation.  (This
very confusion, which is astonishingly resistant to correction, is
indeed a serious problem.)

> back in a re-charter when there's a clearer idea of what "somehow

I've already removed this notion repeatedly from drafts I've written
about this topic, because people keep insisting it's too complicated.
Later, it turns out that people realise that they already have the
problem, and so it reappears.  I'm happy to remove it again, though,
if it will make you and others happy.  I predict it'll be back, but
I'm certainly not devoted to it.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Thu, 22 Jan 2015 08:57:00 -0800

On 1/22/2015 8:50 AM, Andrew Sullivan wrote:
> model.  

Sorry, but I have no idea what aspect of DMARC you are referring to as
being across the tree and critical for its operational model.

Please clarify.

The only part of DMARC that is normally considered part of this topic is
its need to identify the organizational domain, which is strictly and
up-the-hierarchy construct.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 22 Jan 2015 12:12:17 -0500

> being across the tree and critical for its operational model.

Good, then I'm wrong and we can remove that.  The text we have
(indeed, the very item Richard is complaining about) came off this
mailing list, and Jeff put it in the problem statement draft:

       DMARC'ss requirement for
      Identifier Alignment between SPF-authenticated domain, DKIM
      d=domain, and a message's From: domain could be relaxed to include
      domains that were somehow associated via a policy authority.  This
      capability would be *very* nice to have at hand.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Thu, 22 Jan 2015 12:25:54 -0800

>       capability would be *very* nice to have at hand.

It's entirely reasonable as a component of a think-piece.  All sorts of
possibilities for dealing with that issue in DMARC have been floated.
To my knowledge none has been tested and certainly not at scale.

So as for knowing what will work best -- or even work at all, in
practical terms -- I believe there is no operational basis for certitude.

Hence the assertion "critical for its operational model" is what caused
my confusion.

d/

---

From: Barry Leiba <[email-masked]>
Date: Fri, 23 Jan 2015 16:01:09 -0500

Andrew and Richard: Can you work out some text that maintains the
flexibility that the working group needs, while making it clear to
Richard what is and isn't in scope, and what the tools are to keep
things from ratholing or going off the rails?

Barry

---

From: Richard Barnes <[email-masked]>
Date: Tue, 27 Jan 2015 11:08:21 -0500

Eliot and I had a chat about this during a coffee break at the SEMI
workshop.  I think I understand the shape of things better now.  Would it
be accurate to state the goals of the WG in the following way?

* Break associations: In cases where one might think two names might seem
to be related (i.e., sub-domains), create a way for clients to learn that
they are not related.
* Make associations: In cases where two names are not otherwise related,
create a way for clients to learn that they are related.

One additional critical requirement that doesn't seem to me to show up in
the charter is that the notion of "related" here is going to need to be
defined, and that definition is going to need to be scoped.  For example,
two domains might be related in the sense of being considered equivalent
for purposes of DMARC, but not for purposes of web origin checks.

It seems to me that it would be helpful for the goals in the charter to be
phrased in the above form.  If people think that this aligns well with what
the WG is thinking, I would be glad to help craft text.

Does that make sense?

--Richard

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 27 Jan 2015 11:27:22 -0500

Hi,

I rather like this way of stating things; thanks.  I think in
addition, the WG has more or less determined that the first
relationship it will work on is "public suffix list", and the problem
that you've been finding frustrating is exactly that it turns out the
PSL is used for more than one thing, and we simply are not certain
whether they are all one type of relationship (but we suspect pretty
strongly that they're not -- see John Levine's quite clear account of
this).

What I can't tell from your note is whether you require the charter to
scope these notions of "related" or whether you think it would be ok
for the WG to form and have as its first item sorting out different
scopes.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Richard Barnes <[email-masked]>
Date: Tue, 27 Jan 2015 11:30:07 -0500

> for the WG to form and have as its first item sorting out different

I think it would be sufficient to just say, that "related" is not a unitary
concept, and that there will be different flavors of relationship.

--Richard

> > > >> I think where we disconnect here is that to me, it does seem like
> there
> > > is
> > > >> question.  Now you have to talk about what sorts of relationships
> you
> > > want

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 27 Jan 2015 12:00:06 -0500

> concept, and that there will be different flavors of relationship.

Excellent.  I think this was exactly the difference we were having
before, and I'm glad we now agree that it's part of the work for the
WG, not pre-WG.  Thanks!

A

-- 
Andrew Sullivan
[email-masked]

---

From: Richard Barnes <[email-masked]>
Date: Tue, 27 Jan 2015 17:30:55 -0500

> before, and I'm glad we now agree that it's part of the work for the

Great.  I do think some text refactoring is necessary here, though.  Let me
know when you've got a proposal.

--Richard