From nobody Thu Sep 1 07:43:33 2016 Return-Path: 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 6B58012D9C0 for ; Thu, 1 Sep 2016 07:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign-com.20150623.gappssmtp.com 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 ZiGWXkCTo9NL for ; Thu, 1 Sep 2016 07:43:28 -0700 (PDT) Received: from mail-qt0-x261.google.com (mail-qt0-x261.google.com [IPv6:2607:f8b0:400d:c0d::261]) (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 8826312D581 for ; Thu, 1 Sep 2016 07:43:28 -0700 (PDT) Received: by mail-qt0-x261.google.com with SMTP id 11so4786443qtc.2 for ; Thu, 01 Sep 2016 07:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=tjMRQqfn29R7ENsqcbhQ0Qg7xe9dxTSxtlC9l014JFM=; b=JyhxXlq0V3lWtRSa2gK+V9cRv6hWJUaLdTVtO8ArjzT/TskkLO+EZriXGptceYdYtg 21ls8MvnEhHsO6okdRiu8Hd2qTSlvdY1e4Wyb0PiT6rvazdNhh28z8fZEGqGnZagc8zM mKMtwSzAFsZJ+cPVVxn3FU8VtNB1U2xDFw3NmS2XEGmQAu4zyPU/HHJYMy+MJtip6zIe z4phwhPnqDAn/4Y8PzeFLUp2ZyRxyGfiD++2Y+KPTVoHV4Ue/UaJITBDCtv7NZBBA0h4 ntD9/3W/SUEyxdDmg2X6V9KfDIXEfYCHv9y4Z9JCZfCSpDHJyl3Ac3Jp/ejNfQMJ5Q3b TTGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :mime-version; bh=tjMRQqfn29R7ENsqcbhQ0Qg7xe9dxTSxtlC9l014JFM=; b=HAvK1NztwA6SqC1P4DFGlfI1WX/YzOM3fJfv1EYIi1wRP4WlLsIJYQ/dai69iOCXnY QNwTAGUDBn3hs98RD9Fmi3yzNDFHfjL/e+uSOWKE/dSG2+X+FiJzAesC+MdjFaevBAmy EC6gTJUhW+BlLNiH4BlsGe4i4VjIVQBX2/CKTuthDkVQktUACyI39b/A76rA92/wK0Kp e1N/91GF/m5jz7SK3bYWwzvWyRQFZchyVSgrbdC456AFHRwnEpERteyaf74iz+OOv0Uz XOmG8n4GSmqPkOMqG5bDAA8r5v/yDSujW8VYPQOVK1ASsPSw+uADuLE4z5mejxgs7SDW /Uig== X-Gm-Message-State: AE9vXwNhyqbLWg76kbuvhlvkKJ+Y5L6LW64zE6fRUjVF4I6HVf/JAa7/qxJxwgqG3Kbhcbe4Wjo+k1JIGC/DYM24MPKU8aCT X-Received: by 10.55.129.1 with SMTP id c1mr17388423qkd.53.1472741007298; Thu, 01 Sep 2016 07:43:27 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id q72sm908171qka.4.2016.09.01.07.43.26 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 01 Sep 2016 07:43:27 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id u81EhQUU024955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 1 Sep 2016 10:43:26 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 1 Sep 2016 10:43:26 -0400 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" , "dbound@ietf.org" Thread-Topic: [dbound] The proposals before us Thread-Index: AQHSAtnatmsQEHcT00mdHkRUb8L0BaBktpyw Date: Thu, 1 Sep 2016 14:43:25 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A46D882@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F4A46D882BRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 14:43:31 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F4A46D882BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogZGJvdW5kIFttYWlsdG86ZGJvdW5kLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBNdXJyYXkgUy4gS3VjaGVyYXd5DQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMzAsIDIwMTYgMTE6 NTcgQU0NClRvOiBkYm91bmRAaWV0Zi5vcmcNClN1YmplY3Q6IFtkYm91bmRdIFRoZSBwcm9wb3Nh bHMgYmVmb3JlIHVzDQoNCk9LLCBsZXQncyBnZXQgZ29pbmcuICBJdCdzIHRpbWUgdG8gbWFrZSBw cm9ncmVzcyBvciBkaWUuDQpUaGUgcHJvcG9zYWxzIGJlZm9yZSB1czoNCiogT0RVUCAoaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZGVjY2lvLWRib3VuZC1vcmdhbml6YXRp b25hbC1kb21haW4tcG9saWN5LykNCiogSm9obiBMZXZpbmUncyBwcm9wb3NhbCAoaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGV2aW5lLWRib3VuZC1kbnMvKQ0KKiBTT1BB IChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zdWxsaXZhbi1kb21haW4t cG9saWN5LWF1dGhvcml0eS8pDQpHaXZlbiB0aGF0IHdlIGFyZSBub3cgY29uc3RyYWluaW5nIG91 cnNlbHZlcyB0byBkZWFsaW5nIHdpdGggdGhlIGVtYWlsIGNhc2Ugb25seSwgZG8gd2UgaGF2ZSBh IGNsZWFyIHByZWZlcmVuY2UgZm9yIG9uZSBvZiB0aGVzZSB0byBhZG9wdCBhbmQgZGV2ZWxvcD8g IEFzIEkgcmVjYWxsLCB3ZSAoZXNwZWNpYWxseSB0aGUgYXV0aG9ycykgYWxsIGhhZCBob21ld29y ayB0byByZXZpZXcgdGhlc2UgdW5kZXIgdGhpcyBuZXcgc2NvcGUgY29uc3RyYWludCBhbmQgcHJv dmlkZSBjcml0aWNhbCBmZWVkYmFjayB3aXRoIGEgZ29hbCBvZiBtYWtpbmcgYSBzZWxlY3Rpb24g b2Ygc29tZSBraW5kIGZvciB0aGUgd29ya2luZyBncm91cCB0byBkZXZlbG9wLiAgRG9lcyBhbnlv bmUgaGF2ZSBzdWNoIGNvbW1lbnRzIHRvIGdldCB1cyBtb3ZpbmcgaGVyZT8NCk15IHRlYW0gaGFz IGltcGxlbWVudGVkIGEgcHJvb2Ygb2YgY29uY2VwdCBvZiBPRFVQIGFuZCB0ZXN0ZWQgaXQgd2l0 aCBzb21lIGhhY2tpbmcgaW4gRmlyZWZveCBhbmQgUG9zdGZpeC4gSXQgc2VlbXMgdG8gd29yayBq dXN0IGZpbmUuDQoNClNjb3R0DQo= --_000_831693C2CDA2E849A7D7A712B24E257F4A46D882BRN1WNEXMBX01vc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0 eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gZGJvdW5kIFttYWlsdG86ZGJvdW5kLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPk11cnJheSBTLiBLdWNoZXJhd3k8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwg QXVndXN0IDMwLCAyMDE2IDExOjU3IEFNPGJyPg0KPGI+VG86PC9iPiBkYm91bmRAaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2Rib3VuZF0gVGhlIHByb3Bvc2FscyBiZWZvcmUgdXM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pk9LLCBsZXQncyBnZXQgZ29pbmcuJm5ic3A7IEl0J3MgdGltZSB0byBtYWtlIHByb2dyZXNzIG9y IGRpZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGUgcHJvcG9zYWxzIGJlZm9yZSB1czo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBPRFVQICg8YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kZWNjaW8tZGJvdW5kLW9yZ2FuaXph dGlvbmFsLWRvbWFpbi1wb2xpY3kvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1kZWNjaW8tZGJvdW5kLW9yZ2FuaXphdGlvbmFsLWRvbWFpbi1wb2xpY3kvPC9hPik8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogSm9obiBM ZXZpbmUncyBwcm9wb3NhbCAoPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtbGV2aW5lLWRib3VuZC1kbnMvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1sZXZpbmUtZGJvdW5kLWRucy88L2E+KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiogU09Q QSAoPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc3VsbGl2 YW4tZG9tYWluLXBvbGljeS1hdXRob3JpdHkvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1zdWxsaXZhbi1kb21haW4tcG9saWN5LWF1dGhvcml0eS88L2E+KTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPkdpdmVuIHRoYXQgd2UgYXJlIG5vdyBjb25zdHJhaW5pbmcgb3Vyc2VsdmVzIHRv IGRlYWxpbmcgd2l0aCB0aGUgZW1haWwgY2FzZSBvbmx5LCBkbyB3ZSBoYXZlIGEgY2xlYXIgcHJl ZmVyZW5jZSBmb3Igb25lIG9mIHRoZXNlIHRvIGFkb3B0IGFuZCBkZXZlbG9wPyZuYnNwOyBBcyBJ IHJlY2FsbCwgd2UgKGVzcGVjaWFsbHkgdGhlIGF1dGhvcnMpIGFsbCBoYWQgaG9tZXdvcmsNCiB0 byByZXZpZXcgdGhlc2UgdW5kZXIgdGhpcyBuZXcgc2NvcGUgY29uc3RyYWludCBhbmQgcHJvdmlk ZSBjcml0aWNhbCBmZWVkYmFjayB3aXRoIGEgZ29hbCBvZiBtYWtpbmcgYSBzZWxlY3Rpb24gb2Yg c29tZSBraW5kIGZvciB0aGUgd29ya2luZyBncm91cCB0byBkZXZlbG9wLiZuYnNwOyBEb2VzIGFu eW9uZSBoYXZlIHN1Y2ggY29tbWVudHMgdG8gZ2V0IHVzIG1vdmluZyBoZXJlPzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPk15IHRlYW0gaGFzIGltcGxlbWVudGVkIGEgcHJvb2Ygb2YgY29uY2VwdCBvZiBPRFVQIGFu ZCB0ZXN0ZWQgaXQgd2l0aCBzb21lIGhhY2tpbmcgaW4gRmlyZWZveCBhbmQgUG9zdGZpeC4gSXQg c2VlbXMgdG8gd29yayBqdXN0IGZpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlNjb3R0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_831693C2CDA2E849A7D7A712B24E257F4A46D882BRN1WNEXMBX01vc_-- From nobody Sat Sep 3 13:58:15 2016 Return-Path: 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 2EDAB12B0F5 for ; Sat, 3 Sep 2016 13:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[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 DyBfQwe1R82i for ; Sat, 3 Sep 2016 13:58:13 -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 0275012B0F3 for ; Sat, 3 Sep 2016 13:58:12 -0700 (PDT) Received: (qmail 60563 invoked from network); 3 Sep 2016 20:58:11 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 3 Sep 2016 20:58:11 -0000 Date: 3 Sep 2016 20:57:49 -0000 Message-ID: <20160903205749.4439.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: superuser@gmail.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 20:58:14 -0000 >* ODUP ( >* John Levine's proposal ( >* SOPA ( My draft expired, so I just uploaded a new -01 which strips out some of the non-mail stuff but doesn't change the design otherwise. I'm hardly unbiased, but here's my take on it: ODUP: first party publication with TXT records, can work but has a lot of stuff not useful for the mail application. Number of queries varies but seems usually to be the number of components in the name. 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. The draft specifies a new RR with first party publication but Variations section shows how TXT rather than RR or third party rather than first party would work. SOPA: can do all sorts of cool stuff, but the need to put RRs at each name seems like a show stopper to me. From nobody Tue Sep 6 08:50:45 2016 Return-Path: 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 ; 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 ; 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 ; Tue, 6 Sep 2016 08:29:49 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id 71so9505372uag.2 for ; 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: <20160903205749.4439.qmail@ary.lan> From: Casey Deccio Date: Tue, 6 Sep 2016 11:29:47 -0400 Message-ID: To: John Levine Content-Type: multipart/alternative; boundary=94eb2c093222906832053bd877e2 Archived-At: Cc: Murray Kucherawy , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 15:50:43 -0000 --94eb2c093222906832053bd877e2 Content-Type: text/plain; charset=UTF-8 On Sat, Sep 3, 2016 at 4:57 PM, John Levine 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 --94eb2c093222906832053bd877e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Sep 3, 2016 at 4:57 PM, John Levine <johnl@taugh.co= m> wrote:
ODUP: first party p= ublication 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 di= rectives in the future?=C2=A0 Yup.=C2=A0 I don't think there's a lo= t of overhead there.
=C2=A0
=C2=A0 Number of queries
varies but seems usually to be the number of components in the name.

Proper use of the "fetch" directive (int= roduced 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 t= he policy for an entire namespace tree.=C2=A0 This is especially useful for= 1) the "upper" domains, i.e., those currently referred to as &qu= ot;public suffixes"; and 2) domains with heavy usage.=C2=A0 Downloadin= g the policy associated with public suffixes ahead of time brings the numbe= r of DNS lookups for names in any domain with no explicit policy (i.e., usi= ng default behavior) to one [2].=C2=A0 Downloading the policy associated wi= th other domains (especially those with heavy usage) brings lookups to zero= for names in those domains.

I envi= sion two possible companion documents for ODUP: one to document best practi= ce application usage for fetching of policies using "fetch" (how = often to check, etc.); and one to document a mechanism for "advertisin= g" domains for which policy can/should be downloaded ahead of time.=C2= =A0 Note that the latter isn't supposed to be a PSL-like list that incl= udes policy, but simply a pointer to the domains that might want policy dow= nloaded ahead of time.

Mine: minimal design.=C2=A0 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 disclos= ure.=C2=A0 There is a broad effort to minimize information disclosure in th= e name of privacy.=C2=A0 ODUP keeps with those efforts by only disclosing t= he information necessary to find the policy or next delegation of policy--s= ort of the qname-minimization equivalent of DBOUND.=C2=A0 The Levine draft = specifies that the entire name for which the organizational boundary is bei= ng sought is provided to the DNS servers (and in previous versions, the app= lication/use as well).

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

[1] See https://tools.ietf.org/html= /draft-deccio-dbound-organizational-domain-policy-03 and http= s://mailarchive.ietf.org/arch/msg/dbound/rRs4EghKGxaxU3AFMCDRKHBkh3w
[2] See https://github.com/verisign/odup for running code and documen= tation to recreate this.
[3] Once the ODUP configuration is d= eployed at TLDs, e.g., using scripts such as those at https://github.com/verisign/odup
--94eb2c093222906832053bd877e2-- From nobody Thu Sep 8 18:32:36 2016 Return-Path: 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 9B27512B12A for ; Thu, 8 Sep 2016 18:32:34 -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 S8w-lHynzwhQ for ; Thu, 8 Sep 2016 18:32:33 -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 5E3E412B0F1 for ; Thu, 8 Sep 2016 18:32:33 -0700 (PDT) Received: (qmail 52658 invoked from network); 9 Sep 2016 01:32:30 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 9 Sep 2016 01:32:30 -0000 Date: 9 Sep 2016 01:32:09 -0000 Message-ID: <20160909013209.39252.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: casey@deccio.net 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 01:32:34 -0000 In article you write: >On Sat, Sep 3, 2016 at 4:57 PM, John Levine 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. ... I have more opinions, but before expressing them I'd like to see whether anyone other than the two of us is paying attention. R's, John From nobody Fri Sep 9 00:19:19 2016 Return-Path: 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 192C312B1B3 for ; Fri, 9 Sep 2016 00:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 84OOfUyySCZF for ; Fri, 9 Sep 2016 00:19:15 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 6690512B10D for ; Fri, 9 Sep 2016 00:19:15 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id g62so37574408lfe.3 for ; Fri, 09 Sep 2016 00:19:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UFViEqxH4GhADcA+b090cmNIFui1CvpF0Ibr1AFsxYc=; b=bQtknR0fipSRlZYTTZ614TNXqoft+jqk+I6ApmB94a6Ny8SNlunwlWa1ovnej1vwhZ uqDueos3jsaE+NgeFhDGFPgs1cvw1g2GetpvdTNHZY0NEsbHqBaq9snw5e4gpkww1INQ 6vZnaqaYgitwdznQwsb7XdLI9gHZ74/D20Zg4nMtYJxO8b5QbmjHaY55bAmeacK9HqZs K+uOPrK/yuskPWcDz/dUB89tOxlaUYb/1x23R2X9WJgetymVhQb5Uwjl5DmlNNTDj5Bm FGE0QRyAjub9ojCy3oUriLbBC0h3Cst2/7eS3YlcD7VYS5M+/BQ5blUPC+6McCrKzO12 aPtg== 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=UFViEqxH4GhADcA+b090cmNIFui1CvpF0Ibr1AFsxYc=; b=DgF/3VPOTEhDrr+OtFsvS4wsYpRvQzkCcEnY6epK5nYNibChDykLqAwOxwEibNnKWY xD2hPxrBGFvEjh3bdGywFjFnwj2rvsGlitiHbi+36SFqiZ9WiJJ76kj9okqptwUuPkdW vPHW0AvaKsGLxJmtLqFHWV2/nZkabUgd2mDO2mycD/sMcOHTZi0puCqPZdNA4/zym4zv XL80r6lH4dMUOxIx0Pxugm210uTUxMJUxP5gVRBWws9frTcMdBMC9SWH27yueUWKYYPH vny5lZNrYqfHqNWs3ptxzkkfbpJcJldsPIecY/yZAu74W/euScYf8ggGpxXd3EGbaAse AhHQ== X-Gm-Message-State: AE9vXwN2iqD+DSXTaTkFgdY2A2jsX8ze352nPA5VT5cOQYIfzDs2+oRCG2Ek2Nl6JpYvObtJeccEBxmaQnKUHg== X-Received: by 10.46.71.144 with SMTP id u138mr585840lja.20.1473405553479; Fri, 09 Sep 2016 00:19:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.183.8 with HTTP; Fri, 9 Sep 2016 00:19:12 -0700 (PDT) In-Reply-To: <20160909013209.39252.qmail@ary.lan> References: <20160909013209.39252.qmail@ary.lan> From: "Murray S. Kucherawy" Date: Fri, 9 Sep 2016 00:19:12 -0700 Message-ID: To: John Levine Content-Type: multipart/alternative; boundary=001a11411dc6a01468053c0df68f Archived-At: Cc: Casey Deccio , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 07:19:17 -0000 --001a11411dc6a01468053c0df68f Content-Type: text/plain; charset=UTF-8 On Thu, Sep 8, 2016 at 6:32 PM, John Levine wrote: > In article mail.gmail.com> you write: > >On Sat, Sep 3, 2016 at 4:57 PM, John Levine 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. ... > > I have more opinions, but before expressing them I'd like to see > whether anyone other than the two of us is paying attention. > I am. I'm working on some comments on our current proposals myself. Just don't have them all baked enough to send yet. Do go on. :-) -MSK --001a11411dc6a01468053c0df68f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Sep 8, 2016 at 6:32 PM, John Levine <johnl@taugh.co= m> wrote:
In article <CAEKtLiTpa+5URazZeUNwizkx_ohVkgmk_XPZP3gm7k7PrWaY9w@mail.g= mail.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<= br> >future?=C2=A0 Yup.=C2=A0 I don't think there's a lot of = overhead there. ...

I have more opinions, but before expressing them I'd like to see
whether anyone other than the two of us is paying attention.

I am.=C2=A0 I'm working on some comments on our c= urrent proposals myself.=C2=A0 Just don't have them all baked enough to= send yet.

Do go on.=C2=A0 :-)

