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

From: Andrew Sullivan <[email-masked]>
Date: Fri, 2 Oct 2015 17:33:21 -0400

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
[email-masked]

---

From: yaojk <[email-masked]>
Date: Sat, 3 Oct 2015 19:10:09 +0800

> 在 2015年10月3日，05:33，Andrew Sullivan <[email-masked]> 写道：
> 
> Hi,
> 

Thanks for your kind reading.

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

> domain name itself, so explicitly including data for it in the DNS

The wg can discuss it and decide it.

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

> && propagation && RRSIG validity && policy validity.  I think they

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
> [email-masked]
> 
> _______________________________________________
> dbound mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dbound
>

---

From: manning <[email-masked]>
Date: Sat, 3 Oct 2015 04:31:49 -0700

Just one comment for now.

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

The only two types are me and everyone else.  There is no centralized authority per se.   I can serve data authoritatively or I can serve data received from others.    The DNSSEC validation model tracks the authoritative source of the data.   Given these, I can see no value to flags.

/bill

---

From: yaojk <[email-masked]>
Date: Sat, 3 Oct 2015 23:40:29 +0800

> 在 2015年9月30日，03:25，Daniel Kahn Gillmor <[email-masked]> 写道：
> 
>> On Tue 2015-09-29 05:06:23 -0400, Jiankang Yao <[email-masked]> wrote:
>> 
> [...]
>> Name: draft-yao-dbound-dns-solution
>> Revision: 00
>> Title: Resource Record for DNS Administrative Boundaries
>> Document date: 2015-09-28
>> Group: Individual Submission
>> Pages: 11
>> URL:            https://www.ietf.org/internet-drafts/draft-yao-dbound-dns-solution-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-yao-dbound-dns-solution/
>> Htmlized:       https://tools.ietf.org/html/draft-yao-dbound-dns-solution-00
> 
> Thanks for working on this!
> 
> I did a quick read of this draft, and i think i am confused by it. :(

Thanks a lot for your kind reading and comments. 

The dbound issue is complicated. So the solution proposed is also a little complex.  It can easily cause confusion by First reading. :)

> 
> I have three main confusions that i would try to clear up before
> thinking more deeply about the draft:
> 
> Ancestry vs. Policy
> -------------------
> 
> This draft proposes a single mechanism that can work for zones scoped by
> both ancestry and policy.  It's not clear that the same mechanism should
> be used for both of these distinctions.  furthermore, your ancestry
> mechanism appear to only support bilateral policy agreements -- A must
> point to B and B must point to A.  The usual ancestral relationships are
> that foo.bar.example and qux.bar.example both use bar.example as their
> administrative boundary.  The proposal here, even if i'm
> misunderstanding the part that appears to require bilateral policy, at
> least requires an a DBOUND RR for each DNS record looked up.  This would
> massively inflate the size of most zones.  A decision based on ancestry
> might be much easier to find with simple up-walking approach: for
> foo.bar.example, look for a DBOUND record for foo.bar.example, then if
> that's NXDOMAIN, look for bar.example.
> 
> The consensus i heard in the room in Prague was that trying to solve
> both ancestry and policy relationships with the same mechanism smells
> overly complex.  Maybe it would be better to start with a proposal that
> handles only one of them?
> 
> 

> Ancestry vs. Policy

Ancestry and policy can add more complex issues to dbound solution. I think that this topic might need more discussion before finding out a good solution.

> Target Names: URL vs other DNS label?
> -------------------------------------
> 
> The URL approach seems very underspecified.  What sort of URLs should be
> retrievable by an implementation?  what should an implementation do with
> the retrieved data?

The url is the one which is to be agreed by both names. The url may be a famous one such as PSL or any private one which is just agreed by some names.

> 
> I think it would be better to just think about stating the existence of
> some type of policy boundary in the DNS, without trying to spec out the
> structure of all possible policies that could have boundaries in the
> DNS

Your proposal is one kind of choices. Special one VS General one

> 
> 
> Expirations vs. DNS TTL (and RRSIG)
> ----------------------------------
> 
> DNS records already have a TTL (and DNSSEC records have the
> inception/expiration of the RRSIG).  This draft introduces new
> additional inception/expiration timestamps.  how do all these timestamps
> interact with one another?

I think that the dbound-aware application should store the rdata part of dbound record as the propriety of the names or the stable information. So the dnssec's timestamp has nothing relationship with dbound's timestamp. 

