Re: [dbound] Which problem do people want to solve? (was Re: BoF request for IETF 115)

[Chris Fredrickson <[e-mail]>]

Hi all,

I'm the maintainer of Chromium's copy of the PSL. In general I agree with
the point that this group needs to clearly agree on the problem(s) before
we can find the appropriate solution(s). From the BoF request and previous
discussions in this group, it appears that managing the growth of the PSL
is/was the primary motivation for discussing DBOUND in this forum.

PSL maintenance has been top-of-mind lately for some of us in the browser
space. We welcome the maintainers (Jothan and Simone) to correct our
analysis; but we think there are a couple of considerations: (1) managing
the increasing growth of the PSL (this has accelerated somewhat due to the
increase in number of ICANN-managed TLDs, but also due to growth in the
private section of the PSL), and (2) making the curation/governance process
more sustainable. It seems like providing an automated way to assert
private domain additions to the PSL is a focus of this discussion.

With that in mind, I have some thoughts:

   1.

   Since the BoF proposal intends to explore the possibility of DBOUND
   serving as a long-term replacement for the private domains section of the
   PSL, we (the community at large) need to understand why people are trying
   to add so many domains to that section, in order to design an appropriate
   solution.
   -

      If the need is about limiting visibility of cookies (e.g. between
      tenants of a cloud provider), we should encourage people to use
and require
      __Host-prefixed cookies, which do not rely on the PSL at all. (The DBOUND
      proposal specifically calls out
      <https://datatracker.ietf.org/doc/html/draft-levine-dbound-dns#section-6.2>
      cookies sent over HTTP(S), so this seems to be at least part of the
      motivation.)
      -

      If the limitations of that approach make it insufficient (i.e. that
      there's no way to enforce tenants' usage of __Host-prefixed cookies),
      browsers could design a new way for servers/documents to opt out of
      everything but __Host- cookies in order to do that enforcement.
      2.

   A DNS-based dynamic-discovery mechanism (like DBOUND) will likely be a
   non-starter for browsers, due to integrity concerns (not to mention latency
   or offline functionality concerns). Browsers rely on the PSL boundaries for
   security features like Site Isolation
   <https://www.chromium.org/Home/chromium-security/site-isolation/>, and
   I'm skeptical that we (Chromium) would be willing to let Chromium clients
   make security decisions based on some unsigned data that they fetched over
   the wire (though I have not yet chatted with our security teams about this).
   -

      We might be more amenable to something like a .well-known file
      fetched over HTTPS (which can benefit from existing PKI/TLS
      infrastructure), but it's not clear what would happen for deployments
      without TLS support. (This could lead to some interestingly inconsistent
      behavior between Secure and non-Secure cookies, I think.) But I haven't
      thought about this too deeply yet; and I think this is getting ahead of
      ourselves, again designing a solution before we understand the problem
      we're trying to solve.
      3.

   A potentially simpler option to consider is to modify the PSL format, to
   introduce some new attribute that tells clients a fact about all subdomains
   under a given suffix - e.g. that every such subdomain should be considered
   a distinct eTLD+1.
   -

      This might work (in terms of making PSL modifications more scalable),
      but has all the same rollout/rollback problems that adding new
names on the
      PSL does, and has very wide-reaching effects, so I don't think
it should be
      our first choice. And again, I want to be sure that we fully
understand the
      reasons for adding to the private section today, before we decide on a
      solution.

Chris

On Fri, Dec 23, 2022 at 7:31 PM Jothan Frakes <[e-mail]> wrote:

