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

["Kurt Andersen (b)" <[e-mail]>]

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