Re: [dbound] The proposals before us

Casey Deccio <casey@deccio.net> Tue, 06 September 2016 15:50 UTC

Return-Path: <casey@deccio.net>
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 1940612B58D for <dbound@ietfa.amsl.com>; Tue, 6 Sep 2016 08:50:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=deccio.net
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 yS5eKbHj_rr8 for <dbound@ietfa.amsl.com>; Tue, 6 Sep 2016 08:50:36 -0700 (PDT)
Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 616CC12B6EC for <dbound@ietf.org>; Tue, 6 Sep 2016 08:29:49 -0700 (PDT)
Received: by mail-ua0-x230.google.com with SMTP id 71so9505372uag.2 for <dbound@ietf.org>; Tue, 06 Sep 2016 08:29:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wpPfg5Ifj72pfX0JP8hHFclFqa+EsRyGHODz3kfAfwo=; b=W8mMVBxxoqtS/HIfHJf0eYtYA+2hp15pVgvzgKWr5kva4Sjozf/mJIyaDRYeeUr4vD tkMhZb++l+X5hKquoPHyuT7fYTYnwtns7UXV31HebkYciauV3bKErb1px8jLRuoEogxY MPFCrpk1FJSsrcYLvQ0bQYfdy7QUwbByx1ehQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wpPfg5Ifj72pfX0JP8hHFclFqa+EsRyGHODz3kfAfwo=; b=V9Flw4LDtyvsVjhmBjifg9ww92psYq8tHB4dv6B0FO1bUhVZfzSYb6cinhzHZUzCr7 Vl/emDC2dIDIIDZ6JvYr1Q98NMXr0uFIEnrWvKjRTv25/UGHq0cRZWg71oyKGeBKdvB8 NnlGWecJFCxRaGSRYwZzSeMWeaAcoSdriSts0DLEvlc33iUr3pl0Uzv5FUkbuocFUmAo kX+vACP9nGQo9n2HcW6SlZT0VsX6pL30/QB//oKYn9PByOvluM1ztkFn+Ql91ojX2YOh 7iTHREs5zeEdcnIKgVBBKH0/Ib2QziCKpY5k6rmHQuAF2Cptr5+a/98fq+YWBPrnNaj6 NR0Q==
X-Gm-Message-State: AE9vXwOW1hVKpBQ/fLv2xNhfVA9cBgTDDx8SD5QV/3YmS8rDTpQV443GLJYe01ByEQ7HwO30BR4yr/ZzXy1nhg==
X-Received: by 10.159.41.98 with SMTP id t89mr24767087uat.97.1473175788469; Tue, 06 Sep 2016 08:29:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.81.88 with HTTP; Tue, 6 Sep 2016 08:29:47 -0700 (PDT)
In-Reply-To: <20160903205749.4439.qmail@ary.lan>
References: <CAL0qLwYQcNLk7=4=W=vcVwLcMA8JSaKYAKoNGsKP6yQ13qD=Yg@mail.gmail.com> <20160903205749.4439.qmail@ary.lan>
From: Casey Deccio <casey@deccio.net>
Date: Tue, 6 Sep 2016 11:29:47 -0400
Message-ID: <CAEKtLiTpa+5URazZeUNwizkx_ohVkgmk_XPZP3gm7k7PrWaY9w@mail.gmail.com>
To: John Levine <johnl@taugh.com>
Content-Type: multipart/alternative; boundary=94eb2c093222906832053bd877e2
Archived-At: <https://mailarchive.ietf.org/arch/msg/dbound/SYFEyziPpIZy0MW0TLDyE4UEmwI>
Cc: Murray Kucherawy <superuser@gmail.com>, "dbound@ietf.org" <dbound@ietf.org>
Subject: Re: [dbound] The proposals before us
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 06 Sep 2016 15:50:43 -0000

On Sat, Sep 3, 2016 at 4:57 PM, John Levine <johnl@taugh.com> wrote:

> ODUP: first party publication with TXT records, can work but has a lot
> of stuff not useful for the mail application.


You mean it supports the addition of policy-defining directives in the
future?  Yup.  I don't think there's a lot of overhead there.


>   Number of queries
> varies but seems usually to be the number of components in the name.
>

Proper use of the "fetch" directive (introduced in version -01 and fleshed
out in version -02; the current version is -03 [1]) allows an application
to pull down ahead of time or on-demand the policy for an entire namespace
tree.  This is especially useful for 1) the "upper" domains, i.e., those
currently referred to as "public suffixes"; and 2) domains with heavy
usage.  Downloading the policy associated with public suffixes ahead of
time brings the number of DNS lookups for names in any domain with no
explicit policy (i.e., using default behavior) to one [2].  Downloading the
policy associated with other domains (especially those with heavy usage)
brings lookups to zero for names in those domains.

I envision two possible companion documents for ODUP: one to document best
practice application usage for fetching of policies using "fetch" (how
often to check, etc.); and one to document a mechanism for "advertising"
domains for which policy can/should be downloaded ahead of time.  Note that
the latter isn't supposed to be a PSL-like list that includes policy, but
simply a pointer to the domains that might want policy downloaded ahead of
time.

Mine: minimal design.  Number of queries is typically the number of
>
boundaries (not components) or that number plus 1, which in practice
> seems unlikely to be more than 2.


There are two major tradeoffs here:

1) Minimal information disclosure.  There is a broad effort to minimize
information disclosure in the name of privacy.  ODUP keeps with those
efforts by only disclosing the information necessary to find the policy or
next delegation of policy--sort of the qname-minimization equivalent of
DBOUND.  The Levine draft specifies that the entire name for which the
organizational boundary is being sought is provided to the DNS servers (and
in previous versions, the application/use as well).

2) Sane default.  There needs to be a default behavior that is consistent
and compatible with existing behavior.  With ODUP the lack of DNS data at
an ODUP name (that is, nothing special has been changed for the domain by
way of adding ODUP records) results in behavior that is consistent with the
current behavior [3].  The Levine draft says: "If there is no policy for
the domain the lookup fails; there are no defaults... Applications may
apply defaults of their own, but that is beyond the scope of this
specification."  I'm not sure I fully understand that statement, but it
doesn't provide me confidence that the default is backwards compatible with
current behavior.

[1] See
https://tools.ietf.org/html/draft-deccio-dbound-organizational-domain-policy-03
and https://mailarchive.ietf.org/arch/msg/dbound/rRs4EghKGxaxU3AFMCDRKHBkh3w
[2] See https://github.com/verisign/odup for running code and documentation
to recreate this.
[3] Once the ODUP configuration is deployed at TLDs, e.g., using scripts
such as those at https://github.com/verisign/odup