> Good thoughts.  Capture all that in the dbound 2 google doc, Tim
>
>
>
> On Fri, Dec 23, 2022, 4:03 PM Tim Wicinski <[e-mail]> wrote:
>
>>
>> When I was thinking out how we would charter a narrower, focused DBOUND;
>> I had several conversations with w3C board members;
>> they weren't going to commit in advance to work with what the IETF
>> "process" produced. I totally understood that.
>> So if we *really* want to create something the W3C can use, should that
>> be the first iteration of what is worked on?
>>
>> Also whatever is created may appear in different output formats - DNS
>> records for some, PSL style files for others.
>> Also, one format should be able to create another format as in the json
>> begats yaml begats toml begats json.
>>
>> I did have a method to create everything using SVCB DNS Records ("SVCB -
>> the TXT records of the 21st Century!")
>> but I was told to stop and that was wise.
>>
>> tim
>>
>>
>> On Fri, Dec 23, 2022 at 5:40 PM Jothan Frakes <[e-mail]> wrote:
>>
>>> Andrew you are 1000% correct.  We need to back up from the tactical
>>> needs of the few here
>>>
>>> The RIGHT way to do this would be to create some means for a domain
>>> owner/administrator to self-express how they would like to have the
>>> internet expect to interact with that domain name.
>>>
>>> The PSL is an inelegant klooge used in accomplishing this, but there are
>>> a number of ways that could be more crisply and clearly defined than in a
>>> text file the way that it is now.
>>>
>>> Here are examples of attributes that should be more deliberately defined
>>> by a domain name admin via such a tool:
>>>
>>> This domain name will have subdomains for others, and is expressing
>>> itself as a new apex (etld+) for nested namespace
>>> This domain name should or should not have cookies itself (or in
>>> subordinate levels)
>>> This domain name wants to co-exist as an alias for these other domains
>>> with respect to cookies (or in subordinate levels)
>>> This domain name should or should not have wildcard certificates issued
>>> (or in subordinate levels)
>>>
>>> Other things that some meta tool / site could provide to configure:
>>> This domain name has DNSSEC, please retrieve it from [nameserver]
>>> This domain name should be treated (or not) with HSTS
>>>
>>> Such a site should be able to easily have resources to help an operator
>>> create the appropriate DKIM or SPF scenarios to place in their DNS.
>>>
>>> This is not an exhaustive list.
>>>
>>> Something that could be covering solutions across all of this would
>>> likely be better received - but it does need to respect the other tech-debt
>>> it might deliver to folks' whose projects/code need updating to make
>>> changes to evolve stuff.
>>>
>>> -Jothan
>>>
>>>
>>> On Fri, Dec 23, 2022 at 10:09 AM Andrew Sullivan <[e-mail]>
>>> wrote:
>>>
>>>> Dear colleagues,
>>>>
>>>> I work for the Internet Society but this isn't their opionion.
>>>>
>>>> I have read this thread and am having an uncomfortable experience of
>>>> déja vu.
>>>>
>>>> On Thu, Dec 22, 2022 at 02:23:53AM -0500, Tim Wicinski wrote:
>>>> >and this paragraph was what I was
>>>> >
>>>> >   What appears to be needed is a mechanism to determine policy realm
>>>> >   boundaries in the DNS.  That is, given two domain names, one needs
>>>> to
>>>> >   be able to answer whether the first and the second are either within
>>>> >   the same policy realm or have policy realms that are related in some
>>>> >   way.  We may suppose that, if this information were to be available,
>>>> >   it would be possible to make useful decisions based on the
>>>> >   information.
>>>>
>>>> When the WG foundered the last time, it was because everyone wanted to
>>>> solve their own pet problem, and it turns out not every problem has the
>>>> same properties.  Fundamentally, every case requires a way of getting
>>>> policy implications for names in the DNS.  But the policies wanted may well
>>>> not be compatible with each other.
>>>>
>>>> One of the problems is nicely illustrated in the mail-abuse case.  The
>>>> problem there is that a domain at a higher level in the DNS wishes to
>>>> assert its policies over domains lower in the DNS.  The basic reason for
>>>> this is that DMARC used the PSL as a kicking-off point for deciding where
>>>> the Organizational Domain is.  A critical feature of the policy wanted here
>>>> is that the Organizational Domain needs to be able to assert its policy
>>>> over anything beneath it.  That's necessary because the whole concept of
>>>> the Organizational Domain implies authority over a segment of the tree.
>>>> This means that, once you have an Organizational Domain, you impose that
>>>> policy in every case lower in the tree.
>>>>
>>>> One of the other problems is nicely illustrated in the same-origin
>>>> policy case.  The way the same-origin policy works today contains a
>>>> conceptual mistake.  This originated in the original cookie specification,
>>>> which made certain policy authority inferences from the DNS tree, and those
>>>> inferences were an error.  To get around that, people use the PSL.  But the
>>>> PSL _still_ contains the same fundamental error, which is the assumption
>>>> that the policy authority boundary ought to follow the DNS tree structure.
>>>> Now, the DNS tree is neither necessary nor sufficient for these
>>>> inferences.  First, it is not necessary, since obviously there are cases
>>>> where example.com and example.net could be effectively under the same
>>>> policy.  There's no way today to account for this, and the answer that we
>>>> have so far is, "Yep, too bad, doesn't work."  Second, it is not
>>>> sufficient, because a parent that wished to extort control from a child
>>>> could assert certain properties though a PSL entry using wildcards.[1]  In
>>>> order to respond to this matter of necessity and sufficiency, then, the
>>>> mechanism in question needs to have a way of signalling agreement across
>>>> the policy authority boundary, so that both of the included domains agree
>>>> that they're covered by the same policy.
>>>>
>>>> The additional concern I had when I started my effort in 2012 was that
>>>> I thought (and continue to think) it was poor practice to have the
>>>> authoritative assertions about domain policies kept in a registry (the PSL)
>>>> independent from the domain registry (which data is published in the DNS).
>>>> So, I thought it would be valuable to find a way of expressing such
>>>> policies in the DNS, with the option of using data discovered in the DNS as
>>>> a means to maintain a static list like the PSL, for the performance reasons
>>>> people have cited more than once.
>>>>
>>>> I think for any renewed dbound effort to be worth undertaking, it will
>>>> be necessary to decide which of the problems one is trying to solve.  I do
>>>> not believe (and came not to believe last time) that the issues can be
>>>> properly solved in a single way, though it is possible that with enough
>>>> data in the records one could use a single RRTYPE to capture all the use
>>>> cases.  Last time, it seemed to me, those interested in the DMARC-type
>>>> issues were the most active, and since I didn't care about that case very
>>>> much I lost interest in the problem.  I think the same-origin, certificate
>>>> authority, and so on cases are more interesting, but most times I encounter
>>>> someone working on a browser they dismiss the general solution as
>>>> unnecessary because the hack they're using now is good enough (I disagree,
>>>> but I'm not committing code to their projects) or else that looking
>>>> anything up in the DNS is simply impossible (and then they stop listening
>>>> to any discussion of a precompiled PSL that can be better maintained in a
>>>> lazy way).  Regardless, I think if we do not come up with some pretty crisp
>>>> statements of which problems are to be solved, I think the group will
>>>> circle the same drain it did last time.
>>>>
>>>> Part of that drain-circling, by the way, was rooted in the focus on
>>>> picking different proposals that were written into I-Ds, rather than
>>>> getting clear on what problem people wanted to solve.  I had multiple
>>>> proposals that predated everyone else's drafts, and they committed the same
>>>> mistake: proposing a specific mechanism before properly understanding the
>>>> extent of the problem space.  Maybe that was necessary in order to
>>>> understand the space, but I am not convinced we will make a lot of progress
>>>> by reaching for a solution before we state clearly which of the issues will
>>>> and will not be solved.
>>>>
>>>> Best regards,
>>>>
>>>> A
>>>>
>>>>
>>>> [1] This was actually one of the concerns that led me to propose all of
>>>> this back in the mists of time: when ICANN was adding a huge number of
>>>> TLDs, I was nervous that some of those TLDs would quickly prove
>>>> unprofitable and that the relevant registry operators would discover
>>>> "security services" and so forth that imposed costs on registrants after
>>>> the registrants had operating sites using those domains.  These kinds of
>>>> services seemed to me to be quite likely to get support within the ICANN
>>>> GNSO, because it functions pretty similarly to a trade association and the
>>>> registrants don't have a voice.  I am pleased that my worries turned out
>>>> not to be realized, at least so far.
>>>>
>>>> --
>>>> Andrew Sullivan
>>>> [e-mail]
>>>>
>>>> _______________________________________________
>>>> dbound mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dbound
>>>>
>>> _______________________________________________
>>> dbound mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dbound
>>>
>> _______________________________________________
> dbound mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dbound
>