That means that the information extracted from the rdata of dbound will still keep available even if dnssec rrsig expires.
> 
> 
> 
> 
> Other smaller notes from my read-through
> ----------------------------------------
> 
> * the correct URL for the canonical web view of the PSL these days is
>    probably:
>    https://github.com/publicsuffix/list/blob/master/public_suffix_list.dat
> 
> * IANA considerations include "Dbound Public Service" -- it's not clear
>   how this relates to the rest of the draft
> 
> * IANA considerations would probably need a registry of acceptable
>   values for the Flag and Relation fields, or you should replace those
>   fields with bits drawn from a bitmask.
> 
> * section 4 describes "Relation" as "reserved for future use", but also
>   describes more than one value.  These seem incompatible.
> 
> * It's unclear how the variable-length service type field is delimited
>   from the later fields of the record.
> 
> * RFC 2119 language in section 5 seems wrong -- these SHOULDs do not
>   apply to actions taken by implementations.
> 
Thanks for your careful reading and suggestions. 

Jiankang 

> All the best,
>   --dkg

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Oct 2015 21:00:37 -0400

> If there is a general mechanism which can works well, why do we refuse it？

I think the point I was trying to make was that I don't think we have
any evidence yet that there _is_ a general mechanism that works well.
In this particular case, I don't think it's specified well enough for
me to evaluate.  But in the case I worked out before, I concluded
pretty quickly that it was too general to be deployable.  That's why I
abandoned that approach.
 
> 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.

No, I claim these are not two kinds of service relationships.  I think
what Bill said is right.
 
> 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…

But my point is that this approach is _totally incompatible_ with
everything that people already do in this space.  That was the
feedback I got when I tried the same thing.  It was nearly two years
ago, if I recall correctly, but it was discussed at length both in the
APPSAWG meeting and also on the W3C websec list. 

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

Yes, it's perfectly clear.  But I claim it's not going to work.

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

If you can show a use case, I'll be interested.  I'm not partial to
solutions to problems we can't describe because we haven't imagined
them yet.  We have problems we can describe: let's solve those.

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

But the inception and expiration fields are terribly dangerous, as
already demonstrated by DNSSEC.  You need to show why they're needed.

A
-- 
Andrew Sullivan
[email-masked]

---

From: yaojk <[email-masked]>
Date: Mon, 12 Oct 2015 23:37:36 +0800

> already demonstrated by DNSSEC.  You need to show why they're needed.

For example, a user has 2 domain names, a.com and a.net which have applied CA certificates with some expired date. The user would like to configure the same DNS boundaries for these domain names under the https service during the validity period of CA certificates.
The valid period is from the maximum (inception of both domain name certificates) to minimum (expiration of both domain name certificates)

---

From: "Jiankang Yao" <[email-masked]>
Date: Tue, 13 Oct 2015 11:47:56 +0800

From: Andrew Sullivan
Date: 2015-10-08 09:00
To: dbound
Subject: Re: [dbound] Fw: New Version Notification for draft-yao-dbound-dns-solution-00.txt

>No, I claim these are not two kinds of service relationships.  I think

Now, with the new gTLD program, it is very likely that a company applies some names from different gTLD for the same purposes.
if one company has dozens of domain names which are supposed to share the same dns boundaries, for example, domain anmes, n1, n2, n3, n4, n5, ......,
if there are centralized mechanism, the dns administrators might need hundreds of DNS SOPA records for constructing pairwise relationship between any 2 of these  dozens of domain names.
configuration examples:
n1-->n2
n1-->n3
n1-->n4
n1-->n5
......
n2-->n1
n2-->n3
n2-->n4
n2-->n5
........
n3-->n1
n3-->n2
n3-->n4
n3-->n5
.......

if there is a centralized mechanism, all these domain names n1, n2, n3, n4,n5 may agree to get the same policy from PSL or some some private URL (controlled by the comany itself).
n1, n2, n3, n4,n5 may use one dns record to point to PSL or private URL where some policy information is available.

n1-->URL
n2-->URL
n3-->URL
n4-->URL
n5-->URL
.....

so if there is a centralized mechanism(public or private control), it is easy for dns administrators to manage these dns boundaries.  Building cross relationship betwee any 2 of the domain names is for small number of domain names, for example 2 or 3 domain names.

Jiankang Yao

---

From: yaojk <[email-masked]>
Date: Tue, 13 Oct 2015 22:15:39 +0800

