[dbound] Related Domains By DNS (RDBD) Draft

[Stephen Farrell <[e-mail]>]

Hi Sam,

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

On 08/03/2019 20:30, Samuel Weiler wrote:
> 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.

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

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.

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

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.



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