-MSK
=
--001a11411dc6a01468053c0df68f-- From nobody Fri Sep 9 08:33:48 2016 Return-Path: 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 A91BD12B19D for ; Fri, 9 Sep 2016 07:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 4_WlDGywTzEE for ; Fri, 9 Sep 2016 07:49:46 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13B7E12B17A for ; Fri, 9 Sep 2016 07:49:19 -0700 (PDT) Received: from [10.32.60.112] (50-1-99-230.dsl.dynamic.fusionbroadband.com [50.1.99.230]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u89EnHTA043557 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 9 Sep 2016 07:49:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-99-230.dsl.dynamic.fusionbroadband.com [50.1.99.230] claimed to be [10.32.60.112] From: "Paul Hoffman" To: dbound@ietf.org Date: Fri, 09 Sep 2016 07:49:17 -0700 Message-ID: <74DB5D07-3CD9-4052-A8FD-3F07EBD99C22@vpnc.org> In-Reply-To: <20160909013209.39252.qmail@ary.lan> References: <20160909013209.39252.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 14:49:48 -0000 On 8 Sep 2016, at 18:32, John Levine wrote: > I have more opinions, but before expressing them I'd like to see > whether anyone other than the two of us is paying attention. I am paying attention but have conflicting internal opinions on the proposals. Overall, though, I hope that this group does in fact do one of them and that the result of that is also useful for the web folks in some undetermined way. --Paul From nobody Sat Sep 10 08:54:31 2016 Return-Path: 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 D7BB312B14F for ; Sat, 10 Sep 2016 08:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com 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 yysjeDIaEgdE for ; Sat, 10 Sep 2016 08:54:28 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 7008112B015 for ; Sat, 10 Sep 2016 08:54:28 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id w193so8619975oiw.2 for ; Sat, 10 Sep 2016 08:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=//HVfo0lWR1BT/ldLa1wUVeEwtQdC3JPAoIUTD8BNIE=; b=Q/cEAarpD/GRdReZfRp3H2NL1BjbONo2GLUjv2vCgTxxMFaDA68hu7MG/yOQey8tdT a/tuh6nNrFvMubCJjO5fztKnWdmt9odYmjIYpQvOTGktRtusOwQBsje6WFzPCBg56LEp BqL6vUyAjCbcFPEPGQ7iu9MDChB4jmuJIUozU= 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=//HVfo0lWR1BT/ldLa1wUVeEwtQdC3JPAoIUTD8BNIE=; b=U0udCSs4c89J+Kg2Y+Dlregi5IkgwB/QZVkE1/1mdiF9K2Fwekla9kqVP9sxdzlwBL m2tyvgQBXQFFL+NfQWTS1Wh91byEIA7sGzKaBWU7KGlYPxpd9QmcpsUztqxWSO1Gvt+m 8C1UDgZQwR4MeRKwhjSCujm1HEp6lmk09igqSINEWxFuI261ZfXgxk19BgDuagtDeV3q DuX1PRIStE7ABvYEG0QYFjyUMtNehILfyBt1lqIPeMrpv2YdzxGOlO/nf3201XxGvYDC LVDHJzMD4nycd+oPppalBSDjXsHjEbjFg+fBk6LTZpSDbgysG7k9cK9K+ca+cTHOwkJs 2FVw== X-Gm-Message-State: AE9vXwOZ/GWiZ8FalkP4NlQchBZ+Md64derUpbFpn3hlU0vS9xuu/zjsHRHdwxckL0ciGj208r9/c81vyyKL7A== X-Received: by 10.202.221.194 with SMTP id u185mr12474749oig.99.1473522867601; Sat, 10 Sep 2016 08:54:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.159.16 with HTTP; Sat, 10 Sep 2016 08:54:26 -0700 (PDT) In-Reply-To: <20160909013209.39252.qmail@ary.lan> References: <20160909013209.39252.qmail@ary.lan> From: Kurt Andersen Date: Sat, 10 Sep 2016 08:54:26 -0700 Message-ID: To: John Levine Content-Type: multipart/alternative; boundary=001a113d414617a456053c29479d Archived-At: Cc: Casey Deccio , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2016 15:54:30 -0000 --001a113d414617a456053c29479d Content-Type: text/plain; charset=UTF-8 On Thu, Sep 8, 2016 at 6:32 PM, John Levine wrote: > > I have more opinions, but before expressing them I'd like to see > whether anyone other than the two of us is paying attention. > > I am, but have not had time to substantively re-engage with the proposals before us :-) --Kurt --001a113d414617a456053c29479d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Sep 8, 2016 at 6:32 PM, John Levine <johnl@taugh.com> wrot= e:

I have more opinions, but before expressing them I'd like to see
whether anyone other than the two of us is paying attention.

=

I am, but have not had time to substantive= ly re-engage with the proposals before us :-)

--Ku= rt=C2=A0

--001a113d414617a456053c29479d-- From nobody Sat Sep 10 14:13:41 2016 Return-Path: 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 ; 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 ; 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 ; 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" To: dbound@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2016 21:13:39 -0000 In article you write: >On Sat, Sep 3, 2016 at 4:57 PM, John Levine 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. From nobody Sat Sep 10 18:46:13 2016 Return-Path: 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 DC02912B1FC for ; Sat, 10 Sep 2016 18:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 kCOnC2dHhRFL for ; Sat, 10 Sep 2016 18:46:09 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::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 87E2B12B014 for ; Sat, 10 Sep 2016 18:46:09 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id h8so25202732qka.1 for ; Sat, 10 Sep 2016 18:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=VUrnZWDYrS55/Pj/zJaDDVRc1lEMEMYR5M02BnbZXGE=; b=BHoCYWUHDdMB+1QHs18e1PisNPYjASCjFWLOywBrtcgXgLSvD6e9XZ8YIZ9oXARfSc Gqz74pfoLQUO+8hWqES7ILh56OfnGJhSB9Dcg+NE3n9kEY5j+Ns3MAqaKtO8TkBmDvFc o5NVaiwCL7x26U0yJbN4//jahkR+vj4kbm4vI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=VUrnZWDYrS55/Pj/zJaDDVRc1lEMEMYR5M02BnbZXGE=; b=hHvzRjsE0nKk3alanbTEcE9/n+e4RKKWY77yy02BFs8NPVkZFBpVbdrjGPG+i79QLM 9BgmnSlGjMHSYOrl/IaZpqLnv+TArlPghD5zYUcowbZXOvrsO6+AyjBoei2nX8tutxAn zPWg8/1Xdbs+YF3dGkf2kagkIry1N3rcXRyOjMRsq5N/c4LTX+m7n080/hfKUKcyqbzV NsfwXmIdISEAW7b6RM4jywv5C7HqCSl39lRmzY/haQJz9FitJ/7ZEy5i2vjYcFC6LeL+ I5GySW2IGMP60fiIDe1LHP0xGxCdlKBA4+jHNdc2b53+24poNwNeZt1H//Iiw8KsmmNa gSHQ== X-Gm-Message-State: AE9vXwNGp3c/2KiHKXYjhhRB6ECbK2IeheadrlCm1BaeIL38UCuiYV18QQcjLsPRTVO58g== X-Received: by 10.55.5.13 with SMTP id 13mr11632386qkf.112.1473558368495; Sat, 10 Sep 2016 18:46:08 -0700 (PDT) Received: from [192.168.1.3] (c-98-252-29-68.hsd1.va.comcast.net. [98.252.29.68]) by smtp.gmail.com with ESMTPSA id w184sm6373032qkw.38.2016.09.10.18.46.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 10 Sep 2016 18:46:07 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_82E7F8C9-0320-4F34-B12B-8FA0FA340362" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Casey Deccio In-Reply-To: <20160910211314.47140.qmail@ary.lan> Date: Sat, 10 Sep 2016 21:46:06 -0400 Message-Id: <8C13CBDD-A213-47F0-8755-C1A5F0190EE9@deccio.net> References: <20160910211314.47140.qmail@ary.lan> To: John Levine X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2016 01:46:12 -0000 --Apple-Mail=_82E7F8C9-0320-4F34-B12B-8FA0FA340362 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi John, > On Sep 10, 2016, at 5:13 PM, John Levine wrote: >=20 > In article = you = write: >=20 >> 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. >=20 > I don't see how that is very useful in practice. The pertinent information was included in the text that immediately = followed the snippet that you included above. Since it was omitted, = I'll include it again here (some emphasis added): > 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 [1]. Downloading = the policy associated with other domains (especially those with heavy = usage) brings lookups to zero for names in those domains. Slightly restated: The point is that if the entire policy-negative realm (current known as = public suffixes) is pulled in using fetch (e.g., using odup2psl.py [1]), = then unless an organizational domain below the policy-negative realm has = introduced custom policy (by the addition of records in the _odup = subdomain), the DNS lookups required are at most one. If the policy for = any arbitrary organizational domain is pulled in using fetch, then no = DNS lookups are required. > 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. I'm not sure I follow your thought patterns. Current behavior: The PSL contains a list of all public suffixes. The organizational = domain for a domain name is immediately below the public suffix = associated with the name [2]. ODUP: Each TLD defines bottom-most boundary of the policy-negative realm in = the DNS namespace below _odup.TLD. The organizational domain for a = domain name is immediately below the policy negative boundary. By having all the _odup.TLD zones locally (i.e., obtained using fetch), = the boundary of the policy negative realm is known to the application = without it making a single DNS query. For something below the policy-negative boundary (e.g., example.com) if = it doesn't already have a local copy of the _odup.example.com zone, then = it must make an on-demand DNS query for the records it is looking for. = In the case where there are no such records (i.e., the default case) an = NXDOMAIN is returned, and the search stops with just one query. On the = other hand, if it does have a local copy of the _odup.example.com zone, = then no DNS queries are required (unless the local copy of the zone = indicates that there is another organizational domain boundary). >> 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 >=20 > 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). These DNS queries go to different parties than DBOUND-related DNS = queries would go, so it really is additional disclosure. I suppose = whether or not that is acceptable is up to the working group. > The horse > has left the barn and I'd rather have the performance. As already described, when fetch is properly applied, there is no = performance disadvantage to ODUP. Performance and privacy do not have = to be mutually exclusive. >> 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. >=20 > 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. The algorithms on the Public Suffix List page [2] and in section 3.2 of = RFC 7489 [3] seem pretty clear. The algorithm is longest match--there = really isn't a notion of "if the domain isn't there". Best regards, Casey [1] https://github.com/verisign/odup [2] https://publicsuffix.org/list/ [3] https://tools.ietf.org/html/rfc7489= --Apple-Mail=_82E7F8C9-0320-4F34-B12B-8FA0FA340362 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi John,

