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

Samuel Weiler <weiler@csail.mit.edu> Thu, 25 July 2019 15:06 UTC

Date: Thu, 25 Jul 2019 11:05:51 -0400
From: Samuel Weiler <weiler@csail.mit.edu>
To: dnsop@ietf.org
Message-ID: <alpine.OSX.2.20.1907251054380.29273@dhcp-8906.meeting.ietf.org>
User-Agent: Alpine 2.20 (OSX 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="0-2033760801-1552076279=:70761"
Content-ID: <alpine.OSX.2.20.1907251054520.29273@dhcp-8906.meeting.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/n2wCEcR07bKeKOwksOnWbTOWonY>
Subject: Re: [DNSOP] [dbound] [art] not DNAME, was Related Domains By DNS (RDBD) Draft (fwd)
Precedence: list

Moving the discussion to DNSOP, as requested in Montreal.

I continue to be concerned that the RDBD draft is:

1) Biting off too much.  As in the thread below, I think DBOUND failed 
because it attempted to be all things to all people.

2) Failing to address the full-stack implications.  Some use cases I 
heard at the microphone in Montreal involve automated processing and 
have security impacts along the stack.  Yet the doc admits:

    It is not a goal of this specification to provide a high-level of
    assurance as to whether or not two domains are definitely related,

Data formats are simple.  Processing rules for them are hard.
Specifying the former without the latter leads to breakage.  Let's 
pick one use case and then spec out the logic for satisfying it.

-- Sam

---------- Forwarded message ----------
Date: Fri, 8 Mar 2019 15:30:03 -0500 (EST)
From: Samuel Weiler <weiler@csail.mit.edu>
To: dbound@ietf.org
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [dbound] [art] [DNSOP]  not DNAME,
     was Related Domains By DNS (RDBD) Draft

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

Re: [DNSOP] [dbound] [art] not DNAME, was Related… Samuel Weiler