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 <wei...@csail.mit.edu>
To: dbo...@ietf.org
Cc: Stephen Farrell <stephen.farr...@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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
