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

Samuel Weiler <weiler@csail.mit.edu> Fri, 08 March 2019 20:30 UTC

Return-Path: <weiler@csail.mit.edu>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF74F1312F5 for <dbound@ietfa.amsl.com>; Fri, 8 Mar 2019 12:30:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level:
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJl66iRlfFQF for <dbound@ietfa.amsl.com>; Fri, 8 Mar 2019 12:30:04 -0800 (PST)
Received: from cyrus.watson.org (cyrus.watson.org [204.107.128.30]) by ietfa.amsl.com (Postfix) with ESMTP id D820C1279A3 for <dbound@ietf.org>; Fri, 8 Mar 2019 12:30:04 -0800 (PST)
Received: from 31-38-175.wireless.csail.mit.edu (31-38-175.wireless.csail.mit.edu [128.31.38.175]) by cyrus.watson.org (Postfix) with ESMTPSA id 07941CE820; Fri, 8 Mar 2019 20:30:04 +0000 (UTC)
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>
In-Reply-To: <A4E532F7-484E-4605-8D77-8E0A20A15014@gmail.com>
Message-ID: <alpine.OSX.2.20.1903081516350.70761@macbook-air-8.local>
References: <20190227172143.10303200F57CE0@ary.local> <1FFA1977E97DE99C390869DA@PSB> <alpine.OSX.2.21.1902272038320.3336@ary.local> <49A2FC767B5A7146F39456B9@PSB> <A4E532F7-484E-4605-8D77-8E0A20A15014@gmail.com>
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.1903081529540.70761@macbook-air-8.local>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dbound/yHUVkC-wnsSmi94TIwAaxqIqfs8>
Subject: Re: [dbound] [art] [DNSOP] not DNAME, was Related Domains By DNS (RDBD) Draft
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Mar 2019 20:30:12 -0000

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