On Sep 10, 2016, at 5:13 PM, = John Levine <johnl@taugh.com> wrote:

In = article <CAEKtLiTpa+5URazZeUNwizkx_ohVkgmk_XPZP3gm7k7PrWaY9w@mail.gmail.= com> you write:

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 pertinent information was included in the text = that immediately followed the snippet that you included above. =  Since it was omitted, I'll include it again here (some emphasis = added):

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 = [1].  Downloading the policy associated with other domains = (especially those with heavy usage) brings lookups to zero for names in those domains.

Slightly restated:

The point is that if the entire policy-negative = realm (current known as public suffixes) is pulled in using fetch (e.g., = using odup2psl.py [1]), then unless an organizational domain below the = policy-negative realm has introduced custom policy (by the addition of = records in the _odup subdomain), the DNS lookups required are at most one.  If the policy for any arbitrary organizational = domain is pulled in using fetch, then no DNS lookups are = required.


 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.

I'm not = sure I follow your thought patterns.

Current behavior:
The PSL contains a = list of all public suffixes.  The organizational domain for a = domain name is immediately below the public suffix associated with the = name [2].

ODUP:
Each TLD = defines bottom-most boundary of the policy-negative realm in the DNS = namespace below _odup.TLD.  The organizational domain for a domain = name is immediately below the policy negative boundary.

By having all the _odup.TLD zones locally (i.e., = obtained using fetch), the boundary of the policy negative realm is = known to the application without it making a single DNS = query.

For something below the = policy-negative boundary (e.g., example.com) if it doesn't already have a local copy of = the _odup.example.com = zone, then it must make an on-demand DNS query for the records it is = looking for.  In the case where there are no such records (i.e., = the default case) an NXDOMAIN is returned, and the search stops with = just one query.  On the other hand, if it does have a local copy of = the _odup.example.com = zone, then no DNS queries are required (unless the local copy of the = zone indicates that there is another organizational domain = boundary).

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

These DNS = queries go to different parties than DBOUND-related DNS queries would = go, so it really is additional disclosure.  I suppose whether or = not that is acceptable is up to the working group.

The horse
has left the barn and I'd rather have = the performance.

As already described, when fetch is properly = applied, there is no performance disadvantage to ODUP.  Performance = and privacy do not  have to be mutually exclusive.

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.

The = algorithms on the Public Suffix List page [2] and in section 3.2 of RFC = 7489 [3] seem pretty clear.  The algorithm is longest match--there = really isn't a notion of "if the domain isn't there".

Best regards,
Casey

