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

[Samuel Weiler <[e-mail]>]

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