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

[yaojk <[e-mail]>]

> 在 2015年10月3日，05:33，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.

Thanks for your kind reading.

> 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.  

Any new rrtype based DNS solutions will share something similar because 
They all use the basic DNS feature.
If there is a general mechanism which can works well, why do we refuse it？
Of course, the wg finally decide it.
I also thought of DDDS based solution, but it seems to be more complexity, not easily deployble.

> So I think the flag field is probably not a good idea in its
> own right.

Because there are two kinds of service relationships, one decided by the centralized authority such as PSL, the other decided by themselves , this flag will indicate that information.


>  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).
> 
Some domain names may only share the DNS boundaries for some specific service types such as https service type. So the dbound DNS type is for DNS lookup while the "https " is to confirm that these name will only share the DNS boundaries under the "https" service after the DNS lookup for dbound.


It is the program which deal with it. I do not think that there has something unclear.


> 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 wg can discuss it and decide it.


> 
> 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.
> 


DNS boundaries issues may be more complicated than what We can imagine. We'd better cover most issues appeared or that will appear.


> 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.

If the simple solution can solve everything, that is ok.  If DNS boundaries issue is too complex, we might have to need a complex one.

> 
> Best regards,

The DNS boundaries issue is very important. This draft is for discussion, which may help to trigger a better proposal. I hope that the wg can propose a better solution based on it or not.

Thanks.

Jiankang 
> 
> A
> 
> -- 
> Andrew Sullivan
> [e-mail]
> 
> _______________________________________________
> dbound mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dbound
>