Subject: Re: [dbound] [art] [DNSOP] not DNAME, was Related Domains By DNS (RDBD) Draft

From: Suzanne Woolf <[email-masked]>
Date: Fri, 1 Mar 2019 08:49:15 -0500

Hi,

(I realize the current draft is a -00, so comments are intended to be helpful towards a -01, not complaints that a -00 isn’t cooked yet.)

> On Feb 27, 2019, at 10:52 PM, John C Klensin <[email-masked]> wrote:
> 
> 
> 
> --On Wednesday, February 27, 2019 20:48 -0500 John R Levine
> <[email-masked]> wrote:
> 
> 
>> This issue has been argued at great length with proposals like
>> BNAME and CLONE so let's not redo it here.
> 
> Indeed.
> 

One high-level upshot of all this is that the usability of any mechanism that’s ever been proposed to implement notions like “related to” or “variant of” or “alias for” in the DNS depends a lot on exactly what behavior is desired for servers, resolvers, and applications….and what tradeoffs, in terms of security and administrative burden, are acceptable. 

The RDBD mechanism feels like it’s intended to be a building block to something else, maybe several somethings, but the effort to be simple and generally applicable means it’s hard to tell exactly what applications or use cases would benefit from it.

Previous discussions along these lines, as some comments upthread might make clear, tended to bog down in the fact that there are lots of nuances of behavior that people want in their “aliases” or “variants” or “related names,” and it can be hard to get the description right-- but otherwise, all too often it turns out that use cases that seem intuitively similar actually aren’t. Even conversations about “variants” in the context of IDNA tend to lead to sudden discoveries that in situations that are seemingly alike in all the important ways, the desired behavior is still very different for particular applications or users.

I’m not sure how to make this better, except the proposal as currently written is reminding me that previous attempts started simple and didn’t stay that way because the longer people looked at the set of problems they cared about, the more bells and whistles they felt they needed. This is a hard tendency to resist and requires a lot of clarity on the goals actually being pursued. (DNSOP discussions on proposals like ANAME and BNAME have demonstrated the same thing.)

My memories of DBOUND are not reliable but I do recall a distinct sense that people thought they were talking about "the same thing" and repeatedly discovering that maybe they weren’t.

Accordingly, I’d like to see an example or two of how you’d expect an application to use the kind of connection between domains established by the RDBD mechanism. 

I’m looking forward to reading the -01.

Suzanne

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 8 Mar 2019 15:30:03 -0500 (EST)

On Fri, 1 Mar 2019, Suzanne Woolf wrote:

> My memories of DBOUND are not reliable but I do recall a distinct 
> sense that people thought they were talking about "the same thing" 
> and repeatedly discovering that maybe they weren’t.
>
> Accordingly, I’d like to see an example or two of how you’d expect 
> an application to use the kind of connection between domains 
> established by the RDBD mechanism.

+1.

Reading back through the end-of-DBOUND discussions from 2016, I'm 
having these same thoughts.

Digging into two details:

I don't understand the value added by publishing new keys - and 
signing with a new signature format - when there's no evident way to 
bootstrap trust in those keys.  Could you explain (again) the value 
being added?  (I see value from using DNSSEC, but if we insist on 
DNSSEC, we don't need these other pieces.)

The DBOUND problem statement draft covered a number of "use cases that 
seem intuitively similar [but] actually aren't" (quoting Suzanne). 
Even so, it made a general recommendation in the security 
considerations section: "In general, positive assertions about another 
name should never be accepted without querying the other name for 
agreement."  I'm surprised to not see that reflected in this draft. 
Indeed, the discussion here suggests that this is an explicit 
non-requirement.  So I want to know more about the use case(s) you're 
tackling and why checking the symmetry of assertions is not necessary.

https://www.ietf.org/archive/id/draft-sullivan-dbound-problem-statement-02.txt

-- Sam

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 8 Mar 2019 22:21:51 +0000

Hi Sam,

(Fixing the subject a bit - there's no DNAME here:-)

On 08/03/2019 20:30, Samuel Weiler wrote:
>> sense that people thought they were talking about "the same thing" and
>> repeatedly discovering that maybe they weren’t.
>>
>> Accordingly, I’d like to see an example or two of how you’d expect an
>> application to use the kind of connection between domains established
>> by the RDBD mechanism.
> 
> +1.

We added some text on that in -01, in the intro. See the top
of page 3. Wasn't that clear enough?

That text is deliberately terse and not intended to outline
a complete set of use-cases.

My take is that part of the reason DBOUND failed was an
attempt to be all things to all parties. I think repeating
such an attempt with RDBD would lead to the same failure.
I at least, (and I think Alex too), are determined to not
have this fail for that particular reason. (It may fail for
others of course:-)

Just because we're using this list does not mean we have
to repeat the collective mistakes to which we variously
previously contributed using this list:-)

As a consequence I also think it is perfectly fine if RDBD
suffices only for one or a couple of purposes. If it does,
and usefully enough that it gets deployed, and doesn't do
damage otherwise, the rest can look after themselves later.

So even if there are additional credible use-cases, (and
I guess there are) I don't really care or want to discuss
those myself as doing so is likely to lead to the same
failure outcome as occurred with DBOUND.

It is also of course fine to disagree that our chosen bit
of the design space is the place to stick a stake in the
ground. In that case, I'd be happy to discuss other folks'
stakes and locations for 'em once I see their I-D.

Meanwhile, we'd like to discuss this particular design (and
not all possible others) and find out if it looks good enough
for all the people who'd need to, to do the work required to
get such RRs published and used.

