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: Sat, 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.
- [dbound] The proposals before us Murray S. Kucherawy
- Re: [dbound] The proposals before us Jiankang Yao
- Re: [dbound] The proposals before us Hollenbeck, Scott
- Re: [dbound] The proposals before us John Levine
- Re: [dbound] The proposals before us Casey Deccio
- Re: [dbound] The proposals before us John Levine
- Re: [dbound] The proposals before us Murray S. Kucherawy
- Re: [dbound] The proposals before us Paul Hoffman
- Re: [dbound] The proposals before us Kurt Andersen
- Re: [dbound] The proposals before us John Levine
- Re: [dbound] The proposals before us Casey Deccio
- Re: [dbound] The proposals before us John R Levine
- Re: [dbound] The proposals before us Casey Deccio
- Re: [dbound] The proposals before us John R Levine
- Re: [dbound] The proposals before us Gervase Markham
- Re: [dbound] The proposals before us Casey Deccio
- Re: [dbound] The proposals before us John R Levine
- Re: [dbound] The proposals before us Casey Deccio
- Re: [dbound] The proposals before us John R Levine
- Re: [dbound] The proposals before us Casey Deccio