= = --Apple-Mail=_82E7F8C9-0320-4F34-B12B-8FA0FA340362-- From nobody Sat Sep 10 20:44:45 2016 Return-Path: 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 2658812B1C6 for ; Sat, 10 Sep 2016 20:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=g+yghOUJ; dkim=pass (1536-bit key) header.d=taugh.com header.b=kSESCpN5 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 4uEJmUm6uY1Z for ; Sat, 10 Sep 2016 20:44:41 -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 0205D12B1C2 for ; Sat, 10 Sep 2016 20:44:40 -0700 (PDT) Received: (qmail 33358 invoked from network); 11 Sep 2016 03:44:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=824d.57d4d326.k1609; bh=J6baNsEsTyFjP6NKheN5/cWzWitbN5ghAph1MDg3kEE=; b=g+yghOUJFGLU/i7SeRJSaakmVrTk+7Q4lxJJTVQWznd1hWn2hnno7jjWZWM3oWVVtwThlmH0C2PiZGX85I2lfsx5qwv/Py2xyHMGUy4vUoBIXoqtCpvIvS2XsIN4/cfvWAIXWHTnBN/shZOSMceE2KNL3ztYEFVGJIzTT+9bo/I3aqwTfdXmt8QtwVNMjCAVMY+9l7YXD9gvgwPt6/yh9i3ea2LtrCUBXSIgZrEZlEWjJ3LdsGVVUWURAQnFqrF1 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=824d.57d4d326.k1609; bh=J6baNsEsTyFjP6NKheN5/cWzWitbN5ghAph1MDg3kEE=; b=kSESCpN5+Rmct6/BJsUd56CLKe5zRuwzt6MkU/futE6CI0awXAziHPp3NVrk8n6fSOskZHsTf2X0P69RTmhMdq+oST3irjOr1XAib3W1r7+hRzbyldE1x7J1BqY3ULQYc9bNLZ892kwZV7NvdFNThgC4wBHQXfoxQNqfm9mTrsrLwTUgdY9x+5J+N90Hm/ahk31T/GNim9QUM/eyvkOeOJYiKhvLN48zTWv0z/nLV41PIIb+7qC+VBkF0lnk5dck Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 11 Sep 2016 03:44:38 -0000 Date: 10 Sep 2016 23:44:39 -0400 Message-ID: From: "John R Levine" To: "Casey Deccio" In-Reply-To: <8C13CBDD-A213-47F0-8755-C1A5F0190EE9@deccio.net> References: <20160910211314.47140.qmail@ary.lan> <8C13CBDD-A213-47F0-8755-C1A5F0190EE9@deccio.net> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2016 03:44:44 -0000 > The pertinent information was included in the text that immediately > followed the snippet that you included above. Since it was omitted, > I'll include it again here (some emphasis added): I have a problem, in that I have read this document multiple times and have no clue what the actual series of queries and responses would be, given the complexity of the lookup algorithm and the situation where some subtrees can be cached via a fetch result. It'd be a big help if you could give some examples. Could you tell us what the queries would be for abc.def.com if the org domain is def.com, or for ghi.blogspot.com, where the org domain is ghi.blogspot.com, or jkl.mno.uk and jkl.mno.co.uk, where the org domains are mno.uk and mno.co.uk? That would certainly clarify things for me. >> The current behavior is typically to look in the PSL and if the domain >> isn't there, the code does whatever it does. ... > The algorithms on the Public Suffix List page [2] and in section 3.2 of > RFC 7489 [3] seem pretty clear. The algorithm is longest match--there > really isn't a notion of "if the domain isn't there". Let's say you're looking up the domain bulgaria.xn--90ae. That's a name in a real TLD, and the TLD doesn't appear in the PSL. What does the code do now? Looking at some of the PSL libraries, the results look pretty random. Some raise exceptions, some fall off the ends of routines and return null or a random result. R's, John From nobody Mon Sep 12 04:40:24 2016 Return-Path: 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 AF48112B24E for ; Mon, 12 Sep 2016 04:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 c0DGCpRmh_zD for ; Mon, 12 Sep 2016 04:40:17 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::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 7A1E012B212 for ; Mon, 12 Sep 2016 04:40:16 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id h8so50087608qka.1 for ; Mon, 12 Sep 2016 04:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C8Y24HTbpew/PhBYdRqFZQfpcRCTeuvKGHkKlfn5jao=; b=R1d50eoKRERC4P+R5ko+HkcP4Hb2vYTxf8hjolDAz+Q2Rfldxf0vmaMwrC9UQby/9D Y/ApU1gMDtGSBPFYEYrK2DEDUv4RHWkFnRkOrZ/9JfA5FVwcSfzLVQJ42KuBppk7G1cN l0IK1PWAXWtCGyIxcRgDtvmuq+tr2ZMtvQUT4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C8Y24HTbpew/PhBYdRqFZQfpcRCTeuvKGHkKlfn5jao=; b=SZHuERr94VVJ0AnzrxPwdLGDyGhUFwplQBrCoPcZPIQefw5Rc+lV2DiqYnGm4TtvGR lT66E0yUgbqbew8w9MNTfqxu9N6FIC8UdyIPXQ7+5dKDTWMr+F2t3d+lAkmAo+wwYRPH moGBwxV8Ugs5QnOiVadso3qFy2krTx3d+k9yybcfZyVKg7890q92VUBRALw3LgqJ9FVe Ve8BfJU07cqSWsalBISZZpbBB7hav5oj3ZWA8/kFVkicDDT0pYRhqGg3cwB7bP7inyU4 1M6rIyseL6YeBLNBUxJvBRjpy5LkWoYNu1ALnyQCyNyLvsoOP/0OWLrVnJvI459d7/GJ us5A== X-Gm-Message-State: AE9vXwNNuma6KaojCs0mF4MAzirfYYgb/KFTGNhOt6KWmq/5HMh8ywS2mNCMGOEfudfrVg== X-Received: by 10.55.140.131 with SMTP id o125mr19018627qkd.17.1473680415567; Mon, 12 Sep 2016 04:40:15 -0700 (PDT) Received: from restricted.vcorp.ad.vrsn.com ([216.168.230.9]) by smtp.gmail.com with ESMTPSA id z34sm4819820qta.29.2016.09.12.04.40.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 12 Sep 2016 04:40:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Casey Deccio In-Reply-To: Date: Mon, 12 Sep 2016 07:40:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160910211314.47140.qmail@ary.lan> <8C13CBDD-A213-47F0-8755-C1A5F0190EE9@deccio.net> To: John R Levine X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 11:40:19 -0000 > On Sep 10, 2016, at 11:44 PM, John R Levine wrote: >=20 >> The pertinent information was included in the text that immediately = followed the snippet that you included above. Since it was omitted, = I'll include it again here (some emphasis added): >=20 > I have a problem, in that I have read this document multiple times and = have no clue what the actual series of queries and responses would be, = given the complexity of the lookup algorithm and the situation where = some subtrees can be cached via a fetch result. It'd be a big help if = you could give some examples. Sure. Please see Section 6, "Examples": = https://tools.ietf.org/html/draft-deccio-dbound-organizational-domain-poli= cy-03#section-6 Table 1 has all the ODUP-related DNS entries. Figure 1 shows a = representation of the affected namespace tree in question. Figure 2 = shows all the queries and responses to ODUP-resolve each and every name = in the tree, as the rule in the algorithm corresponding to each = response. Table 3 shows the resolution result. If you have some local data via fetch, then it's simply as if you didn't = have to perform those DNS lookups. For example, if I have fetched = "_odup.uk", then anything under "_odup.uk" doesn't need to be looked up = in the DNS. That includes: a._odup.uk, g.co._odup.uk, and _odup.uk, for = example. >=20 > Could you tell us what the queries would be for abc.def.com if the org > domain is def.com See example for: b.a.uk > , or for ghi.blogspot.com, where the org domain is > ghi.blogspot.com See example for: c.b.a.uk (not an exact match, but it's close enough) > jkl.mno.uk and jkl.mno.co.uk, where the org domains > are mno.uk and mno.co.uk? See the examples for b.a.uk and g.co.uk. > That would certainly clarify things for me. Hope that helps. >>> The current behavior is typically to look in the PSL and if the = domain >>> isn't there, the code does whatever it does. ... >=20 >> The algorithms on the Public Suffix List page [2] and in section 3.2 = of RFC 7489 [3] seem pretty clear. The algorithm is longest = match--there really isn't a notion of "if the domain isn't there". >=20 > Let's say you're looking up the domain bulgaria.xn--90ae. That's a > name in a real TLD, and the TLD doesn't appear in the PSL. What does > the code do now? Looking at some of the PSL libraries, the results > look pretty random. Some raise exceptions, some fall off the ends of > routines and return null or a random result. Fair enough. Admittedly, the principles behind the current PSL are = actually more robust than the current algorithm, data, and = implementations. In theory, given a perfectly complete and accurate = PSL, if there's no match, the "public suffix" is the root, which makes = the organizational domain the TLD. In the past this doesn't necessarily = make sense, particularly for the cases for which the PSL was originally = designed. However, TLDs aren't what they used to be. It is clear that = many are not intended for general registration, and the TLD itself very = well could be the organizational domain. Casey= From nobody Mon Sep 12 06:07:56 2016 Return-Path: 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 2BADB12B229 for ; Mon, 12 Sep 2016 06:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=gETBiVw/; dkim=pass (1536-bit key) header.d=taugh.com header.b=cX3jCEAK 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 MsARnusMLlTs for ; Mon, 12 Sep 2016 06:07:51 -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 994C712B1B4 for ; Mon, 12 Sep 2016 06:07:51 -0700 (PDT) Received: (qmail 14222 invoked from network); 12 Sep 2016 13:07:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=378c.57d6a8a5.k1609; bh=6q33n5M0h9INYSOmtJCWG0VOEoyMnj7AuD5he68wZWM=; b=gETBiVw/8oTWC9bDoWsGMjo8INZd2QQ/syFBi/znwGOESiC3TadI4hU4ElykkdzvpTIGz0jsFqPwm1XMXhuidirD1Syu9EVpeH3Z19hUh4kwRaAFPs9zw6IaBe1vSnhWNNnphNOSRYJLFk6KhPgF8mN3WaefkzaBt2jQ20YvJmvcXcx9JSrnMFKEEcF02Z3qnXOFrZziNxuXlOMO+Vu6S1bcV5QHcNUmpTn7ZS3RB/GVqS73QI16rsozpkSxtGuk DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=378c.57d6a8a5.k1609; bh=6q33n5M0h9INYSOmtJCWG0VOEoyMnj7AuD5he68wZWM=; b=cX3jCEAKdEen/uTHKWkGr3hZJ1WfTY37gJJKAQ0WD/jxo6YQO+EJo/yZJ2V4fV4TS/JHJgAXmJ0COEolPOlUp5RnAKc/h4Qn8Y7nvsNY8SOP2Tn2CeQfyDxnnBwCrBbIXu6brGDRG+3CFRmJLrfas21wN7Vh6JxwUep5lXUxnrk3l73cKV4skOdR3OLblGCsyn5XRDTcSTlOdCN5P32VZ+AdFgnTiI5n4z23AQ16yfqLz02OEvyEyi3pcNzm9ido Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 12 Sep 2016 13:07:48 -0000 Date: 12 Sep 2016 09:07:49 -0400 Message-ID: From: "John R Levine" To: "Casey Deccio" In-Reply-To: References: <20160910211314.47140.qmail@ary.lan> <8C13CBDD-A213-47F0-8755-C1A5F0190EE9@deccio.net> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 13:07:56 -0000 > Sure. Please see Section 6, "Examples": Ah, of course. Oops. I mostly wanted to clarify that odup does a tree walk, so if a hostile sender used addresses like a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.blah.example it could produce a lot of noise traffic. > Fair enough. Admittedly, the principles behind the current PSL are > actually more robust than the current algorithm, data, and > implementations. ... In practice, people will write libraries to wrap the calls, and they'll do whatever they do if they don't find the data they're looking for. I agree there's no obvious default, since you can't tell by inspection whether a TLD is a private vanity TLD, a gTLD that delegates at the second level, or something else. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Sep 12 06:30:51 2016 Return-Path: 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 61CDF12B295 for ; Mon, 12 Sep 2016 06:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mozilla-org.20150623.gappssmtp.com 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 gSo2FyBZ8Gwe for ; Mon, 12 Sep 2016 06:30:40 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 548DD12B2A1 for ; Mon, 12 Sep 2016 06:30:40 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id c131so58117741wmh.0 for ; Mon, 12 Sep 2016 06:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=3AV4oNYflCiVIyjbQyN49CmvhfDzZDI43y5piwEZf3E=; b=MS/qlts/XVPSIu6vYCmsremOo5T5gVXBmpN+8DfRHDnrUJL+vm4g4W0eEdqqV0OG5Q c7ILb2nhiEYslWuulZhAaWMdU/cs/jNV6yw5FW/+I16h2aoizcFrsLJzEFhZ8Bxthx3f zloRHfYXrR4Ea/d0bH2u2+MMAEuyXWCy6lG8aYns51uV5GfAjtuiZb+WT8f+f3oO+SiV dcWv/B5PtIAisgUmVtBSl9jIVM5M2MpFGslnT0J37uLxz/UOiOu4Klf6yBPQ90g1yNvq NvV1oCO1UB83N7kkWgaQMEtB+ImWuluqhmbUP0cayFKB8HdugMEbV8ulSSfOrVMx76x2 RmLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=3AV4oNYflCiVIyjbQyN49CmvhfDzZDI43y5piwEZf3E=; b=VNxY+JIq6RYelQVotxx4qklz2iIfF0jx+P7t9NEEq+wufClW0c4OeE+VdKbBOJIxo/ kYnBj/NWH9V6U/tvzNspbj0L6LwodkJg1EM9x/E31GJszedbyZwmi4mRKi620iI8EYst ft2Fp270tMDBQxrG52T/bQiNbd6uQoKAFi2f1EnA6fpwFzdKcpDRU1JMkiJKTPPXsHNv e5rgO1Pzxhahs7ucS12v+mH62/XFxMbZKl/f9jYFE+4uiUahiA8nU3rOfj860vyfXaB+ LLH4lB6FwhejIlyQThHKeR6oICFPCNXY/RTG/655Z2Fx4NgwA7NwpEkB8XIhtO+J4Gpx ly8g== X-Gm-Message-State: AE9vXwP5G2lf3jK6AvskFEADdpCYzfyvWT3fE/V40RpJS5S0AhHCxL4cn0jonmvPwvxt5qww X-Received: by 10.28.15.194 with SMTP id 185mr11062699wmp.58.1473687037156; Mon, 12 Sep 2016 06:30:37 -0700 (PDT) Received: from [192.168.0.14] (cpc101302-bagu16-2-0-cust1610.1-3.cable.virginm.net. [86.21.118.75]) by smtp.gmail.com with ESMTPSA id f10sm17867428wje.14.2016.09.12.06.30.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Sep 2016 06:30:35 -0700 (PDT) To: John R Levine , Casey Deccio References: <20160910211314.47140.qmail@ary.lan> <8C13CBDD-A213-47F0-8755-C1A5F0190EE9@deccio.net> From: Gervase Markham Message-ID: Date: Mon, 12 Sep 2016 14:30:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 13:30:43 -0000 On 11/09/16 04:44, John R Levine wrote: > Let's say you're looking up the domain bulgaria.xn--90ae. That's a > name in a real TLD, and the TLD doesn't appear in the PSL. What does > the code do now? Looking at some of the PSL libraries, the results > look pretty random. Some raise exceptions, some fall off the ends of > routines and return null or a random result. The PSL algorithm states that if the suffix of a given domain name is not in the PSL, then the public suffix is the last label - so "xn--90ae" in your example. And the PSL+1, or "registered/registrable domain" would be bulgaria.xn--90ae. Whether this is always correct is a matter for discussion, and whether libraries do this is a matter for their authors, but that's what the spec says. See "Algorithm", bullet 2: https://publicsuffix.org/list/ Gerv From nobody Mon Sep 12 06:32:33 2016 Return-Path: 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 7386212B0A3 for ; Mon, 12 Sep 2016 06:32:32 -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, 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 QmudogPIfL9M for ; Mon, 12 Sep 2016 06:32:29 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 1AEBB12B0A6 for ; Mon, 12 Sep 2016 06:32:26 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id v189so133847594vkv.1 for ; Mon, 12 Sep 2016 06:32:26 -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=CqKSK0kwAPSQqT0VqZ14RyRIiN5MiSoSuEi47QqDR5I=; b=SlVg2NmFOQQ6Bvabeqo5363+nHszR5ZxXL4GjZWPx9h5MTUHF5cHhJxDot4jo6+VRC hRVtzz1xi3payTUahaiZ8Ql4mQegcv7acvmYLJYWP0uTb/YXh49dXcDoWLAsXl8Jn3gx dmdvPc76UwSMdxiuk5PfqnbVbTuWV39CK60QA= 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=CqKSK0kwAPSQqT0VqZ14RyRIiN5MiSoSuEi47QqDR5I=; b=IngXFalO2jTwLiaHppLmn9rUAfLAXvleT1riDzijsTj7nzgRZHfo+YeouKoHV1NfEd sH5hvZhp81WxbRK1ptcerWOTM4o+yHhdE2ErI/Iz0KKZ275xlI8ByCZj9JaphFWqIrzz T3nxPygnWs6uMwkB4/M3TM9bCkFZD3epYbr6JyNN5FzdVzKU5mGD2DGAIFim6toBV2l0 ZcUVq/WyEbvAgZSzR/ubHODJb3W/VUb7yXnb4mbSATv+VQR5bC2EjvANFNO/waIXFXCL w7isDqlZ1yxccUt/XZX74GXilkOiM0E3hBbUcp2z7RTuQi2T6gfTF1jHdexlxilkpvaQ Oalw== X-Gm-Message-State: AE9vXwOLjm/wrDBqcvx/9S6gWNeNhu45CMb7O4vkVLMfGVLSCLYpiVeCeTFpP9utHm1DXsRGWzXAtNG74fQzsA== X-Received: by 10.31.164.16 with SMTP id n16mr10855611vke.18.1473687144876; Mon, 12 Sep 2016 06:32:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.70.77 with HTTP; Mon, 12 Sep 2016 06:32:24 -0700 (PDT) In-Reply-To: References: <20160910211314.47140.qmail@ary.lan> <8C13CBDD-A213-47F0-8755-C1A5F0190EE9@deccio.net> From: Casey Deccio Date: Mon, 12 Sep 2016 09:32:24 -0400 Message-ID: To: John R Levine Content-Type: multipart/alternative; boundary=001a114165eac7e287053c4f8676 Archived-At: Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 13:32:32 -0000 --001a114165eac7e287053c4f8676 Content-Type: text/plain; charset=UTF-8 On Mon, Sep 12, 2016 at 9:07 AM, John R Levine wrote: > Sure. Please see Section 6, "Examples": >> > > Ah, of course. Oops. I mostly wanted to clarify that odup does a tree > walk, so if a hostile sender used addresses like > a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.blah.example it could > produce a lot of noise traffic. > Yes - it all depends on the DNS setup on the other side. That is common to both proposals. > Fair enough. Admittedly, the principles behind the current PSL are >> actually more robust than the current algorithm, data, and implementations. >> ... >> > > In practice, people will write libraries to wrap the calls, and they'll do > whatever they do if they don't find the data they're looking for. I agree > there's no obvious default, since you can't tell by inspection whether a > TLD is a private vanity TLD, a gTLD that delegates at the second level, or > something else. > Yes - no obvious default of the nature of a name is the reason why the PSL and DBOUND exist :) My point in the earlier email was that the algorithm should be well defined and with a sane default, so once deployed, if nobody does anything different, their behavior doesn't change. Casey --001a114165eac7e287053c4f8676 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 12, 2016 at 9:07 AM, John R Levine <johnl@tau= gh.com> wrote:
Sure.=C2=A0 Please see Section 6, "Examples":

 Ah, of course.=C2=A0 Oops.=C2=A0 I mostly wanted to clarify that odup does = a tree walk, so if a hostile sender used addresses like a.b.c.d.e.f.g.h.i.j= .k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.blah.example it could produce a = lot of noise traffic.

Yes - it all depe= nds on the DNS setup on the other side.=C2=A0 That is common to both propos= als.
=C2=A0
Fair enough.=C2=A0 Admittedly, the principles behind the current PSL are ac= tually more robust than the current algorithm, data, and implementations. .= ..

In practice, people will write libraries to wrap the calls, and they'll= do whatever they do if they don't find the data they're looking fo= r.=C2=A0 I agree there's no obvious default, since you can't tell b= y inspection whether a TLD is a private vanity TLD, a gTLD that delegates a= t the second level, or something else.

= Yes - no obvious default of the nature of a name is the reason why the PSL = and DBOUND exist :)