> 在 2015年10月13日，11:48，Jiankang Yao <[email-masked]> 写道：
> 
>  
>  
>  
> From: Andrew Sullivan
> Date: 2015-10-08 09:00
> To: dbound
> if there are centralized mechanism

Oops, "if there are centralized mechanism"
Should be:

"if there are no centralized mechanisms"

> , the dns administrators might need hundreds of DNS SOPA records for constructing pairwise relationship between any 2 of these  dozens of domain names.
> configuration examples:
> n1-->n2
> n1-->n3
> n1-->n4
> n1-->n5
> ......
> n2-->n1
> n2-->n3
> n2-->n4
> n2-->n5
> ........
> n3-->n1
> n3-->n2
> n3-->n4
> n3-->n5
> .......
>  
>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 13 Oct 2015 10:34:40 -0400

> The valid period is from the maximum (inception of both domain name certificates) to minimum (expiration of both domain name certificates)

I was afraid you were claiming something like that.  I don't think
this mechanism should be attempting to override anything from the
X.509 certificate and I think if we try that we are bound to make
things much more fragile.  The expiry times are already part of the
certificates.  Don't try to do something tricky with that via the DNS.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 13 Oct 2015 10:37:39 -0400

> if there are centralized mechanism, the dns administrators might need hundreds of DNS SOPA records for constructing pairwise relationship between any 2 of these  dozens of domain names.

I suspect that "hundreds" is overstating the case (if we really have
hundreds of such names, it's pretty clear the DNS is finished anyway),
but yes.  That is the sort of trivial thing that an uncomplicated
script in Python or something similar can handle, and it allows
pairwise checking that both sides of the relationship agree.

> if there is a centralized mechanism, all these domain names n1, n2, n3, n4,n5 may agree to get the same policy from PSL or some some private URL (controlled by the comany itself).

If you really want the URI approach, then I think you should ditch
other mechanisms instead.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Jiankang Yao" <[email-masked]>
Date: Wed, 14 Oct 2015 09:13:19 +0800

From: Andrew Sullivan
Date: 2015-10-13 22:37
To: dbound
>> if there are no centralized mechanism, the dns administrators might need hundreds of DNS SOPA records for constructing pairwise relationship between any 2 of these  dozens of domain names.
>
you may mis-understand it here.
I mean that we need to configure hundreds of DNS records instead of hundreds of names.
For a number of N domain names, we need to configure (N-1) dns records for each domain name.
so for a number of N domain names which need to be configured to share the same dns administrative boundaries, there might have N(N-1) DNS records in total.

for 10 domain names, there need 10*(10-1)=90 DNS records
for 20 domain names, there need 20*(20-1)=380 DNS records

Jiankang

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 13 Oct 2015 18:59:23 -0700

On Tue, Oct 13, 2015 at 7:37 AM, Andrew Sullivan <[email-masked]>
wrote:

> > if there are centralized mechanism, the dns administrators might need
> hundreds of DNS SOPA records for constructing pairwise relationship between
> any 2 of these  dozens of domain names.
>

All of the companies that I have worked with and for (except for when the
internet was really small) have had hundreds or thousands of domains. Many
are defensive, but still it's pretty standard these days and it does not
seem to be stressing the DNS beyond the limits of reason.

--Kurt Andersen

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 14 Oct 2015 14:28:52 -0400

> you may mis-understand it here.

No.

> I mean that we need to configure hundreds of DNS records instead of hundreds of names.

Yes.  But why would anyone have even 10s of names that share a
boundary this way?  In the SOPA draft, if you're just trying to say
"I'm a public suffix" you can say that without a two-way relationship.

> For a number of N domain names, we need to configure (N-1) dns records for each domain name.

But if N isn't a small number, I claim, the mechanism will be useless
as a foundation for security policy anyway.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 14 Oct 2015 14:30:30 -0400

> seem to be stressing the DNS beyond the limits of reason.

Sure, but most of them are in fact parked.  They don't need this
mechanism at all.

If you actually needed to operate even dozens of web servers as though
they were tightly linked to one another, it'd be a pain.  If you
actually just redirect them all to the same place, I can't see why
you'd need the mechanism.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Kurt Andersen <[email-masked]>
Date: Wed, 14 Oct 2015 11:58:34 -0700

> you'd need the mechanism.

Sadly, some of the companies thought that using a vanity domain for every
product (both web and email) was a good idea :-(

--Kurt