Re: [dbound] DBOUND interest @ IETF 114?

[Paul Vixie <[e-mail]>]

Andrew Sullivan wrote on 2022-07-28 11:12:
> Hi,
> 
> Ordinary disclaimer: I work for the Internet Society, but this is not my 
> employer's opinion.

likewise, not speaking for $dayjob here.

> On Wed, Jul 27, 2022 at 08:22:58PM -0700, Paul Vixie wrote:
> 
>> ... the PSL has in recent years scaled back its hopes for some
>> signals that everyone was ignoring. the "effective PSL" is exactly
>> what same-origin processing requires; not more.
> 
> I might state this a different way: same-origin processing has gradually 
> morphed so that the PSL's more limited claims are now what people expect 
> from same-origin.  It still doesn't actually deliver on the promise the 
> name (same origin) seems to make. ...

do we have any in-depth w3 experts and/or browser engineers who can 
comment upon that summary and perhaps verify it? to me the original sin 
was the "www" subdomain, where an object at www.example.com would like 
to be able to HREF an object at images.example.com and have that web 
server receive the cookie. so, www.example.com had to be able to speak 
for example.com. hell then having broken loose, it was necessary to put 
some limits on this, allowing www.example.com to speak for example.com 
but not for other.com or com itself. the PSL was the bandage we needed.

someone who works in the w3 industry and has some publication credits 
more recent than mine (RFC 2756) will ideally step up and state real 
facts for the record which we can base some directional guidance on.

> ... But I don't think we should modify the problem statement 
> to pretend that the current state of affairs is what people actually 
> want.

i think that we can and probably must do so. the people who show up and 
want to do work get to pick their problem statement. existence (or not) 
of others not present or too busy to help won't affect that. problem 
statement is a bid/ask protocol among specific bidders and askers.

> ... I think it's just what they figure they can get, and now we have 
> a lot of stuff deployed with that mindset, so we have to accept that 
> mindset as an important use case (if only for backward compatibility).

understood. however, a mixed solution that addresses both known needs 
and potential needs is subject to a "boil the ocean" outcome. if in 
order to "scale the PSL" we must also "ask the web what it really wants" 
then the seven years since dbound was convened aren't even half of the 
period we must plan to work around without relief. i'm happy to call the 
first artifact an interrim solution if we already know it won't last 
forever. but i'll be happier still if we just make it easily extensible.

>> i hope we can agree to a V1 specification that solves the bare minimum 
>> (same-origin enforcement)
> 
> The interesting thing, to me, is that the last time this came around 
> that was _not_ the bare minimum.  The goals that I laid out when first 
> proposing various things in this area (which were more closely aligned 
> with same-origin) ended up swamped by the mail domain/inheritance cases 
> that were really important for anti-spam measures.

as a former anti-spammer, i can only imagine how demanding "we" would 
have been, and as a possible proxy, let me apologize about "us". 
passions run hot in that community.

if there are anti-spammers who show up and want to work then we ought to 
listen to them and search for shared solutions -- subject to a schedule, 
and with the promise that whatever is V1 will be easily extensible.

> ... Maybe getting 
> agreement on which problem is to be tackled and what the ordered list of 
> problems is would be helpful before we start selecting solutions?

i'm fine with that. my bid for a problem statement is "effective PSL" 
meaning the parts of PSL which are actually used today, adding scale so 
that we don't have a central mostly-static repository maintained by 
non-contracted parties. i realize now that "john's draft seemed fine to 
me" could look like i'd selected a solution. far from it. i'm trying 
only to establish that someone else's invention would be welcome, there 
should be no NIH Syndrome here.

>> ... and that it'll be done with TXT records, nothing new.
> 
> One obvious problem with TXT records is that it is difficult to make 
> statements about a domain name from a subdomain of that domain name, 
> since the domain itself ought to be the controller of its fate.

i think the RDNS is no longer a trivially short distance from DNS 
clients, owing to the long march toward anycast. so our reflex may be to 
avoid DNS transactions which might have to be oft-repeated. so, label 
stripping seems insane. we may want to storm that conceptual castle and 
say "because RDNS trends towards anycast, dbound clients are urged to 
maintain their own long-lived cache of positive and negative results".

it's possible that we'll prefer to use wildcards to express boundaries, 
and that to do so we must introduce yet another _foo label under the 
delegation point so that the shape of that subtree won't affect the 
shape of the "real" subtree. this is what i think john's draft did.

it's certain that for a variety of reasons a mostly-static PSL will 
still be needed, and that clients of that will not make any "dbound" 
queries in real time. i expect to implicitly facilitate the generation 
of such a mostly-static snapshot using online TXT RRs which are 
periodically swept and verified. by implicitly i just mean it has to 
remain possible in this next iteration of the problem and solution.

>> we've had the holy wars; now we have the plea for peace.
> 
> I would not describe the previous situation as holy war, but rather as a 
> discussion about what peace would mean.  I still think that is necessary.

i was referring to

https://ieeexplore.ieee.org/document/1667115

but i now see that i ought to have referenced it and added a :-). apologies.

-- 
P Vixie