My point in the earlier email was that the algor= ithm should be well defined and with a sane default, so once deployed, if n= obody does anything different, their behavior doesn't change.

Casey
--001a114165eac7e287053c4f8676-- From nobody Mon Sep 12 07:34:39 2016 Return-Path: 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 053D812B539 for ; Mon, 12 Sep 2016 07:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=EBj3jXxP; dkim=pass (1536-bit key) header.d=taugh.com header.b=MRo3KXQf 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 Mtt23p9S2HLJ for ; Mon, 12 Sep 2016 07:34:33 -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 C768A12B33C for ; Mon, 12 Sep 2016 07:17:08 -0700 (PDT) Received: (qmail 31838 invoked from network); 12 Sep 2016 14:17:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=7c5d.57d6b8e2.k1609; bh=QC0xq+lOD7rD/m9WdleTtxYAbmh5m9nR1a0fpbrW3cg=; b=EBj3jXxPsbTcBixMwUZUgm6rVHrHryEs2+o7Kk5S2cjZ9a2qIBtn/SZjVzmIUo4K6t6jxFKCkoGsyc8ve9sku8XSFHUiYFnRHkehsixXOfBKg883Upl81m8K9isxLpSJdMKQ68e5uUeIABWij6dI5wvWQ5H1HjAGdilo2CM2cUwoCnclqnvb3jBUTQYQLzfxDpcRxi3Vuomot9j4G7Q42adtODStUfbzim+DSEX3c1VGjYFTWZ+I7OqTL8guxFRP DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=7c5d.57d6b8e2.k1609; bh=QC0xq+lOD7rD/m9WdleTtxYAbmh5m9nR1a0fpbrW3cg=; b=MRo3KXQfABw8TYRBVqGv5arFABuyq082MIab4Qvn1UdNLeVKLd3JnmnztT9aNDD2MKCWo8btGAiNxI45803yokWNgZII31RyrAyuDhTYLs/3JIMvLuPkuhFFCeBZEeA26HswCWjewQf7A5SAJWd4ueyHFjgsoCTpfHOCaa3VoYKogwa3MbCaEB2+yCYyUAYMbzh4ts5NUfU6f+huh1XtGusRcTqfL92CfvISLO+lGSddfsQ+OJPcBdbgW1N/0Siw Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 12 Sep 2016 14:17:06 -0000 Date: 12 Sep 2016 10:17:07 -0400 Message-ID: From: "John R Levine" To: "Casey Deccio" In-Reply-To: References: <20160910211314.47140.qmail@ary.lan> <8C13CBDD-A213-47F0-8755-C1A5F0190EE9@deccio.net> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 14:34:38 -0000 >> Ah, of course. Oops. I mostly wanted to clarify that odup does a tree >> walk, so if a hostile sender used addresses like >> a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.blah.example it could >> produce a lot of noise traffic. > > Yes - it all depends on the DNS setup on the other side. That is common to > both proposals. Nope. In my proposal the number of lookups depends on the number of boundaries, not the number of components. There'd be a lookup for a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.blah._bound.example which would be matched by *._bound.example. If that returned an answer saying that there's a boundary at .example, there'd be a second lookup a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z._bound.blah.example that would return NXDOMAIN if there's no subdelegation, and then it's done. The design uses on the closest encloser rule for wildcards to let it publish irregular boundaries like *.uk and *.ac.uk. > My point in the earlier email was that the algorithm should be well defined > and with a sane default, so once deployed, if nobody does anything > different, their behavior doesn't change. That'd be fine with me, but I wouldn't count on implementers paying more attention to this default than to the one for the current PSL. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Sep 12 07:43:28 2016 Return-Path: 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 B6A8012B733 for ; Mon, 12 Sep 2016 07:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 XFJPJ8GCZD3z for ; Mon, 12 Sep 2016 07:43:22 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 B401312B2AA for ; Mon, 12 Sep 2016 07:26:27 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id f76so136883559vke.0 for ; Mon, 12 Sep 2016 07:26:27 -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=PTTPfLSDYmtIta4F1lYH8vY/scuL8uwnO86Xc/53yKs=; b=YAZYjNJ0Exx0XSABjcHXA7t3Bw6DUQKSt+CQ1uHKq97UA5FGaCvUsir/5kXtE076uH ogZux4KbbSSSBz7MXgjD9GkG/cfC1DZVBh5Kr3WYVD9mmg/9JeZQDgMdG2IezRY/kefW /eOupGZZT20wfSn4Qm9YE5FL1q+Px2+fR8HUs= 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=PTTPfLSDYmtIta4F1lYH8vY/scuL8uwnO86Xc/53yKs=; b=WlhkJMqYHSPH1v+zYHNMbg6bNB/T8ySzV0MtlZEj1GIdn9ULVccdMZ9fgrVa/UMb2q SYEc45tElzltTw4Y7mGhs5fwNPseNcn3iL1fqURNWmv/yXqbJVWa2LMPSOs9jDSqXTJD 6fXfmmdIJO5UGkxEPnO4eAdI/ECWhKxr9lJmzao+A6I9D2x0b8SMM4nve1fK8UfQ5Pr3 Dyv7bofeDLE32mzL+ycD4TfCJdEvoNedlN+IRQa0f+taxp/6mF7hFj492umt/PmLy1Wk flVobPSqNUBhZw6X8I3qc1ECkBVgGvNHg1BDJCdmsSZLrLxlKFr34u2pHAR31VxVi4Xa LC9Q== X-Gm-Message-State: AE9vXwPlZBqnB9UEt3wLBD/t+zKTYCF5c+BsEfvG3xyL39uAtqQva0Z7qV9wy5DJUbjEVkSjGBy+S/Ztl4aOxw== X-Received: by 10.31.9.137 with SMTP id 131mr12844705vkj.117.1473690386755; Mon, 12 Sep 2016 07:26:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.70.77 with HTTP; Mon, 12 Sep 2016 07:26:26 -0700 (PDT) In-Reply-To: References: <20160910211314.47140.qmail@ary.lan> <8C13CBDD-A213-47F0-8755-C1A5F0190EE9@deccio.net> From: Casey Deccio Date: Mon, 12 Sep 2016 10:26:26 -0400 Message-ID: To: John R Levine Content-Type: multipart/alternative; boundary=001a11440eb8030d33053c504846 Archived-At: Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 14:43:27 -0000 --001a11440eb8030d33053c504846 Content-Type: text/plain; charset=UTF-8 On Mon, Sep 12, 2016 at 10:17 AM, John R Levine wrote: > Ah, of course. Oops. I mostly wanted to clarify that odup does a tree >>> walk, so if a hostile sender used addresses like >>> a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.blah.example it >>> could >>> produce a lot of noise traffic. >>> >> >> Yes - it all depends on the DNS setup on the other side. That is common >> to >> both proposals. >> > > Nope. In my proposal the number of lookups depends on the number of > boundaries, not the number of components. The moment you said "hostile sender", all bets were off. They make as many "boundaries" or any other component as they want. My point in the earlier email was that the algorithm should be well defined >> and with a sane default, so once deployed, if nobody does anything >> different, their behavior doesn't change. >> > > That'd be fine with me, but I wouldn't count on implementers paying more > attention to this default than to the one for the current PSL. Yes, that's exactly the point of "sane default": don't expect anyone to do anything different. Casey --001a11440eb8030d33053c504846 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 12, 2016 at 10:17 AM, John R Levine <johnl@tau= gh.com> wrote:
Ah, of course.=C2=A0 Oops.=C2=A0 I mostly wanted to clarify that odup does = a tree
walk, so if a hostile sender used addresses like
a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.blah.example = it could
produce a lot of noise traffic.