> Reading back through the end-of-DBOUND discussions from 2016, I'm having
> these same thoughts.
> 
> I don't understand the value added by publishing new keys - and signing
> with a new signature format - when there's no evident way to bootstrap
> trust in those keys.  Could you explain (again) the value being added? 
> (I see value from using DNSSEC, but if we insist on DNSSEC, we don't
> need these other pieces.)

That comes from the history of DKIM I guess. It turns out that
unsigned keys in DNS demonstrably can provide some value if they
get (re-)used.

In this case, a signature indicates that the relating-domain (or
private-key-holder) was involved in the declaration that a
relationship exists. (Or that an active attack is ongoing, which
is ok, there's still value as not all transactions are under
active attack all the time. See RFC 7435.)

That said, I fully accept that the added value of the (now
optional) signatures isn't too high. See my earlier discussion
with John L.

> seem intuitively similar [but] actually aren't" (quoting Suzanne). Even
> so, it made a general recommendation in the security considerations
> section: "In general, positive assertions about another name should
> never be accepted without querying the other name for agreement."  I'm
> surprised to not see that reflected in this draft. Indeed, the
> discussion here suggests that this is an explicit non-requirement.  

We're not starting from the DBOUND problem statement here. If you
were to ask me would I do that, my answer would be "no thanks,
that didn't work before."

> So I
> want to know more about the use case(s) you're tackling 

Sure. Happy to take any questions on the text we added.

> and why checking
> the symmetry of assertions is not necessary.

If you want symmetry, then just do this trick twice. I don't see
any issue with that.

I also don't think all relationship are symmetric, so it just
seems to make sense to support asymmetry too.

Cheers,
S.

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 14 Mar 2019 16:13:22 -0400 (EDT)

>>> application to use the kind of connection between domains established
...
> of page 3. Wasn't that clear enough?

No, it is not.  Those are pretty broad use cases.  I want to see them 
more specifically defined.  e.g.  "correlate the ownership of websites 
in different languages" is still pretty broad.  WHO do you want to do 
the correlation?  (Which pieces of code?)  Is this for statistics and 
analysis (only) - e.g. so the Alexa list reflects the aggregate of 
correlated sites?  Or do you want client code doing something?  Do you 
want cookies shared?  Credentials?  I realize that this could touch 
many parts of the stack.

Put another way, if you're right that:

> ... part of the reason DBOUND failed was an

Then the use case(s) needs to be very clear.

-- Sam

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 15 Mar 2019 17:38:55 +0000

Hi Sam,

On 14/03/2019 20:13, Samuel Weiler wrote:
> No, it is not.  Those are pretty broad use cases.  

Broad != not-clear though:-) But fair enough.

> I want to see them
> analysis (only) 

Yes, it is for that. But saying "only" seems wrong - if people are
minded to publish this information then it can be used by anyone who
finds it, however they want.

For example, I might write some survey code that changes how it
counts based on this. But I can't describe that code as it'd
depend on what survey I'm actually doing.

>- e.g. so the Alexa list reflects the aggregate of
> correlated sites?  Or do you want client code doing something?  

See above.

> Do you
> want cookies shared? 

No. I would prefer to stay away from that, for now at least.

If/when RDBD RRs get published then browsers can think about whether
they'd like to use that information is as far as I'd go there - since
I do not make a browser, I don't see any point in trying to tell those
who do that they ought use this now. If they decided they did want to
use RDBD, then they could register a new rdbd-tag value if that was
what they wanted - at least I think that'd be a sensible thing to do.
And any text about the semantics of RDBD RRs using that rdbd-tag
value can be written then, by whomever understands that particular
use-case in full detail.

> Credentials?  

No. Same as above.

We say this in the draft:

"
   It is not a goal of this specification to provide a high-level of
   assurance that two domains are definitely related, nor to provide
   fine-grained detail about the kind of relationship that may exist
   between domains.
"

I'd be fine to strengthen that and saying something stronger if that
helped, e.g. maybe to say that rdbd-tag==0 RRs are not designed to
be used for cookies or for cross-domain authentication.

> I realize that this could touch many
> parts of the stack.
> 

Not sure I agree there. Use-case clarify or the lack thereof
does not imply one is or is not trying to be all things to all
parties. I do agree that clear text about use-cases is better
of course. But so is terse text.

Cheers,
S.