Re: [dbound] The proposals before us

"John Levine" <johnl@taugh.com> Sat, 10 September 2016 21:13 UTC

Return-Path: <johnl@taugh.com>
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 A0C6812B1B0 for <dbound@ietfa.amsl.com>; Sat, 10 Sep 2016 14:13:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 E43xAzC2BNs7 for <dbound@ietfa.amsl.com>; Sat, 10 Sep 2016 14:13:38 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F041B12B1A8 for <dbound@ietf.org>; Sat, 10 Sep 2016 14:13:37 -0700 (PDT)
Received: (qmail 75388 invoked from network); 10 Sep 2016 21:13:35 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 Sep 2016 21:13:35 -0000
Date: 10 Sep 2016 21:13:14 -0000
Message-ID: <20160910211314.47140.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: dbound@ietf.org
In-Reply-To: <CAEKtLiTpa+5URazZeUNwizkx_ohVkgmk_XPZP3gm7k7PrWaY9w@mail.gmail.com>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dbound/prmqxlgVUuf_B_RxLXNkYL-PKYw>
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: Sat, 10 Sep 2016 21:13:39 -0000

In article <CAEKtLiTpa+5URazZeUNwizkx_ohVkgmk_XPZP3gm7k7PrWaY9w@mail.gmail.com> you write:
>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.

Actually, I was thinking of the whole policy-negative stuff.  My proposal
also has slots for other policies, so we seem about the same 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.

I don't see how that is very useful in practice.  The namespace that
people are likely to be most interested in is the .COM TLD, but the
registry doesn't know which subdomains have third-party delegations.
A domain that doesn't have third-party delegations can publish a fetch
blob, but in most cases that's only going to say we're one big
organizational domain.  It's unclear to me if fetch helps domains like
uk that know that ac.uk and org.uk and co.uk are boundaries but don't
know what boundaries may exist below that.

>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

That is true, but for incoming mail the request will typically be in
conjunction with a bunch of inquiries about the IP the message is
coming from (DNSBLs) and the domain in the envelope (SPF).  The horse
has left the barn and I'd rather have the performance.

>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.

The current behavior is typically to look in the PSL and if the domain
isn't there, the code does whatever it does.  I haven't looked at any
of the libraries to see if they don't look for an org domain or if
they do some hack like assume it's a 2LD.  Whatever they do, it seems
compatible to me.

R's,
John

PS: Now I'm definitely going to wait for someone else to say something.