Yes - it all depends on the DNS setup on the other side.=C2=A0 That is comm= on to
both proposals.

 Nope.=C2=A0 In my proposal the number of lookups depends on the number of b= oundaries, not the number of components.=C2=A0

=
The moment you said "hostile sender", all bets were off.=C2= =A0 They make as many "boundaries" or any other component as they= want.

My point in the earlier email was that the algorithm should be well defined=
and with a sane default, so once deployed, if nobody does anything
different, their behavior doesn't change.

 That'd be fine with me, but I wouldn't count on implementers paying= more attention to this default than to the one for the current PSL.

Yes, that's exactly the point of "sane d= efault": don't expect anyone to do anything different.

Casey
--001a11440eb8030d33053c504846-- From nobody Mon Sep 12 08:08:49 2016 Return-Path: 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 5440112B9D2 for ; Mon, 12 Sep 2016 08:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=q1aWXJEe; dkim=pass (1536-bit key) header.d=taugh.com header.b=ZnP2tzML 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 HLMketNR_-D2 for ; Mon, 12 Sep 2016 08:08:43 -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 3CC1812B5BE for ; Mon, 12 Sep 2016 07:36:52 -0700 (PDT) Received: (qmail 38173 invoked from network); 12 Sep 2016 14:36:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=951c.57d6bd82.k1609; bh=6YzbSX9f/rz2/oMbDlwPkYFpOEths2uWd9xs5XCHfao=; b=q1aWXJEeXOo0qnI0ogDkugAzC7HifQ495ybzQPS+rZxL8AEUxeZBKA7mS6qpRyRa6wWB/5iudO629/EgTJOojy8Vs+T+9z0RcfaLkxmRQiTtzJCpWZjW0saY2Hqc96vDnpma//jMEypllayXJnv3DptTZLDYUvLMMl2qcyGalcJoaudoXuJZBklX3+etSvvvuW4sbbJgyqhaSLPIgeVo8jOEZnvhMGpXflhYF/+WFfSA6LeqSQV4qLM/Qq5BpKH+ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=951c.57d6bd82.k1609; bh=6YzbSX9f/rz2/oMbDlwPkYFpOEths2uWd9xs5XCHfao=; b=ZnP2tzMLeXoJ1lx3udZOAj4VMF49Rc9BjGPSp/atWoOcF2ICWkukVAIH9KfEbWp/MDUsuMhNBE9E42Fu02YALspUWLPiM8KjbNEOZJbUyXTWXRUR7O3TXY3qRAt6Li73S6A9UysuEN9Cy+fQYRf5iF7XVlPd3FAJ+zzDD2WQMqKUjfU1CwvPZyPXcw/yzC1a5YVJKBeO20QYr0pMcI07InLyaVh7gkMzR4/2PJxzpRjaC0jzpzCSuU3RbPzINEBw Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 12 Sep 2016 14:36:50 -0000 Date: 12 Sep 2016 10:36:50 -0400 Message-ID: From: "John R Levine" To: "Casey Deccio" In-Reply-To: References: <20160910211314.47140.qmail@ary.lan> <8C13CBDD-A213-47F0-8755-C1A5F0190EE9@deccio.net> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 15:08:47 -0000 > The moment you said "hostile sender", all bets were off. They make as many > "boundaries" or any other component as they want. Ah, I see your point. I figured most hostile senders will use other people's domains, such as the many wildcarded parked ones. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Sep 12 08:29:49 2016 Return-Path: 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 1CAD912B2F3 for ; Mon, 12 Sep 2016 08:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 Z8woRyXc02mW for ; Mon, 12 Sep 2016 08:29:43 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 9F3DD12B73F for ; Mon, 12 Sep 2016 07:43:44 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id v189so137217721vkv.1 for ; Mon, 12 Sep 2016 07:43:44 -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=AzgzBgkAg6Yy7lVqv1YMUbBkjH6HzxAKGyIA8HYYn8I=; b=fo4JXsJZCGi95FUaguKFvlhEskGQpdSLQhPWfrwaT8qJX5eI7BmADIZBD9D90e1biU zeUs16o6Z1H4tO4h1WxeHrnxJcLWgdFpEQgWdoluAXTBlzMY7J4xMs8yGnUh+6pB9/2O 9yl+TI3kKI+KbCXcFvwjSvDT1Pccym3hbz2ME= 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=AzgzBgkAg6Yy7lVqv1YMUbBkjH6HzxAKGyIA8HYYn8I=; b=GOyL+yIb06qiW6vT1f5BiCQerV9dHtJBdMyyTjSX0+4BgHetF+arEma8mjt+TyYSeE q/FBCki/jmEyjzm2hFmputrIk7hZU6vQdAtV+7DYzdA5v10RdAnyz+VsxYix5cy4Jjtf NpB45rQmhXPMjyONK+YMDYAcxp23M1DKYvViWcOQ9zVQ3oD8D3WEd8Y+1axr286y9es0 kBuLiyjvuvMPj6Ng9Bx6dktmlfqfxvpnqe128vL8nd8KozLBKnyOxD5IOTNzuKRRAeH0 ENRRR21pXK8lPcoz0VDxux0sEVILO6JpHSYYk6MH1MOtdbzKGhIVmSA2dq/CT3adajim 9bMg== X-Gm-Message-State: AE9vXwOq6vBoW82xPJ9AKukx+M0ZjSGLNtANcB/Bl62mGzFXHhyGsdPT26XL4+aYoxYk+4rI1lFziMhtDXVZ7w== X-Received: by 10.31.202.4 with SMTP id a4mr13118363vkg.101.1473691422622; Mon, 12 Sep 2016 07:43:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.70.77 with HTTP; Mon, 12 Sep 2016 07:43:41 -0700 (PDT) In-Reply-To: References: <20160910211314.47140.qmail@ary.lan> <8C13CBDD-A213-47F0-8755-C1A5F0190EE9@deccio.net> From: Casey Deccio Date: Mon, 12 Sep 2016 10:43:41 -0400 Message-ID: To: John R Levine Content-Type: multipart/alternative; boundary=001a114ddefcc11810053c5085d3 Archived-At: Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 15:29:48 -0000 --001a114ddefcc11810053c5085d3 Content-Type: text/plain; charset=UTF-8 On Mon, Sep 12, 2016 at 10:36 AM, John R Levine wrote: > The moment you said "hostile sender", all bets were off. They make as many >> "boundaries" or any other component as they want. >> > > Ah, I see your point. I figured most hostile senders will use other > people's domains, such as the many wildcarded parked ones. Yup. Also, the walking stops at NXDOMAIN, so unless there's policy way down at the bottom (which is possible, but not likely, for the typical user), the walking isn't exhaustive. Casey --001a114ddefcc11810053c5085d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 12, 2016 at 10:36 AM, John R Levine <johnl@tau= gh.com> wrote:
The moment you said "hostile sender", all bets were off.=C2=A0 Th= ey make as many
"boundaries" or any other component as they want.

 Ah, I see your point.=C2=A0 I figured most hostile senders will use other p= eople's domains, such as the many wildcarded parked ones.
<= div>
Yup.

Also, the walking stops at NXDOMAIN, so unle= ss there's policy way down at the bottom (which is possible, but not li= kely, for the typical user), the walking isn't exhaustive.

Casey
--001a114ddefcc11810053c5085d3--