Subject: [dbound] Thoughts and comments on draft-levine-orgboundary-04

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 18 Jan 2016 16:42:19 -0800

After considering both draft-levine-orgboundary-04 and
draft-deccio-dbound-organizational-domain-policy-01
as examples of what was termed during the Yokohama discussion as a "top
down" boundary assertion, I have found it much easier to grok the lookup
sequence from John's proposal than the one in Casey's.

I'm still not sure that I have entirely grasped the nuances and especially
the potential corner-case holes that reside within the algorithm proposed
by Casey and I don't see the benefit of supporting an "offline" mode since
the applicability of the domain boundary lookups is in dealing with online,
real time queries.

Question regarding the text:

The last paragraph of section 2 says "Each domain publishes its own
policies". I take this to mean its own boundaries, but would it be more
appropriate to say "Each ADMD publishes its own boundaries"?

It seems slightly problematic to be dependent on a (potentially
uncooperative) parent domain in order for child domains to be looped into
the BOUND framework. Since SOA is an established mechanism within DNS
management, would it make the mechanism more resilient to follow the SOA
chain before branching off to look for BOUND records?

As a security measure, the failure to lookup a terminating record with a
NOLOWER bit set seems like its interpretation could be application
dependent. In the case of cookies or certs, one may want individual name
isolation, but in the case of DMARC, that would enable attacks rather than
prevent them.

Section 3 (and 10) calls for the applications to be indicated as a lookup
table managed by IANA. Why not just have defined application mechanisms
which could be comma-separated in the record rather than an encoded numeric
value?

In section 5, paragraph 3, the draft reads "the record would indicate no
boundaries. . ." but then the exemplar record is "*._bound.test IN BOUND 0
0 .". Shouldn't that be "*._bound.test IN BOUND 1 0 ." to indicate no
boundaries?

In section 5, regarding the example with municipal boundaries, using
toronto.on.ca, while wildcards work fine for resolving www.toronto.on.ca,
would they also "do the right thing" for the same web site answering to "
toronto.on.ca" or would they force the boundary up to the on.ca level? This
hearkens back to the discussion in the next to last paragraph of section 2
with abc.example.

In section 8, the text refers to "a parent publishing records that shadow
part or all of the boundary record namespace for delegated subdomains,
correct operation depends on the parent and subdomains agreeing about who
publishes what" but does not propose any procedural guidance on what sort
of division of publishing responsibilities might be reasonable

Section 10 (following from the discussion of how to implement as a series
of TXT records in section 9) specifies this as a new RRTYPE. I share
Murray's concerns based on the experience with the SPF RRTYPE that
implementing a new RRTYPE would impede progress on a dbound solution even
more so than our difficulties in achieving consensus on the problem
statement :-)

Nits:

   - Section 4, first sentence is missing an "and": ". . .takes a domain
   name an application. . ."

--Kurt Andersen

---

From: Casey Deccio <[email-masked]>
Date: Tue, 19 Jan 2016 11:11:46 -0500

On Mon, Jan 18, 2016 at 7:42 PM, Kurt Andersen (b) <[email-masked]> wrote:

> by Casey

I'm happy to answer specific questions or better explain concepts that are
poorly presented.

> and I don't see the benefit of supporting an "offline" mode since the
> applicability of the domain boundary lookups is in dealing with online,
> real time queries.
>

Unfortunately, domain boundary lookups are not confined to online,
real-time queries.  For example, for applications with performance
considerations, and/or those which have resource- or network-constrained
environments, online lookups might not be feasible or desirable.  Nor is it
necessarily feasible or desirable for logging or forensic applications.
I'm sure there are other examples.

The context of where we're coming from needs to be understood in designing
solutions in this space: the current solution is an offline file.  While a
solution with an online component is reasonable, closing the door to
offline solutions is not backwards compatible neither in the lookup
process, nor in the behaviors inherent in the process.

Also, this is one of the considerations that was discussed in the Prague
meeting and later mailing list discussion:

http://www.ietf.org/mail-archive/web/dbound/current/msg00502.html

On this topic, I'll be updating my draft (and code implementation) in
coming weeks to flesh out and clarify the offline component, addressing
some of the concerns that have cropped up in that regard.

Regards,
Casey

---

From: "John Levine" <[email-masked]>
Date: 22 Jan 2016 03:27:59 -0000

Thanks for taking a look.

>appropriate to say "Each ADMD publishes its own boundaries"?

It's kind of a chicken and egg problem.  The domain publishes the boundaries
so you know where the ADMD's are.

>chain before branching off to look for BOUND records?

Zone boundaries have nothing do do with these boundaries.  There are
plenty of places where a single organization uses multiple zones for
its internal convenience and others where lots of logically unrelated
domain are in the same zone file and in a few cases the same record.
Consider for example all of the separate blogs at *.blogger.com.

Also, the DNS decided decades ago that the delegation authority flows
down from the root.  If you have a disagreement with your parent domain,
you fix that with money and lawyers, not technical kludges.

>isolation, but in the case of DMARC, that would enable attacks rather than

Sure.  Applications should pick defaults that make sense, and it's
clear the in some cases the safe default is the names are all
different while in others they're all the same.

>which could be comma-separated in the record rather than an encoded numeric

You need a registry either way, to keep the application names or
numbers from colliding as people invent and start to use new ones.

>0 .". Shouldn't that be "*._bound.test IN BOUND 1 0 ." to indicate no

Doesn't really matter, although I suppose the 1 would save a lookup.

>hearkens back to the discussion in the next to last paragraph of section 2

In this case, toronto.on.ca is a boundary like on.ca and ca.  If you
had www.toronto.on.ca that would be an entity with the confusing name
"www" located in Toronto.

>of division of publishing responsibilities might be reasonable

Hm, I thought it was obvious but maybe not.  If the delegated
subdomain is really independent, the parent shouldn't shadow it.  If
they disagree, see discussion about money and lawyers above.

>more so than our difficulties in achieving consensus on the problem

Doesn't make a lot of difference to me either way.  In this case, any
name that contains _bound should only have DBOUND records so the
downside of using TXT is less than it was with SPF where the names
are unprefixed.

>   name an application. . ."

Thx, will fix it if I ever revise it again.

R's,
John