Re: [dbound] Fw: New Version Notification for draft-yao-dbound-dns-solution-00.txt

[Andrew Sullivan <[e-mail]>]

Hi,

On Tue, Sep 29, 2015 at 05:06:23PM +0800, Jiankang Yao wrote:
> Dear all,
> 
>        I submit a draft about dbound solution.
>        any comments are welcome.

Thanks for this contribution.  I've read it, and I have some comments.

It seems to me that this approach is not too dissimilar to a couple of
the earlier approaches I took to the problem.  In
https://tools.ietf.org/html/draft-sullivan-domain-origin-assert-02 I
had two different ways to assert the policy boundaries: either with
names alone, or else with ports and schemes as well.  In
https://tools.ietf.org/html/draft-sullivan-zone-policy-assertions, I
had a target document that included various policies for the zone.

In draft-yao-dbound-dns-solution, there is a combination of these
approaches, AFAICT, such that either the mechanism can do what the
current SOPA draft offers (the one Jeff and I are working on), or else
you can get a policy document from elsewhere.  The features of the
get-document-from-elsewhere part seem to me to be somewhat
underdefined in the draft, so it's hard to know what is intended for
it, but I suspect it shares the same problem that the
zone-policy-assertions draft I wrote did: you could put more or less
anything in the target policy, so it's nearly impossible to understand
what the effects of this mechanism would be, and the ways to express
the policies need to be well worked out in advance.  RRTYPEs are not
that expensive, so we probably don't need a general-purpose mechanism
here.  So I think the flag field is probably not a good idea in its
own right.  I'm also extremely uncomfortable with an RRTYPE that
includes its own subtyping mechanism, because it isn't clear to me
what an application ought to do in case both types are at the same
owner name (which is certainly legal under the DNS).

The relation field seems unnecessary.  The "ancestry" relationship in
draft-deccio-dbound-name-relationships can be read directly off the
domain name itself, so explicitly including data for it in the DNS
seems wasteful.

The service type field got me into trouble when I tried to do this
with draft-sullivan-domain-origin-assert-02.  There are two reasons.
First, this effectively ties DNS RDATA directly to other services,
whereas we've traditionally used the DNS as a lookup device to find
more stuff.  (SRV and related data types already strain this boundary,
and arguably DANE does too, so maybe it's no big deal.)  The bigger
problem, however, is that it involves a new specification of how to
construct (e.g.) the same-origin rules that is totally incompatible
with existing policy-enforcement deployed code.  As a result, it seems
fantastically unlikely to get deployed.

It also isn't clear whether how the proposal can be used in the
absence of the data: it seems to require a lookup at the time
resources are being used.  Anything that involves additional lookups
in real time will simply not fly: the browsers (and mobile device
people) are terribly sensitive to additional latency, lookups, and so
on.  So it needs to offer a way that existing code that uses a
built-in PSL can work.  I can see how one could construct such a list
with this mechanism, but the addition of the service field means that
it won't be a drop-in replacement.  (Without that service field, as
John Levine already noted, this proposal is no different from the SOPA
type Jeff and I suggested.)

Finally, I _really_ dislike the Expiration and Inception fields.  I
get what they're for, and they're attractive in themselves, but
experience with DNSSEC has shown how hard it is to get such values
right in the presence of caches, propagation times in the DNS, and so
on.  I don't even want to think about the timing considerations of TTL
&& propagation && RRSIG validity && policy validity.  I think they
should be shed.

Best regards,

A

-- 
Andrew Sullivan
[e-mail]