From nobody Sun Nov 1 00:51:30 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2C63A0BF2 for ; Sun, 1 Nov 2020 00:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=UrN6zyvK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KGURbzFe 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 tTKfMSiHLZLe for ; Sun, 1 Nov 2020 00:51:26 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 182DE3A0BDE for ; Sun, 1 Nov 2020 00:51:25 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 8B6667A0 for ; Sun, 1 Nov 2020 02:33:00 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 01 Nov 2020 02:33:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=ELWN4i8f9qdwhxhGFYcqfBgDXKSrkaHAx/BAJBM4smk=; b=UrN6zyvK XmDObgG4+rIp82/iUYifMMVjx+6PfQ4+zGKfIRyMiJsWFcsJTNKc9sH5RG4kC+Vk pbEBkGAk05PPopkDuHJofozXsClwv0Am7YkJcWbsW52SHmobPxd5vq/EfVAHDkRo 7cinM3rmgVX3m8JOpp1E/Z9o8KjKFj//KWQVee45MtRJXHblQ4/zRDgn4EIEVhmo e9tH62/R8I5JkuN/dyl5IY/fQ4VaFrtQeW2jHjFK6690t0vmO5P1C3Fjk6yCF6eN /Qu5aCO77PESednPH8um1Ef3E/xU9qDPb0+Oa6tk7Xj7LoSGFMCmdB7bKZnuCYUS jKpHz7ON4c61rg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=ELWN4i8f9qdwhxhGFYcqfBgDXKSrk aHAx/BAJBM4smk=; b=KGURbzFeQJwWYlRrNXRULtZPpmwHL2yfbYup0YGcDwZ1K /O/C/zHVFtQnCjjN3EmA5AXJMjO/n1NzeByyGQbrw0hMEjf49ms/U0kSTHoQhLSB cFQzsANhuJQwSEULE0YajaPP6eMETgki9zKg8YshvzofZ0OpHNMBxVi6bwlONNBQ 9R1gRj4m6NCrS9Q0MoXNNiwlkbdTI7kKpwrF+H4zTJkLbz9ZQ4CF/1i8w3OagDkd 29oEnUdpGRYAnkRvtbA20qG7eydmogO5N/kZ69kPup7hXIQ/+BxDbiSzPOfh0bUm K/iROcs2y0u2+UWMYdwM/bMjsT9islwXIDK6N7fyg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrleekgddutdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphepuddtgedrvddutddrudehrd egjeenucevlhhushhtvghrufhiiigvpeefnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az60-664.internal.cloudapp.net (unknown [104.210.15.47]) by mail.messagingengine.com (Postfix) with ESMTPA id EF3E73064610 for ; Sun, 1 Nov 2020 02:32:59 -0500 (EST) Content-Type: multipart/alternative; boundary="===============2505024083461848255==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: add@ietf.org Message-Id: <20201101073259.EF3E73064610@mailuser.nyi.internal> Date: Sun, 1 Nov 2020 02:32:59 -0500 (EST) Archived-At: Subject: [Add] Weekly github digest (ADD Activity Summary) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2020 07:51:28 -0000 --===============2505024083461848255== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Pull requests ------------- * ietf-wg-add/draft-add-requirements (+1/-1/=F0=9F=92=AC0) 1 pull requests submitted: - Clean up requirements list (by tfpauly) https://github.com/ietf-wg-add/draft-add-requirements/pull/31=20 1 pull requests merged: - Clean up requirements list https://github.com/ietf-wg-add/draft-add-requirements/pull/31=20 * ietf-wg-add/wg-materials (+1/-1/=F0=9F=92=AC0) 1 pull requests submitted: - Correct use of 24 hour clock (by chris-box) https://github.com/ietf-wg-add/wg-materials/pull/1=20 1 pull requests merged: - Correct use of 24 hour clock https://github.com/ietf-wg-add/wg-materials/pull/1=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-add/draft-add-requirements * https://github.com/ietf-wg-add/wg-materials --===============2505024083461848255== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (ADD Activity Summary)

Sunday November 01, 2020

Events without label "editorial"

Pull requests

ietf-wg-add/draft-add-requirements (+1/-1/=F0=9F=92=AC0)

1 pull requests submitted:

1 pull requests merged:

ietf-wg-add/wg-materials (+1/-1/=F0=9F=92=AC0)

1 pull requests submitted:

1 pull requests merged:

Repositories tracked by this digest:

--===============2505024083461848255==-- From nobody Tue Nov 3 00:45:38 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7F93A153A for ; Tue, 3 Nov 2020 00:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 dvkjnSxzi7fS for ; Tue, 3 Nov 2020 00:45:36 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 301A93A1539 for ; Tue, 3 Nov 2020 00:45:36 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 4CQNf65w7tz7tR1; Tue, 3 Nov 2020 09:45:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1604393134; bh=pOqXyZwWPQcAI4GYKVd5ZF4hhdCVWK7hNeLRHZe4iqk=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=DQUFORPYD7/SoXntRNeOO5CBACBaKrRc0KoyxLx2/xDQAKZ4W0dN7T4PgSAeUC7jz ks8GDkOIK6z6y2DQw19IvfSYkd+k4jkmQPCEuSzKuOUXxAZMpRd83nJ6QvGOzi7vbw MqV472ox14Ep1B2L+g+gsQY2vV5gQL3KT5Strhcx/ZHfEm6+x+Xk0nEqNd3tkEeouF etO2ySIoaToGNRUb658zGQ/X0T44sCu2f9CnA9W7x7x3UbPkz++Q7ubNmRZszNyxZH kBk9PvlMEWYnDTvgLwl1obEn0ji3eZY08E6+Wo5ryFyErgYNuo6mmMHLr9V2Otkwze eESrliCXcIemQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.29]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 4CQNf659x5z3wbM; Tue, 3 Nov 2020 09:45:34 +0100 (CET) From: To: Michael Richardson CC: "add@ietf.org" Thread-Topic: [Add] Fwd: New Version Notification for draft-btw-add-home-09.txt Thread-Index: AQHWlWtgz9eArRaCh0us7zUJ3r3ubam2T6+A Date: Tue, 3 Nov 2020 08:45:34 +0000 Message-ID: <29054_1604393134_5FA118AE_29054_361_1_787AE7BB302AE849A7480A190F8B93303156ED47@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160070133695.29542.17938288314819681829@ietfa.amsl.com> <4877_1600701839_5F68C58F_4877_262_3_787AE7BB302AE849A7480A190F8B9330315439B7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <17447_1600766250_5F69C12A_17447_63_24_787AE7BB302AE849A7480A190F8B933031544085@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <4625.1601155226@localhost> <26930_1601279130_5F71949A_26930_275_7_787AE7BB302AE849A7480A190F8B933031548579@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <26930_1601279130_5F71949A_26930_275_7_787AE7BB302AE849A7480A190F8B933031548579@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-btw-add-home-09.txt X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 08:45:38 -0000 SGkgTWljaGFlbCwgDQoNCkZXSVcsIGFuIHVwZGF0ZWQgdmVyc2lvbiB0aGF0IHRha2VzIGludG8g YWNjb3VudCB5b3VyIHJldmlldyBjYW4gYmUgc2VlbiBhdDogaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWJ0dy1hZGQtaG9tZS0xMC4NCg0KVGhlIGNoYW5nZXMgY2FuIGJlIHRyYWNr ZWQgaGVyZTogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYnR3LWFk ZC1ob21lLTEwLnR4dCANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2lu ZS0tLS0tDQo+IERlwqA6IEFkZCBbbWFpbHRvOmFkZC1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBw YXJ0IGRlDQo+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4gRW52b3nDqcKgOiBsdW5k aSAyOCBzZXB0ZW1icmUgMjAyMCAwOTo0Ng0KPiDDgMKgOiBNaWNoYWVsIFJpY2hhcmRzb24gPG1j citpZXRmQHNhbmRlbG1hbi5jYT47IHRpcnVtYWwgcmVkZHkNCj4gPGtvbmR0aXJAZ21haWwuY29t PjsgYWRkQGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBbQWRkXSBGd2Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtYnR3LWFkZC0NCj4gaG9tZS0wOS50eHQNCj4gDQo+IEhpIE1p Y2hhZWwsDQo+IA0KPiBUaGFuayB5b3UgZm9yIHRoZSBjb21tZW50cy4NCj4gDQo+IFBsZWFzZSBz ZWUgaW5saW5lLg0KPiANCj4gQ2hlZXJzLA0KPiBNZWQNCj4gDQo+ID4gLS0tLS1NZXNzYWdlIGQn b3JpZ2luZS0tLS0tDQo+ID4gRGXCoDogQWRkIFttYWlsdG86YWRkLWJvdW5jZXNAaWV0Zi5vcmdd IERlIGxhIHBhcnQgZGUgTWljaGFlbA0KPiA+IFJpY2hhcmRzb24gRW52b3nDqcKgOiBzYW1lZGkg MjYgc2VwdGVtYnJlIDIwMjAgMjM6MjAgw4DCoDogdGlydW1hbA0KPiByZWRkeQ0KPiA+IDxrb25k dGlyQGdtYWlsLmNvbT47IGFkZEBpZXRmLm9yZyBDY8KgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kv T0xODQo+ID4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IE9iamV0wqA6IFJlOiBbQWRk XSBGd2Q6IE5ldyBWZXJzaW9uDQo+ID4gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1idHctYWRkLSBo b21lLTA5LnR4dA0KPiA+DQo+ID4NCj4gPiBUaXJ1IGFuZCBhdXRob3JzLCBJIHJlYWQgdGhyb3Vn aCBkcmFmdC1idHctYWRkLWhvbWUtMDkuDQo+ID4NCj4gPiBGaXJzdCwgSSBmb3VuZCB0aGUgQ0xP VUQtaXNoIGljb24gZm9yIHRoZSAiTEFOIiBjb25mdXNpbmcuDQo+ID4gSXQgbG9va3MgbGlrZSBp dCBpcyB0aGUgIkgiIGlzIGluc2lkZSB0aGUgQ1BFLg0KPiA+DQo+ID4gICAgICAgICAgICAgICAg ICAgICAgICwtLSwtLSwtLS4NCj4gPiAgICAgICAgICAgICAgICAgICAgLC0nICAgKy0tKyAgYC0u DQo+ID4gICAgICAgICAgICAgICAgICAgKCBMQU4gIHxIIHwgICAgQ1BFLQ0KPiA+ICAgICAgICAg ICAgICAgICAgICBgLS4gICArLS0rICAgLC0nDQo+ID4gICAgICAgICAgICAgICAgICAgICAgIGAt LSd8LSctLScNCj4gPg0KPiA+DQo+ID4gTXkgZXllcyBzZWUgYSBCT1gsIHdpdGggYW4gSVNQIGZh Y2luZyBpbnRlcmZhY2UgbGFiZWxsZWQgIkNQRSINCj4gPiBhbmQgYSBMQU4gZmFjaW5nIGludGVy ZmFjZSBsYWJlbGxlZCAiTEFOIiwgYW5kIHRoZW4gSSBhbSBjb25mdXNlZA0KPiBieQ0KPiA+IHRo ZSBIIGluc2lkZSwgYW5kIHRob3VnaHQgaXQgd2FzIHRoZSBDUEUgYWN0aW5nIGFzIGEgSG9zdC4g IE9ubHkNCj4gYWZ0ZXINCj4gPiBhIGZldyBmaWd1cmVzIGRpZCBJIHVuZGVyc3RhbmQgdGhhdCB0 aGlzIHdhcyBhIExBTiAiY2xvdWQiDQo+IA0KPiBbTWVkXSBZb3UgZ290IGl0IDotKQ0KPiANCj4g VGhlIGludGVudCB3YXMgdG8gZGlzdGluZ3Vpc2ggdGhlIGNhc2Ugd2hlcmUgYSBob3N0IGNvbm5l Y3RlZCAqKg0KPiBmcm9tIHdpdGhpbioqIGEgTEFOIGFuZCB0aGUgY2FzZSB3aGVyZSB0aGUgaG9z dCBpcyBkaXJlY3RseQ0KPiBjb25uZWN0ZWQgKG1vYmlsZSBuZXR3b3JrcywgZm9yIGV4YW1wbGUp Lg0KPiANCj4gPg0KPiA+IEkgc3VnZ2VzdDoNCj4gPg0KPiA+ICAgICArLSsNCj4gPiAgICAgfEh8 DQo+ID4gICAgICstKyAgICAgICAgIC4tLS0tLS0tLg0KPiA+ICAgICAgfCAgTEFOICAgICB8IENQ RSAgICstLS0gLi4gSVNQLWNsb3VkDQo+ID4gICAgICArLS0tLS0tLS0tLSsgICAgICAgfA0KPiA+ ICAgICAgICAgICAgICAgICAnLS0tLS0tLScNCj4gPg0KPiANCj4gW01lZF0gV2lsbCBzZWUgaG93 IHRvIG1ha2UgdGhpbmdzIGNsZWFyZXIuIFRoYW5rcy4NCj4gDQpbLi5dDQoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2Ug bWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3Jt YXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25j CnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9u LiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNp Z25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2Vz IGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBk J2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1l c3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2 aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hv dWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0 aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVz c2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFu ayB5b3UuCgo= From nobody Tue Nov 3 08:34:23 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860613A0D9D for ; Tue, 3 Nov 2020 08:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 qG0UsNiFi6YL for ; Tue, 3 Nov 2020 08:34:20 -0800 (PST) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 1D2273A0D36 for ; Tue, 3 Nov 2020 08:34:20 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 0A3GJ1nN018272 for ; Tue, 3 Nov 2020 08:34:18 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : message-id : date : to; s=20180706; bh=ss8UDTAPSW5NIZG2t80NgYoZllBGqbmmN7eQldIHIpQ=; b=tg7sWQa+NBlKJuwdS5N3sqvhgY4YM+fRrNYjocRnuVc2yxBPMxPgpdLWI6ZHXgp4Mmqe N9XpUel/JLRk0JmM+11928XD3XK8jJuPUCBQRCPHQ/MH1nQj5J9/cdbt9k2nIkHZHlSQ nrpHPHdjD0ZbvP4rt6tgvC79HEwY+Fbfp9ZAWBXO19k8DeSYtCT8iLLQl/yToPTS4L+M 74UoEFj93213rtwq6atUbslnIq1TTLL76g7JW4x5yQv9N/s7ZUHJyjRyN4rZ/8+555o+ +8nT/pC/kEkXiwOfVnTstoL777NILEhvIu/DMb7TooIdJEo5ImwMvAOSa5xdbM0Upvjl bQ== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 34h6wugqsp-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 03 Nov 2020 08:34:18 -0800 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QJ800CEVBD48U40@rn-mailsvcp-mta-lapp04.rno.apple.com> for add@ietf.org; Tue, 03 Nov 2020 08:34:16 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QJ800Q00B24KQ00@rn-mailsvcp-mmp-lapp02.rno.apple.com> for add@ietf.org; Tue, 03 Nov 2020 08:34:16 -0800 (PST) X-Va-A: X-Va-T-CD: aa987671f9cf16b3e83d4d5ef62c6b43 X-Va-E-CD: 3f645d9b4a10fc436a6b2db83d8e5a10 X-Va-R-CD: de59a5c4a8d0aa553fcf6034284d84c7 X-Va-CD: 0 X-Va-ID: 46e0b5b7-5936-4b72-b9e1-efb81767fc96 X-V-A: X-V-T-CD: aa987671f9cf16b3e83d4d5ef62c6b43 X-V-E-CD: 3f645d9b4a10fc436a6b2db83d8e5a10 X-V-R-CD: de59a5c4a8d0aa553fcf6034284d84c7 X-V-CD: 0 X-V-ID: 50859488-68a3-4f17-9db0-4f51b808c9b1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-03_08:2020-11-03, 2020-11-03 signatures=0 Received: from localhost.localdomain (unknown [17.232.167.2]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QJ800Z5NBD33U00@rn-mailsvcp-mmp-lapp02.rno.apple.com> for add@ietf.org; Tue, 03 Nov 2020 08:34:16 -0800 (PST) From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_73599B35-AD1E-405C-84E2-F012AE787F25" MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\)) Message-id: <9DE350EE-F438-435A-8C34-9C15A9744E7A@apple.com> Date: Tue, 03 Nov 2020 08:34:14 -0800 To: ADD Mailing list X-Mailer: Apple Mail (2.3654.0.3.2.26) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-03_08:2020-11-03, 2020-11-03 signatures=0 Archived-At: Subject: [Add] Discovery of Equivalent Encrypted Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 16:34:22 -0000 --Apple-Mail=_73599B35-AD1E-405C-84E2-F012AE787F25 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello ADD, A few of us have written up a simplified description of the mechanism to = use DNS records to discover encrypted DNS servers, focusing on the = clearest cases discussed in the previous interim (bootstrapping from an = unencrypted resolver, etc). https://www.ietf.org/archive/id/draft-pauly-add-deer-00.html = Your comments and thoughts are welcome and appreciated! Best, Tommy= --Apple-Mail=_73599B35-AD1E-405C-84E2-F012AE787F25 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
Hello ADD,

A few of us have written up a simplified description of the mechanism to use DNS records to discover encrypted DNS servers, focusing on the clearest cases discussed in the previous interim (bootstrapping from an unencrypted resolver, etc).

https://www.ietf.org/archive/id/draft-pauly-add-deer-00.html

Your comments and thoughts are welcome and appreciated!

Best,
Tommy
--Apple-Mail=_73599B35-AD1E-405C-84E2-F012AE787F25-- From nobody Tue Nov 3 09:35:33 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5A33A0E11 for ; Tue, 3 Nov 2020 09:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Y6rGELwS4rTb for ; Tue, 3 Nov 2020 09:35:30 -0800 (PST) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 265D73A0DDD for ; Tue, 3 Nov 2020 09:35:30 -0800 (PST) Received: by mail-il1-x132.google.com with SMTP id t13so8916190ilp.2 for ; Tue, 03 Nov 2020 09:35:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TqFRS5VylPvgGwop2Dh0hCJhPocJ3iynHRAI9Ecp730=; b=Ld3RJc6ZmAPRXlOhv3R7n4FKKPaw674YZV0dmZ+bpuiThubyXDj21C89U1WzPpHbSC fcLygyecOmkJ0nb8sEjz67dmMGOopRUMrSMDa4jzKLR2r78MkIchudUA4GQ5w+++jdZ3 mfLAPwIaOneNijU22G8UjdaXU2OhWe4hVs8+2ctYXTGvsT3tRu3kMKgDyyi35BnXM5cU 7YTvJXMxLaRCz3RyZRTc2cmKaY6NRxXv6D+6i6Q14wUWyQTuYttmBO3dxxjWHjHkRp9u XBOYNYvq5xu03rk5TFhcctcgmKfxGPr87dvLsi3qptbsAP+98IMOkOrykHCx9ohdET2v oxBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TqFRS5VylPvgGwop2Dh0hCJhPocJ3iynHRAI9Ecp730=; b=JDLz9hdCXQ35ayDmF0KKC/HvvTpMxkQfiAVaAQAFBDo+mCEf+8yRrxDsDMFCsN1uI8 tM+q1oduQpS5cRTr522SLE0Hs5jU392CgxoPJSElNqT5/pwqq1S86xX68/keal7s6mg7 jozW/DC4je6Y+37jBTS+snfPwidqsZbWiV9Qh/FXoJ9+Hse1v/YWJ+C0T2sV3+3jSO2/ 69zSoFomYEHplU7FPLVA7fPOmTyh4TD+J/M02VlCCP+CwOAsAfYXeT/esw3drjw8G+t6 DLUWhTqUg1O95hhW7gICdabJ9w+PFkdEPIoa+1PQ0c5tzpP0gYggpFbZNvKWyVY5blex CsRQ== X-Gm-Message-State: AOAM530MhEYTk9KBz0L2YMmnFgr7zzfSzqe4MF8po6jZEDNbhsY7WXgX 1mchlT6p5DqJt7RIpYQmj7S6EgMKY3CsN55BpmUncg== X-Google-Smtp-Source: ABdhPJxyEHwmvitTJ0tXssihH9KCm1JfjC3xk1AP0ngb+dKl37r485GJqp/pIC5mK/w/UQ5DF526O19tzqMT3ou4J6M= X-Received: by 2002:a05:6e02:4a9:: with SMTP id e9mr15151113ils.24.1604424929140; Tue, 03 Nov 2020 09:35:29 -0800 (PST) MIME-Version: 1.0 References: <9DE350EE-F438-435A-8C34-9C15A9744E7A@apple.com> In-Reply-To: <9DE350EE-F438-435A-8C34-9C15A9744E7A@apple.com> From: Ben Schwartz Date: Tue, 3 Nov 2020 12:35:17 -0500 Message-ID: To: Tommy Pauly Cc: ADD Mailing list Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000ffc4b005b3374900" Archived-At: Subject: Re: [Add] Discovery of Equivalent Encrypted Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 17:35:32 -0000 --000000000000ffc4b005b3374900 Content-Type: multipart/alternative; boundary="000000000000f8dc2705b3374941" --000000000000f8dc2705b3374941 Content-Type: text/plain; charset="UTF-8" Thanks for this draft. I support this approach, and I think the clear distinction between named, IP-authenticated, and opportunistic modes is very helpful. Some notes: A. Security design > "In order to be considered an authenticated Equivalent Encrypted Resolver, the TLS certificate presented by the Encrypted Resolver MUST contain both the domain name (from the SVCB answer) and the IP address of its equivalent Unencrypted Resolver" Requiring the certificate to cover the TargetName is unusual. Why does it help for the certificate to contain this domain name, if it is also required to authenticate or match the DNS server IP? Is a nontrivial TargetName always required? > "An attacker might try to direct Encrypted DNS traffic to itself by causing the client to think that a discovered Equivalent Encrypted Resolver uses a different IP address from the Unencrypted Resolver." It seems like you are contemplating an attacker who controls the DNS path but not the RA/DHCP path. I'd appreciate seeing a few more words on that beyond the current reference to RA protection. In general, some text on threat modeling might help to justify the design decisions. B. Interaction with other options I would appreciate a sentence on how the opportunistic mode interacts with "probe port 853 for DoT". C. Hints > "These address hints ... avoid additional DNS lookup for the A and AAAA records of the Encrypted Resolver name." Strictly speaking, a compliant SVCB client is expected to perform the additional lookups anyway. The hints just avoid a delay while those queries complete. If you think it's important to "skip" those followup queries, we would have to make a deeper change. Otherwise, you could say "avoid *waiting for* DNS lookup...". On Tue, Nov 3, 2020 at 11:34 AM Tommy Pauly wrote: > Hello ADD, > > A few of us have written up a simplified description of the mechanism to > use DNS records to discover encrypted DNS servers, focusing on the clearest > cases discussed in the previous interim (bootstrapping from an unencrypted > resolver, etc). > > https://www.ietf.org/archive/id/draft-pauly-add-deer-00.html > > Your comments and thoughts are welcome and appreciated! > > Best, > Tommy > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000f8dc2705b3374941 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for this draft.=C2=A0 I support this approach, and = I think the clear distinction between named, IP-authenticated, and opportun= istic modes is very helpful.

Some notes:

<= /div>
A. Security design
> "In order to be considered= an authenticated Equivalent Encrypted Resolver, the TLS certificate presen= ted by the Encrypted Resolver MUST contain both the domain name (from the S= VCB answer) and the IP address of its equivalent Unencrypted Resolver"=

Requiring the certificate to cover the TargetName= is unusual.=C2=A0 Why does it help for the certificate to contain this dom= ain name, if it is also required to authenticate or match the DNS server IP= ?=C2=A0 Is a nontrivial TargetName always required?
> "An attacker might try to direct Encrypted DNS traff= ic to itself by causing the client to think that a discovered Equivalent En= crypted Resolver uses a different IP address from the Unencrypted Resolver.= "

It seems like you are contemplating an atta= cker who controls the DNS path but not the RA/DHCP path.=C2=A0 I'd appr= eciate seeing a few more words on=C2=A0that beyond the current reference to= RA protection.

In general, some text on threat mo= deling might help to justify the design decisions.

B. Interaction with other options
I would appreciate a sentence = on how the opportunistic mode interacts with "probe port 853 for DoT&q= uot;.

C. Hints
> "These addr= ess hints ... avoid additional DNS lookup for the A and AAAA records of the= Encrypted Resolver name."

Strictly speaking,= a compliant SVCB client is expected to perform the additional lookups anyw= ay.=C2=A0 The hints just avoid a delay while those queries complete.=C2=A0 = If you think it's important to "skip" those followup queries,= we would have to make a deeper change.=C2=A0 Otherwise, you could say &quo= t;avoid *waiting for* DNS lookup...".

On Tu= e, Nov 3, 2020 at 11:34 AM Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Hello ADD,

A few of us have w= ritten up a simplified description of the mechanism to use DNS records to d= iscover encrypted DNS servers, focusing on the clearest cases discussed in = the previous interim (bootstrapping from an unencrypted resolver, etc).

https://www.ietf.org/archive/id/draft-paul= y-add-deer-00.html

Your comments and thoughts are we= lcome and appreciated!

Best,
Tommy
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000f8dc2705b3374941-- --000000000000ffc4b005b3374900 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPmAYJKoZIhvcNAQcCoIIPiTCCD4UCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggzyMIIEtjCCA56gAwIBAgIQeAMYYHb81ngUVR0WyMTzqzANBgkqhkiG9w0BAQsFADBMMSAwHgYD VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE AxMKR2xvYmFsU2lnbjAeFw0yMDA3MjgwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFQxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFz IFIzIFNNSU1FIENBIDIwMjAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvLe9xPU9W dpiHLAvX7kFnaFZPuJLey7LYaMO8P/xSngB9IN73mVc7YiLov12Fekdtn5kL8PjmDBEvTYmWsuQS 6VBo3vdlqqXZ0M9eMkjcKqijrmDRleudEoPDzTumwQ18VB/3I+vbN039HIaRQ5x+NHGiPHVfk6Rx c6KAbYceyeqqfuJEcq23vhTdium/Bf5hHqYUhuJwnBQ+dAUcFndUKMJrth6lHeoifkbw2bv81zxJ I9cvIy516+oUekqiSFGfzAqByv41OrgLV4fLGCDH3yRh1tj7EtV3l2TngqtrDLUs5R+sWIItPa/4 AJXB1Q3nGNl2tNjVpcSn0uJ7aFPbAgMBAAGjggGKMIIBhjAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHzM CmjXouseLHIb0c1dlW+N+/JjMB8GA1UdIwQYMBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MHsGCCsG AQUFBwEBBG8wbTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3Ry MzA7BggrBgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvcm9vdC1y My5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIz LmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5n bG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEANyYcO+9JZYyqQt41 TMwvFWAw3vLoLOQIfIn48/yea/ekOcParTb0mbhsvVSZ6sGn+txYAZb33wIb1f4wK4xQ7+RUYBfI TuTPL7olF9hDpojC2F6Eu8nuEf1XD9qNI8zFd4kfjg4rb+AME0L81WaCL/WhP2kDCnRU4jm6TryB CHhZqtxkIvXGPGHjwJJazJBnX5NayIce4fGuUEJ7HkuCthVZ3Rws0UyHSAXesT/0tXATND4mNr1X El6adiSQy619ybVERnRi5aDe1PTwE+qNiotEEaeujz1a/+yYaaTY+k+qJcVxi7tbyQ0hi0UB3myM A/z2HmGEwO8hx7hDjKmKbDCCA18wggJHoAMCAQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUA MEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWdu MRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEg MB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzAR BgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4 Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuu l9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJ pij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh 6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti +w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEA S0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9u bG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaM ld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88 q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/f hO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBNEwggO5oAMCAQICEAE/JGAv3XK3SRaKvGds QSwwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gQXRsYXMgUjMgU01JTUUgQ0EgMjAyMDAeFw0yMDA5MDgy MzQzNTNaFw0yMTAzMDcyMzQzNTNaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFzY0Bnb29nbGUuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7rjWsiqQSnXGFTvs/2JDygQFtWsgF+Ce W2I/wmwCuWH2eNUBYslyudWmJsUMi7IbeSsKHrvBI2P7k6sk5p6o3uFlomiFaDMqXcn76t5GNGym CmHm5KBWxc3LfyvR4C2/wg9oUwbL2xxXc6QQpWWE4ONn9NMHwNC396Ih5u7tcrH5eF49HbVarP5i TindWAOzz++JA3VC/1lIkqWvOt2BcBtxQDUnYp8sr8UnMF/6UqtCd0aHJnKkvYi4o8Qo5Qf3YgiJ DzADzBTf54o3NAI3hiIVKPvz1l0g78IcR29Bt9jUrE33qGzGB6HoY7Z8quhA/ngW2XjuLkIY1ZKX AwTXBQIDAQABo4IBzzCCAcswHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5jb20wDgYDVR0PAQH/ BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUu687mSaB85ui VgNNFSUhtTljkxEwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYmaHR0cHM6 Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wCQYDVR0TBAIwADCBmgYIKwYBBQUHAQEE gY0wgYowPgYIKwYBBQUHMAGGMmh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL2NhL2dzYXRsYXNy M3NtaW1lY2EyMDIwMEgGCCsGAQUFBzAChjxodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2Nh Y2VydC9nc2F0bGFzcjNzbWltZWNhMjAyMC5jcnQwHwYDVR0jBBgwFoAUfMwKaNei6x4schvRzV2V b4378mMwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9jYS9nc2F0 bGFzcjNzbWltZWNhMjAyMC5jcmwwDQYJKoZIhvcNAQELBQADggEBAG9R1/y5PatVOc8xLrAmGgNO /Q4+lbJuHNwX3aIpOkM72Ot4r6r5/IFOSx1pMpmzvrECyy5YQzUGkHV4atuNq5YPPNMGa+XlaKSg oU2dA6RCD40dtwmrPxrKiGAfHPNvfmRvgnx9qxBKFPbKF/Tn8BwKSZCSvx33TnQRfqLUTcgrAarQ dF9Oc45moJrn4nVF0VTTPI6LVminvjg3tLgF2bny1N6CitQnb1t67vpYjeNpcXNIGQzEDaYI3WnK rVeZMcLSY+Z2dQH8HvVsA95vFCTywgiWKq5KxFqz/GdB6JhDWcIJIKCJVUyqD/Bjx47+e4Ye/FuD NDSYc+613Ozl3TkxggJqMIICZgIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFzIFIzIFNNSU1FIENBIDIwMjACEAE/ JGAv3XK3SRaKvGdsQSwwDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIME+vtYBV54+ 16XjpL+echNu/wa4LngtNUlsoZh9iFeKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTIwMTEwMzE3MzUyOVowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJ YIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcN AQEHMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQArNdTqCZMYkIIIe7d/LqMiPFWu7D2R 3u5YMAA3OA4S5ZyO8fjYmhLeQRj6NlfGqvxytWEqcxZz4gj3x2GSKq/JPcaZdnTr9xRZeSTrvOuq jMA8/AIxtKD7D1RWOeAlc3UWTYwNEKYO4JO60IGss6lA4TPxtlSOn98DvK4mKsTyRGsJS5KyPbnF qVjPoOSFAN3gErEOFcoRmm2Cbs09gXhcDHCV9wiQmD3lUhV0qCUrDhz1ok1TeE2i5tKctYFfqXl9 30rlNVYNz3BRMQqeJSgQK3XvSiFWaxKG3srxIz3ZvDC4SMVsxUY4MJjtNyqp9UF1Q/jdZAM+HcnI 5WQJfi5+ --000000000000ffc4b005b3374900-- From nobody Tue Nov 3 11:05:03 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28733A0982 for ; Tue, 3 Nov 2020 11:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 m_DqSb2Ub8jM for ; Tue, 3 Nov 2020 11:05:00 -0800 (PST) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 DF55E3A0639 for ; Tue, 3 Nov 2020 11:04:59 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id o205so9184917qke.10 for ; Tue, 03 Nov 2020 11:04:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=EhvHNNbhmj140UT5uzT3uOSY8aBaN54brG4HCvISbdI=; b=JtRwYtsJSwth3fKKMghet1jLgRdD74n9u+Zo/ZuPKgp48OeJjXos2hYu78+VUFtC4B qvYt20T3erHVq9tlzu/2JebMWi37CQqHufYQU0Gl5CRrA455HT3BQp6i8NNgG4a4JN8/ 347YRc7TVWXQMuZ8cJxLNLQeFEW35/GsD1ERnR7cXPp0OJF/vWbutbGiY8ABGuSFZBzS cT/Io79rog28aQB1g4CZbB4E6YVAeRDoYLxbqFAc5fWDcHEmo3NWG4QHa7Nz0BRdPTKr DVuIdILnhKV3B5d3m7qa7inBHwjtS0OEZqHWT5uI7O3efRf2qSCp14UWVdL6Obf9tfqp 6h3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=EhvHNNbhmj140UT5uzT3uOSY8aBaN54brG4HCvISbdI=; b=Xs1ZQT9KO9RRbKtGbRqmomioGNJ16s6ddhM/RWyWkf/0aNUvEBZ2a8eqkBVlMxUXDu N3Z9tNS8AvGnyNvn5ph11kwUX+3IYrDu3tX5gKuQ+XLIRpHu4ODfXp6T8DGP3dpv6x1I ztPpsNlaZCUwLCzxwIejzX0UD9EgqK3cM5nN2hILcVpJewnOmMuBqf4cOOpSuHETHhts c+ChPTI4RJSJyGqDLpStpt1UnRILf/NamH/bf8J1rRreUi557f9GgvbRXrvO6zoLxW4o bjCmrZG1IowWzedTXRDVwjyGQqDcpUEa+bS8/OgNbqQ/9uyWRHRnOkGV5xXxWyMngC9r K1/Q== X-Gm-Message-State: AOAM530vEiE9uvA7TQPYYOOw/U4tTkgX+HqfJMZwzbFWwJ4yOY5Ci0rp tJN9moLwIYsN/EDaYd4CUVob9D19F2GZqsn1vISbFJuRrfE= X-Google-Smtp-Source: ABdhPJxFES8cx+KitLo/S30Kz0PFmT2cbX6XHQaNFKnGqJqGH+brAbKAvmXU37Nwfc266M2SuWUcepjPAqCeKDZ5g+s= X-Received: by 2002:a05:620a:62b:: with SMTP id 11mr22113795qkv.229.1604430298728; Tue, 03 Nov 2020 11:04:58 -0800 (PST) MIME-Version: 1.0 From: "Chris Box (BT)" Date: Tue, 3 Nov 2020 19:04:47 +0000 Message-ID: To: ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000005cc8705b3388ab0" Archived-At: Subject: [Add] Updated requirements draft X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 19:05:02 -0000 --00000000000005cc8705b3388ab0 Content-Type: text/plain; charset="UTF-8" Hi everyone, As yesterday was deadline day there was of course a surge of new drafts. One of those is a first revision to draft-box-add-requirements. Following the feedback from the first interim, this is now tightly focussed on the "single use case", that of discovering the encrypted resolvers that are claimed to be equivalent to a resolver (e.g. Do53) that the client already knows about. This narrower focus has allowed for more description of the case itself, and there are now 16 tentative requirements that flow from it. Happily it's only 10 pages long. https://tools.ietf.org/html/draft-box-add-requirements-01 I'm sure you will have opinions on the content, and I'd like to hear them. I don't claim the draft is fully correct, but hopefully it's a good basis to start discussion. Please share your thoughts on the list, or directly. Github issues are also possible, but preferably after I've had time to tidy up and respond to the existing ones which I hope to do on Weds or Thurs. Thanks, Chris --00000000000005cc8705b3388ab0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone= ,

As yesterday was deadline day there was of course= a surge of new drafts.

=
One of those is a first rev= ision to draft-box-add-requirements. Following the feedback from the first = interim, this is now tightly focussed on the "single use case", t= hat of discovering the encrypted resolvers that are claimed to be equivalen= t to a resolver (e.g. Do53) that the client already knows about. This narro= wer focus has allowed for more description of the case itself, and there ar= e now 16 tentative requirements that flow from it. Happily it's only 10= pages long.


I'm sure you will have opinions on the content, and I&#= 39;d like to hear them. I don't claim the draft is fully correct, but h= opefully it's a good basis to start discussion.

Please= share your thoughts on the list, or directly. Github issues are also possi= ble, but preferably after I've had time to tidy up and respond to the e= xisting ones which I hope to do on Weds or Thurs.

= Thanks,
Chris


--00000000000005cc8705b3388ab0-- From nobody Tue Nov 3 11:48:16 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23CE3A10FD for ; Tue, 3 Nov 2020 11:48:10 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 TDg3S5KxgzWc for ; Tue, 3 Nov 2020 11:48:09 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 200703A10FE for ; Tue, 3 Nov 2020 11:48:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CEDF138984; Tue, 3 Nov 2020 14:48:07 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id S-sXGXpSRZuO; Tue, 3 Nov 2020 14:48:07 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3D98938982; Tue, 3 Nov 2020 14:48:07 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C01BC1649; Tue, 3 Nov 2020 12:22:29 -0500 (EST) From: Michael Richardson To: mohamed.boucadair@orange.com cc: "add\@ietf.org" In-Reply-To: <29054_1604393134_5FA118AE_29054_361_1_787AE7BB302AE849A7480A190F8B93303156ED47@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160070133695.29542.17938288314819681829@ietfa.amsl.com> <4877_1600701839_5F68C58F_4877_262_3_787AE7BB302AE849A7480A190F8B9330315439B7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <17447_1600766250_5F69C12A_17447_63_24_787AE7BB302AE849A7480A190F8B933031544085@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <4625.1601155226@localhost> <26930_1601279130_5F71949A_26930_275_7_787AE7BB302AE849A7480A190F8B933031548579@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <29054_1604393134_5FA118AE_29054_361_1_787AE7BB302AE849A7480A190F8B93303156ED47@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-btw-add-home-09.txt X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 19:48:11 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable wrote: > Hi Michael, > FWIW, an updated version that takes into account your review can be > seen at: https://tools.ietf.org/html/draft-btw-add-home-10. The diagrams are much clearer, thank you! > The changes can be tracked here: https://tools.ietf.org/rfcdiff?url2= =3Ddraft-btw-add-home-10.txt =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+hkdUACgkQgItw+93Q 3WVcyQf/WUfoIGe1U4zrOAAuH4sAHOvdIeQN1/I2vgMhV1PIq5wnbAVPwdxHyjmK VoOZ8nviGE5nT/KKJAaEAdKuK/yVdQEsUZgcAKiYstDFC6zmg0c2w5xEAfs8yALJ EmYUd+mb8YePrpQESCtZO0vjK4KadKOqfvql5Oelyn9xIFukit1P1fpEbQQeRNao q05g4JkyiEpr8MI0+kF3LiFtKYVRAxWI416qcaPurj7Eyno280lBM5oV87Zu9P9j 8pNqUbsbtBeLV4ju36lIsoEHSYnWE3Y89ngxtR58Cpb75yShXY12qknIH9jSxAFk olBeHhmvea0HIKr+ZLw7ALBxP8wcSg== =ano4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 3 12:03:55 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8513A1110 for ; Tue, 3 Nov 2020 12:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 UuDuRaokcswv for ; Tue, 3 Nov 2020 12:03:47 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 3C4EE3A1117 for ; Tue, 3 Nov 2020 12:03:23 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id u62so19775665iod.8 for ; Tue, 03 Nov 2020 12:03:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c5JxPmyEEm7HYWpjrz0GYSLU6Fmt4NMzShCFzvmfXEM=; b=ag77o0EV5FfxdxKR/nQUubp3BpmGhYCUIXKnXyU8Lds8+JHy1Gg6JQrvmUd0ed8qis 2IdR8JK5sxmjVbSinaaaxgWLmEMwA7Wf5IMHuZ4hOu9EhHYVy9vF4BKQRUMTT2WWlERC Lh+i1OfPOBhFAI25gKRlc0IgFgjKUyoQUTC0/6N+kC7KU8gyfiGZCaWwG7JCiW4K25bN 0F6z54vR+E8T8MN6yq70MkmS3Edn+CDp59mphtrFMSMt+FxpOOy4S/G5XdqSW6dEGTw/ XUY3pwXJj+uXBwv7PJbYuj6F65UbKGd5AmPaiBkXYnfQ/jKtKJnr7m5muxBdJStt8K5y DjRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c5JxPmyEEm7HYWpjrz0GYSLU6Fmt4NMzShCFzvmfXEM=; b=suPpmyGVl057dPchNajwBWD94pSt3+voO2BX/mz+FqmCAUgoqTU6Y0x5fF9JolkwYV nUYwATgi7pzIOTRVpceSwOglqhKUbZI6/ZLlFCfzSp+4067kCGIl4HkLwC+E4mS7dFPI dD7O5ExYy7WMO8kJ9DZnExV2sZWOd514iiW7boRc3zI1KiBVlFf4XlJRkE3lkI9lTojY WkribAfespQWHQZs+WK2k7lNOgj094eT4eYRjkE9xPyio+13aOGu0Lxq3Zp7ORuLaY7M SLzSztkCHnZBmSJUBB65HBh5KrHsbMJA3l4HXZL84SmlGSA/4TvZG05EAia7IFquotNF 8TzQ== X-Gm-Message-State: AOAM530JNKqZMTP4Zi1oMLRozIkXIjg3/xOBpo90jH5JTeNnKiU3J/F9 GUu8nlbeGLaz2uwYuGklgboOrLnFLwc/54MQE5drIA== X-Google-Smtp-Source: ABdhPJyC/iqBfcM4AHWBU8kI5IxoRHCG6C9nS+ppWhLpRYPXH+Qk6lYyDfHgEaOcyBWSVjmkDq/XKOp2Twf/6ktLVaA= X-Received: by 2002:a05:6638:451:: with SMTP id r17mr17737388jap.8.1604433802298; Tue, 03 Nov 2020 12:03:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ben Schwartz Date: Tue, 3 Nov 2020 15:03:10 -0500 Message-ID: To: "Chris Box (BT)" Cc: ADD Mailing list Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000e00d4d05b3395a38" Archived-At: Subject: Re: [Add] Updated requirements draft X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 20:03:50 -0000 --000000000000e00d4d05b3395a38 Content-Type: multipart/alternative; boundary="000000000000da65d705b3395a11" --000000000000da65d705b3395a11 Content-Type: text/plain; charset="UTF-8" Thank you for the updated draft. Some comments: Introduction > it lists > requirements that any proposed discovery mechanisms should address. > They can do this either by providing a solution, or by explicitly > stating why it is not in scope. This seems like a fine sentiment to me, but Sections 3-6 do not seem compatible with it. These sections use phrasings like "a solution is required", "must support", "need to be supported" unconditionally. I think the phrasing should be adjusted so that requirements language only appears in Section 7, where it can be made clear that these are not mandatory. Prior sections should focus on describing the use cases that would benefit if these requirements are met. Section 3.1 > Network-identified is preferred I don't think this is true. For example, it may be operationally preferable to let the resolver keep control of publishing its own configuration, where the potential for skew and confusion is minimized. I also don't think this claim belongs in a requirements document. Section 3.2 > a means is needed for the discovery process to work > from a locally-addressed Do53 resolver to an Encrypted DNS resolver > that is accessible either at the same (local) address, or at a > different global address. Both options need to be supported. I don't think we need to support all imaginable configurations that correspond to our general use case. We only "need" to solve one configuration, and we can consider covering others where it is fruitful to do so. It seems like the motivating use case here is in Section 5 (a forward reference would be helpful). Section 5 > It is frequently the case that Do53 resolvers announced by home > networks are difficult to upgrade to support encrypted operation. I think it would be interesting to elucidate this further. In particular, I think we should distinguish between routers that cannot be upgraded at all, and routers that could receive small patches but would present difficulties when introducing major new functionality. For example, it may be that there are routers that would perform poorly when terminating TLS locally, but could be updated to forward port 853 to the upstream resolver. > it is possible that the only option for encrypted > operation is to refer to a separate globally-addressed encrypted DNS > resolver. I think it would be helpful to explain under what circumstances such a separate resolver would be likely to provide "equivalence" as described in Section 3. Section 6 I like the presentation of the threat model here. I don't understand the point about ensuring an attacker cannot "Influence automatic discovery mechanisms". Does this mean "ensure the attacker cannot interfere with other secure name resolution mechanisms"? Section 7 I like the enumeration structure here. I'm still concerned about the use of normative language. No single "solution" is going to cover all of these requirements, so what is it that these MUSTs mean? I would prefer a non-normative description of each requirement or capability. On Tue, Nov 3, 2020 at 2:05 PM Chris Box (BT) wrote: > Hi everyone, > > As yesterday was deadline day there was of course a surge of new drafts. > > One of those is a first revision to draft-box-add-requirements. Following > the feedback from the first interim, this is now tightly focussed on the > "single use case", that of discovering the encrypted resolvers that are > claimed to be equivalent to a resolver (e.g. Do53) that the client already > knows about. This narrower focus has allowed for more description of the > case itself, and there are now 16 tentative requirements that flow from it. > Happily it's only 10 pages long. > > https://tools.ietf.org/html/draft-box-add-requirements-01 > > I'm sure you will have opinions on the content, and I'd like to hear them. > I don't claim the draft is fully correct, but hopefully it's a good basis > to start discussion. > > > Please share your thoughts on the list, or directly. Github issues are > also possible, but preferably after I've had time to tidy up and respond to > the existing ones which I hope to do on Weds or Thurs. > > Thanks, > Chris > > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000da65d705b3395a11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for the updated draft.=C2=A0 Some comments:
=
Introduction
> it lists
> requirem= ents that any proposed discovery mechanisms should address.
> They = can do this either by providing a solution, or by explicitly
> stati= ng why it is not in scope.

This seems like a fine sentim= ent to me, but Sections 3-6 do not seem compatible with it.=C2=A0 These sec= tions use phrasings like "a solution is required", "must sup= port", "need to be supported" unconditionally.=C2=A0 I think= the phrasing should be adjusted so that requirements language only appears= in Section 7, where it can be made clear that these are not mandatory.=C2= =A0 Prior sections should focus on describing the use cases that would bene= fit if these requirements are met.

Section 3.1
>=C2=A0Netwo= rk-identified is preferred

I don't think this is true.=C2=A0 For example, it= may be operationally preferable to let the resolver keep control of publis= hing its own configuration, where the potential for skew and confusion is m= inimized.=C2=A0 I also don't think this claim belongs in a requirements= document.

Section 3.2
> a means is needed for the discovery= process to work
> from a locally-addressed Do53 resolver to an Encry= pted DNS resolver
> that is accessible either at the same (local) add= ress, or at a
> different global address.=C2=A0 Both options need to = be supported.

I don't think we need to support all imaginable configurations th= at correspond to our general use case.=C2=A0 We only "need" to so= lve one configuration, and we can consider covering others where it is frui= tful to do so.

It seems like the motivating use case here is in Section 5 = (a forward reference would be helpful).

Section 5
>=C2=A0It is frequently= the case that Do53 resolvers announced by home
>=C2=A0networks are= difficult to upgrade to support encrypted operation.

I think it would be interesting to eluc= idate this further.=C2=A0 In particular, I think we should distinguish betw= een routers that cannot be upgraded at all, and routers that could receive = small patches but would present difficulties when introducing major new fun= ctionality.

For example, it may be that there are routers that would perform poo= rly when terminating TLS locally, but could be updated to forward port 853 = to the upstream resolver.

>=C2=A0it is possible that the only option f= or encrypted
>=C2=A0operation is to refer to a separate globally-ad= dressed encrypted DNS
>=C2=A0resolver.

I think it = would be helpful to explain under what circumstances such a separate resolv= er would be likely to provide "equivalence" as described in Secti= on 3.

Section 6
I like the presentation = of the threat model here.

I don't understand t= he point about ensuring an attacker cannot "Influence automatic discov= ery mechanisms".=C2=A0 Does this mean "ensure the attacker cannot= interfere with other secure name resolution mechanisms"?
Section 7
I like the enumeration structure here.

I'm still concerned about the use of normative la= nguage.=C2=A0 No single "solution" is going to cover all of these= requirements, so what is it that these MUSTs mean?=C2=A0 I would prefer a = non-normative description of each requirement or capability.
On Tue, N= ov 3, 2020 at 2:05 PM Chris Box (BT) <chris.box.ietf@gmail.com> wrote:
Hi everyone,

As yesterday was deadline day there was of course a= surge of new drafts.

One of those is a first revi= sion to draft-box-add-requirements. Following the feedback from the first i= nterim, this is now tightly focussed on the "single use case", th= at of discovering the encrypted resolvers that are claimed to be equivalent= to a resolver (e.g. Do53) that the client already knows about. This narrow= er focus has allowed for more description of the case itself, and there are= now 16 tentative requirements that flow from it. Happily it's only 10 = pages long.


I&= #39;m sure you will have opinions on the content, and I'd like to hear = them. I don't claim the draft is fully correct, but hopefully it's = a good basis to start discussion.
<= br>
Please share your thoughts on the list, or directly. Github i= ssues are also possible, but preferably after I've had time to tidy up = and respond to the existing ones which I hope to do on Weds or Thurs.
=

Thanks,
Chris

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000da65d705b3395a11-- --000000000000e00d4d05b3395a38 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPmAYJKoZIhvcNAQcCoIIPiTCCD4UCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggzyMIIEtjCCA56gAwIBAgIQeAMYYHb81ngUVR0WyMTzqzANBgkqhkiG9w0BAQsFADBMMSAwHgYD VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE AxMKR2xvYmFsU2lnbjAeFw0yMDA3MjgwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFQxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFz IFIzIFNNSU1FIENBIDIwMjAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvLe9xPU9W dpiHLAvX7kFnaFZPuJLey7LYaMO8P/xSngB9IN73mVc7YiLov12Fekdtn5kL8PjmDBEvTYmWsuQS 6VBo3vdlqqXZ0M9eMkjcKqijrmDRleudEoPDzTumwQ18VB/3I+vbN039HIaRQ5x+NHGiPHVfk6Rx c6KAbYceyeqqfuJEcq23vhTdium/Bf5hHqYUhuJwnBQ+dAUcFndUKMJrth6lHeoifkbw2bv81zxJ I9cvIy516+oUekqiSFGfzAqByv41OrgLV4fLGCDH3yRh1tj7EtV3l2TngqtrDLUs5R+sWIItPa/4 AJXB1Q3nGNl2tNjVpcSn0uJ7aFPbAgMBAAGjggGKMIIBhjAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHzM CmjXouseLHIb0c1dlW+N+/JjMB8GA1UdIwQYMBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MHsGCCsG AQUFBwEBBG8wbTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3Ry MzA7BggrBgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvcm9vdC1y My5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIz LmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5n bG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEANyYcO+9JZYyqQt41 TMwvFWAw3vLoLOQIfIn48/yea/ekOcParTb0mbhsvVSZ6sGn+txYAZb33wIb1f4wK4xQ7+RUYBfI TuTPL7olF9hDpojC2F6Eu8nuEf1XD9qNI8zFd4kfjg4rb+AME0L81WaCL/WhP2kDCnRU4jm6TryB CHhZqtxkIvXGPGHjwJJazJBnX5NayIce4fGuUEJ7HkuCthVZ3Rws0UyHSAXesT/0tXATND4mNr1X El6adiSQy619ybVERnRi5aDe1PTwE+qNiotEEaeujz1a/+yYaaTY+k+qJcVxi7tbyQ0hi0UB3myM A/z2HmGEwO8hx7hDjKmKbDCCA18wggJHoAMCAQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUA MEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWdu MRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEg MB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzAR BgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4 Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuu l9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJ pij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh 6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti +w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEA S0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9u bG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaM ld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88 q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/f hO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBNEwggO5oAMCAQICEAE/JGAv3XK3SRaKvGds QSwwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gQXRsYXMgUjMgU01JTUUgQ0EgMjAyMDAeFw0yMDA5MDgy MzQzNTNaFw0yMTAzMDcyMzQzNTNaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFzY0Bnb29nbGUuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7rjWsiqQSnXGFTvs/2JDygQFtWsgF+Ce W2I/wmwCuWH2eNUBYslyudWmJsUMi7IbeSsKHrvBI2P7k6sk5p6o3uFlomiFaDMqXcn76t5GNGym CmHm5KBWxc3LfyvR4C2/wg9oUwbL2xxXc6QQpWWE4ONn9NMHwNC396Ih5u7tcrH5eF49HbVarP5i TindWAOzz++JA3VC/1lIkqWvOt2BcBtxQDUnYp8sr8UnMF/6UqtCd0aHJnKkvYi4o8Qo5Qf3YgiJ DzADzBTf54o3NAI3hiIVKPvz1l0g78IcR29Bt9jUrE33qGzGB6HoY7Z8quhA/ngW2XjuLkIY1ZKX AwTXBQIDAQABo4IBzzCCAcswHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5jb20wDgYDVR0PAQH/ BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUu687mSaB85ui VgNNFSUhtTljkxEwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYmaHR0cHM6 Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wCQYDVR0TBAIwADCBmgYIKwYBBQUHAQEE gY0wgYowPgYIKwYBBQUHMAGGMmh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL2NhL2dzYXRsYXNy M3NtaW1lY2EyMDIwMEgGCCsGAQUFBzAChjxodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2Nh Y2VydC9nc2F0bGFzcjNzbWltZWNhMjAyMC5jcnQwHwYDVR0jBBgwFoAUfMwKaNei6x4schvRzV2V b4378mMwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9jYS9nc2F0 bGFzcjNzbWltZWNhMjAyMC5jcmwwDQYJKoZIhvcNAQELBQADggEBAG9R1/y5PatVOc8xLrAmGgNO /Q4+lbJuHNwX3aIpOkM72Ot4r6r5/IFOSx1pMpmzvrECyy5YQzUGkHV4atuNq5YPPNMGa+XlaKSg oU2dA6RCD40dtwmrPxrKiGAfHPNvfmRvgnx9qxBKFPbKF/Tn8BwKSZCSvx33TnQRfqLUTcgrAarQ dF9Oc45moJrn4nVF0VTTPI6LVminvjg3tLgF2bny1N6CitQnb1t67vpYjeNpcXNIGQzEDaYI3WnK rVeZMcLSY+Z2dQH8HvVsA95vFCTywgiWKq5KxFqz/GdB6JhDWcIJIKCJVUyqD/Bjx47+e4Ye/FuD NDSYc+613Ozl3TkxggJqMIICZgIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFzIFIzIFNNSU1FIENBIDIwMjACEAE/ JGAv3XK3SRaKvGdsQSwwDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIOmpR8uLAwln 02Y3fxvHh506TDeQyNgd9i8IDUC0t89iMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTIwMTEwMzIwMDMyMlowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJ YIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcN AQEHMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQAOiQmzaPz5uHgIAgqj3GKAq3K3hZg8 7YzDCk+Tg9JKLst+Xb+ldzy9YczzQu4ON/IWFUU0tTzWLvcJDc0LcMrKDTRsOuchf00JY03w0Nrf jv13kvjxuiDs2LfWdQwKHm+HvW49sU/Sv0QanwGfSYhhORlShpfr2QWVpES2xSHzUUNvbb1v4Thx MNBXI4yJQxTta3KfvtShlcG9z0i98q11UEzTWDFjFOjWZgyHdSUTXImeppXuxcfYn8sm8drh3SON 86NPn+Ctbt1IUXpaKtdqKmJExIw3y3peMjIhiwpFRAlXfFimVKne+zNQiZol7hpfd+1Q9A9XPsIw SNPPm90K --000000000000e00d4d05b3395a38-- From nobody Wed Nov 4 11:02:26 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2AC3A0F41 for ; Wed, 4 Nov 2020 11:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 pKBWbGqQF7DM for ; Wed, 4 Nov 2020 11:02:23 -0800 (PST) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 4F0313A0F22 for ; Wed, 4 Nov 2020 11:02:23 -0800 (PST) Received: by mail-qv1-xf34.google.com with SMTP id 13so1231043qvr.5 for ; Wed, 04 Nov 2020 11:02:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ScZDrFwwyKYCmQz7Qy9wPjb0gIU2RA8Tp9lF+YdLE1Y=; b=ug6cGlFbvyEw33jNgbellqoTWXyj3gdzY7k0TpEdSh3KsaEPrVWbKwMqrea7p3kZcH oj3U/Bh1EGjsLllzgMFKeiwZOX+ojo0UgvkIrD0vsn1HOR+l/nIJ2kGzZmJVk+oCWkx2 g2pyDYMJQ7ZQUZEABCwoqw6hD8oWcxtQU6UrrTRprV8PYknyjMi4xYqB08A7eefSQ0A3 VMSF3QpPO7lIggDWzyZUfvUVX1eG9HT95Z0+My528pOlTm0pFUzSmRSuwDKLbUbJS3u/ EkMj9UB4mWJMhyKjaD+Y7C1KbM91+Da1KC+3zKraofQAwU7g/v9YG2AknOvZ1bhueofH IxZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ScZDrFwwyKYCmQz7Qy9wPjb0gIU2RA8Tp9lF+YdLE1Y=; b=hHVnJ9A1eLxLsZ4JglmmjIK/TPQXq9ZfKco7J8H6UQdtWyaD8KLpcTp1qofHckZ2yz 2myGrIVAvOnW3NbtkrAeEAz4s/SEcEYrhaSzfktvVD+7U+skkHy5f5a/xtAcTfEJEEFj rjKf2QuU/9DVvPY3Awb5dbbLlM4xUa/uKdXYGRf8Hf3CeA4zPpJUAX9jGR0n+EcEKwER INZmFU/lGah3X9Gnjg5tCMESpjuQ1ZpwUs1AMjuviY8R6+ECRLllDEx7wuE3bqaZdC+3 ZTc0jy77w22vlVDapsd2GSNKaC88BRkEzLkVmOOh3nGna9RBgBroaZH03HfH111b+/ZN HFkg== X-Gm-Message-State: AOAM5313n0Qr7PnvNXdj26qLEonHPcp5qHfc8subB5eS4/idianeiYaH v48AIebLUUotP9zAF+3K7u5Ha0iODUGPCB25WpU= X-Google-Smtp-Source: ABdhPJwZO3P08Ekp1XfXFt1BoTOjW09SoGvIU0BrJTfyoFsAlxKzFmAoFZPMk+CGXs6W3xoP3dAkY+jXsqMNOlpvTuU= X-Received: by 2002:a0c:f38b:: with SMTP id i11mr33991376qvk.41.1604516542242; Wed, 04 Nov 2020 11:02:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Chris Box (BT)" Date: Wed, 4 Nov 2020 19:02:13 +0000 Message-ID: To: Ben Schwartz Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000089649b05b34c9eb3" Archived-At: Subject: Re: [Add] Updated requirements draft X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 19:02:25 -0000 --00000000000089649b05b34c9eb3 Content-Type: text/plain; charset="UTF-8" Ben, Thanks for your comments. On Tue, 3 Nov 2020 at 20:03, Ben Schwartz wrote: > Introduction > > it lists > > requirements that any proposed discovery mechanisms should address. > > They can do this either by providing a solution, or by explicitly > > stating why it is not in scope. > > This seems like a fine sentiment to me, but Sections 3-6 do not seem > compatible with it. These sections use phrasings like "a solution is > required", "must support", "need to be supported" unconditionally. I think > the phrasing should be adjusted so that requirements language only appears > in Section 7, where it can be made clear that these are not mandatory. > Prior sections should focus on describing the use cases that would benefit > if these requirements are met. > I'm happy to adjust the phrasing. If it turns out that more than one solution is required to satisfy the requirements, then clearly no single solution would comply with them all. > > Section 3.1 > > Network-identified is preferred > > I don't think this is true. For example, it may be operationally > preferable to let the resolver keep control of publishing its own > configuration, where the potential for skew and confusion is minimized. I > also don't think this claim belongs in a requirements document. > Originally I thought this sentence was uncontroversial, but now you've opened my eyes I can see it's probably best left out. It doesn't need to be there. > Section 3.2 > > a means is needed for the discovery process to work > > from a locally-addressed Do53 resolver to an Encrypted DNS resolver > > that is accessible either at the same (local) address, or at a > > different global address. Both options need to be supported. > > I don't think we need to support all imaginable configurations that > correspond to our general use case. We only "need" to solve one > configuration, and we can consider covering others where it is fruitful to > do so. > > It seems like the motivating use case here is in Section 5 (a forward > reference would be helpful). > Yes I'll add the forward reference. And again, if we cannot have a single solution that meets all requirements of this case, then yes I can see there could be separate solutions for: - Local address Do53 to same local address DoH - Local address Do53 to global address DoH Is this what you mean? Or are you saying that some particular configurations should not be solved? > Section 5 > > It is frequently the case that Do53 resolvers announced by home > > networks are difficult to upgrade to support encrypted operation. > > I think it would be interesting to elucidate this further. In particular, > I think we should distinguish between routers that cannot be upgraded at > all, and routers that could receive small patches but would present > difficulties when introducing major new functionality. > > For example, it may be that there are routers that would perform poorly > when terminating TLS locally, but could be updated to forward port 853 to > the upstream resolver. > This is definitely something that could be explored. > > > it is possible that the only option for encrypted > > operation is to refer to a separate globally-addressed encrypted DNS > > resolver. > > I think it would be helpful to explain under what circumstances such a > separate resolver would be likely to provide "equivalence" as described in > Section 3. > Ok. > > Section 6 > I like the presentation of the threat model here. > > I don't understand the point about ensuring an attacker cannot "Influence > automatic discovery mechanisms". Does this mean "ensure the attacker > cannot interfere with other secure name resolution mechanisms"? > Perhaps Tommy or Chris W could answer this better. > > Section 7 > I like the enumeration structure here. > > I'm still concerned about the use of normative language. No single > "solution" is going to cover all of these requirements, so what is it that > these MUSTs mean? I would prefer a non-normative description of each > requirement or capability. > Not sure how best to proceed on this front. I'd value the opinion of others in the working group too, i.e. what do you consider is the best way to state these requirements? Chris --00000000000089649b05b34c9eb3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ben,

Thanks for your comment= s.

On Tue, 3 Nov 2020 at 20:03, Ben Schwartz <bemasc@google.com> wrote:
Introduction
> it lists
> requirements that any proposed discovery me= chanisms should address.
> They can do this either by providing a s= olution, or by explicitly
> stating why it is not in scope.

=
This seems like a fine sentiment to me, but Sections 3-6 do not = seem compatible with it.=C2=A0 These sections use phrasings like "a so= lution is required", "must support", "need to be suppor= ted" unconditionally.=C2=A0 I think the phrasing should be adjusted so= that requirements language only appears in Section 7, where it can be made= clear that these are not mandatory.=C2=A0 Prior sections should focus on d= escribing the use cases that would benefit if these requirements are met.

I'm happy to adjust th= e phrasing. If it turns out that more than one solution is required to sati= sfy the requirements, then clearly no single solution would comply with the= m all.
=C2=A0

Section 3.1
>= ;=C2=A0Network-identif= ied is preferred

I don't think this is true.=C2=A0 For example, it may be op= erationally preferable to let the resolver keep control of publishing its o= wn configuration, where the potential for skew and confusion is minimized.= =C2=A0 I also don't think this claim belongs in a requirements document= .

Originally I tho= ught this sentence was uncontroversial, but now you've opened my eyes I= can see it's probably best left out. It doesn't need to be there.<= br>
=C2=A0
Section 3.2
> a means is needed for the discovery pro= cess to work
> from a locally-addressed Do53 resolver to an Encrypted= DNS resolver
> that is accessible either at the same (local) address= , or at a
> different global address.=C2=A0 Both options need to be s= upported.

I don't think we need to support all imaginable configurations that c= orrespond to our general use case.=C2=A0 We only "need" to solve = one configuration, and we can consider covering others where it is fruitful= to do so.

It seems like the motivating use case here is in Section 5 (a f= orward reference would be helpful).
Yes I'll add the forward reference. And again, if we cannot= have a single solution that meets all requirements of this case, then yes = I can see there could be separate solutions for:
  • Local ad= dress Do53 to same local address DoH
  • Local address Do53 to glob= al address DoH
Is this what you mean?=C2=A0 Or are you = saying that some particular configurations should not be solved?
<= div>

=
Section 5
>= =C2=A0It is frequently the case that Do53 resolvers announced by hom= e
>=C2=A0networks are difficult to upgrade to support encrypted ope= ration.

I think it= would be interesting to elucidate this further.=C2=A0 In particular, I thi= nk we should distinguish between routers that cannot be upgraded at all, an= d routers that could receive small patches but would present difficulties w= hen introducing major new functionality.

For example, it may be that there are r= outers that would perform poorly when terminating TLS locally, but could be= updated to forward port 853 to the upstream resolver.

This is definitely something that could be e= xplored.
=C2=A0

>=C2=A0it is possible that the only option for encrypt= ed
>=C2=A0operation is to refer to a separate globally-addressed en= crypted DNS
>=C2=A0resolver.

I think it would be h= elpful to explain under what circumstances such a separate resolver would b= e likely to provide "equivalence" as described in Section 3.

Ok.
=C2=A0

Section 6
I like the presentation of the threat model here= .

I don't understand the point about ensuring = an attacker cannot "Influence automatic discovery mechanisms".=C2= =A0 Does this mean "ensure the attacker cannot interfere with other se= cure name resolution mechanisms"?

Perhaps Tommy or Chris W could answer this better.
= =C2=A0

Section 7
I like the enumeration structur= e here.

I'm still concerned about the use of n= ormative language.=C2=A0 No single "solution" is going to cover a= ll of these requirements, so what is it that these MUSTs mean?=C2=A0 I woul= d prefer a non-normative description of each requirement or capability.

Not sure how best to proceed on th= is front. I'd value the opinion of others in the working group too, i.e= . what do you consider is the best way to state these requirements?

Chris
--00000000000089649b05b34c9eb3-- From nobody Wed Nov 4 11:39:03 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC003A0FD2 for ; Wed, 4 Nov 2020 11:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 GDdjy4G3ZvRK for ; Wed, 4 Nov 2020 11:39:00 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 EBE5C3A0E69 for ; Wed, 4 Nov 2020 11:38:59 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id u62so23416680iod.8 for ; Wed, 04 Nov 2020 11:38:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F9cmD/5F28QFC9jsfLlyJ4pB403RDcSeROcRn39VfNg=; b=qrJZ8k5+qsOFLz1uQiS12rYedRCNCk4sQIakuHkUIG23xIYltHFaaaXX0wFOVbUqSm oknOWRMDWbGaMEoCJZWJXo8zHiHZj4B89DUzf7FuTCz+nQw+jsGTxEVIHA6oHlL97uzu cyrOr+6Ew0okNQnsttIauv7DbS3BiQvNS4lJpnJFgWPXEpywy99vRMbE775F+Zt2/TBq jp+yZYYBfZUhZs55Jv4zf4KDsuQXrHOUJDXbvRCIoEe1+9/zA7MOWUrUFwiODfipoarH K8gJ4wWvYRemBXIk7sj3FxEgj9thSb2anILXtnCG6xozq9dB/zr9G+okMAnMt35M3Fht rw6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F9cmD/5F28QFC9jsfLlyJ4pB403RDcSeROcRn39VfNg=; b=RX4EoTVelJkORRbPsGnul2h5ou2dBVrDaaH9XqQonQ0gO5gRBNl4kqrseOcHWnKuXL 2rmfTD/eNZfjdBtYTfUuqQRUE6Yu5q7G1C41rlwlRR8bFFmSab53ahpUpK9LUHVDzxS5 8wiGzwKxOM7mcNIXmBJ4S3eDCz07jcuUGd6SK/sleMGaQr984ZmzfZ7Kek+s9DLV2gMc mIB8dQwxXrueUg3xBJ5ITlnwhu+aLs9mpB10vdw1KWaC1OMvVkk3gh84CRVXSFQ6w7uW x3mAVmq4C+EnEbVa/BH2aZPIl43493eigqNUAieypOSX8CtwF1kivMTdQdLxWuZMz0UF VhVQ== X-Gm-Message-State: AOAM531VPMKi44+zwSSZGJd6RowRuyfKW682DANjFtY9GALrbLcJzpmd gIqUQERv/mazsCAvmLAHxtKY5GpUGNzQg3FJPuyLiw== X-Google-Smtp-Source: ABdhPJz/elCO3lnjyYWc6zhfNJ/NarzgLeTjsWBv5neMld1a0J6AU+nQz62DnEMfkdMCPFmiwHKdGw/gNjWsVe1eXuE= X-Received: by 2002:a05:6602:208f:: with SMTP id a15mr18251986ioa.91.1604518738942; Wed, 04 Nov 2020 11:38:58 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ben Schwartz Date: Wed, 4 Nov 2020 14:38:47 -0500 Message-ID: To: "Chris Box (BT)" Cc: ADD Mailing list Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000008028ed05b34d2137" Archived-At: Subject: Re: [Add] Updated requirements draft X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 19:39:01 -0000 --0000000000008028ed05b34d2137 Content-Type: multipart/alternative; boundary="00000000000078b94505b34d2117" --00000000000078b94505b34d2117 Content-Type: text/plain; charset="UTF-8" ... > Section 3.2 >> > a means is needed for the discovery process to work >> > from a locally-addressed Do53 resolver to an Encrypted DNS resolver >> > that is accessible either at the same (local) address, or at a >> > different global address. Both options need to be supported. >> >> I don't think we need to support all imaginable configurations that >> correspond to our general use case. We only "need" to solve one >> configuration, and we can consider covering others where it is fruitful to >> do so. >> >> It seems like the motivating use case here is in Section 5 (a forward >> reference would be helpful). >> > > Yes I'll add the forward reference. And again, if we cannot have a single > solution that meets all requirements of this case, then yes I can see there > could be separate solutions for: > > - Local address Do53 to same local address DoH > - Local address Do53 to global address DoH > > Is this what you mean? Or are you saying that some particular > configurations should not be solved? > Yes. There's a whole slew of permutations here: Do53 IP is local or global, encrypted DNS IP is same or different, DoH or DoT, network-identified or resolver-identified, etc. I don't think we need to solve all combinations, and some combinations may not have good solutions. --00000000000078b94505b34d2117 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
...
Section 3.= 2
> a means is needed for the discovery process to work=
> from a locally-addressed Do53 resolver to an Encrypted DNS resolve= r
> that is accessible either at the same (local) address, or at a> different global address.=C2=A0 Both options need to be supported.

I don'= t think we need to support all imaginable configurations that correspond to= our general use case.=C2=A0 We only "need" to solve one configur= ation, and we can consider covering others where it is fruitful to do so.
=
= It seems like the motivating use case here is in Section 5 (a forward refer= ence would be helpful).

= Yes I'll add the forward reference. And again, if we cannot have a sing= le solution that meets all requirements of this case, then yes I can see th= ere could be separate solutions for:
  • Local address Do53 t= o same local address DoH
  • Local address Do53 to global address D= oH
Is this what you mean?=C2=A0 Or are you saying that = some particular configurations should not be solved?

Yes.=C2=A0 There's a whole slew of permutat= ions here: Do53 IP is local or global, encrypted DNS IP is same or differen= t, DoH or DoT, network-identified or resolver-identified, etc.=C2=A0 I don&= #39;t think we need to solve all combinations, and some combinations may no= t have good solutions.
--00000000000078b94505b34d2117-- --0000000000008028ed05b34d2137 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPmAYJKoZIhvcNAQcCoIIPiTCCD4UCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggzyMIIEtjCCA56gAwIBAgIQeAMYYHb81ngUVR0WyMTzqzANBgkqhkiG9w0BAQsFADBMMSAwHgYD VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE AxMKR2xvYmFsU2lnbjAeFw0yMDA3MjgwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFQxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFz IFIzIFNNSU1FIENBIDIwMjAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvLe9xPU9W dpiHLAvX7kFnaFZPuJLey7LYaMO8P/xSngB9IN73mVc7YiLov12Fekdtn5kL8PjmDBEvTYmWsuQS 6VBo3vdlqqXZ0M9eMkjcKqijrmDRleudEoPDzTumwQ18VB/3I+vbN039HIaRQ5x+NHGiPHVfk6Rx c6KAbYceyeqqfuJEcq23vhTdium/Bf5hHqYUhuJwnBQ+dAUcFndUKMJrth6lHeoifkbw2bv81zxJ I9cvIy516+oUekqiSFGfzAqByv41OrgLV4fLGCDH3yRh1tj7EtV3l2TngqtrDLUs5R+sWIItPa/4 AJXB1Q3nGNl2tNjVpcSn0uJ7aFPbAgMBAAGjggGKMIIBhjAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHzM CmjXouseLHIb0c1dlW+N+/JjMB8GA1UdIwQYMBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MHsGCCsG AQUFBwEBBG8wbTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3Ry MzA7BggrBgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvcm9vdC1y My5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIz LmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5n bG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEANyYcO+9JZYyqQt41 TMwvFWAw3vLoLOQIfIn48/yea/ekOcParTb0mbhsvVSZ6sGn+txYAZb33wIb1f4wK4xQ7+RUYBfI TuTPL7olF9hDpojC2F6Eu8nuEf1XD9qNI8zFd4kfjg4rb+AME0L81WaCL/WhP2kDCnRU4jm6TryB CHhZqtxkIvXGPGHjwJJazJBnX5NayIce4fGuUEJ7HkuCthVZ3Rws0UyHSAXesT/0tXATND4mNr1X El6adiSQy619ybVERnRi5aDe1PTwE+qNiotEEaeujz1a/+yYaaTY+k+qJcVxi7tbyQ0hi0UB3myM A/z2HmGEwO8hx7hDjKmKbDCCA18wggJHoAMCAQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUA MEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWdu MRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEg MB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzAR BgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4 Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuu l9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJ pij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh 6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti +w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEA S0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9u bG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaM ld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88 q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/f hO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBNEwggO5oAMCAQICEAE/JGAv3XK3SRaKvGds QSwwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gQXRsYXMgUjMgU01JTUUgQ0EgMjAyMDAeFw0yMDA5MDgy MzQzNTNaFw0yMTAzMDcyMzQzNTNaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFzY0Bnb29nbGUuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7rjWsiqQSnXGFTvs/2JDygQFtWsgF+Ce W2I/wmwCuWH2eNUBYslyudWmJsUMi7IbeSsKHrvBI2P7k6sk5p6o3uFlomiFaDMqXcn76t5GNGym CmHm5KBWxc3LfyvR4C2/wg9oUwbL2xxXc6QQpWWE4ONn9NMHwNC396Ih5u7tcrH5eF49HbVarP5i TindWAOzz++JA3VC/1lIkqWvOt2BcBtxQDUnYp8sr8UnMF/6UqtCd0aHJnKkvYi4o8Qo5Qf3YgiJ DzADzBTf54o3NAI3hiIVKPvz1l0g78IcR29Bt9jUrE33qGzGB6HoY7Z8quhA/ngW2XjuLkIY1ZKX AwTXBQIDAQABo4IBzzCCAcswHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5jb20wDgYDVR0PAQH/ BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUu687mSaB85ui VgNNFSUhtTljkxEwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYmaHR0cHM6 Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wCQYDVR0TBAIwADCBmgYIKwYBBQUHAQEE gY0wgYowPgYIKwYBBQUHMAGGMmh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL2NhL2dzYXRsYXNy M3NtaW1lY2EyMDIwMEgGCCsGAQUFBzAChjxodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2Nh Y2VydC9nc2F0bGFzcjNzbWltZWNhMjAyMC5jcnQwHwYDVR0jBBgwFoAUfMwKaNei6x4schvRzV2V b4378mMwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9jYS9nc2F0 bGFzcjNzbWltZWNhMjAyMC5jcmwwDQYJKoZIhvcNAQELBQADggEBAG9R1/y5PatVOc8xLrAmGgNO /Q4+lbJuHNwX3aIpOkM72Ot4r6r5/IFOSx1pMpmzvrECyy5YQzUGkHV4atuNq5YPPNMGa+XlaKSg oU2dA6RCD40dtwmrPxrKiGAfHPNvfmRvgnx9qxBKFPbKF/Tn8BwKSZCSvx33TnQRfqLUTcgrAarQ dF9Oc45moJrn4nVF0VTTPI6LVminvjg3tLgF2bny1N6CitQnb1t67vpYjeNpcXNIGQzEDaYI3WnK rVeZMcLSY+Z2dQH8HvVsA95vFCTywgiWKq5KxFqz/GdB6JhDWcIJIKCJVUyqD/Bjx47+e4Ye/FuD NDSYc+613Ozl3TkxggJqMIICZgIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFzIFIzIFNNSU1FIENBIDIwMjACEAE/ JGAv3XK3SRaKvGdsQSwwDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIA4obFZEuZ2m dw+bMNoYI/4/6EL1nCJ01W/if0BnKkyCMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTIwMTEwNDE5Mzg1OVowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJ YIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcN AQEHMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQC7nQuGGkHVgemoxi8FIFooxDxECpGV tWobHcRL9ctnnnekn5MGOr4IozzS9+FSPuMG/MsbnOuGKSDYwtKZEMm10T1HXHOEpaFwEfFpCSDX ect2WyuLHMbOUkFxeMfP0oxs9KiTRS2YGt+xWWzzox+zRu2GWsB7Zrv4duDhOt0Bez39AWsNxY9J CQDo5EpQ+1WzfP6YFg7AzxRltUdqzwep1eXaPkXC/0hN36B1SdErwVfLJKfs/X0oQqzu70zu5MPA J3uXtVZhAi+gyxVKEiT9eNFOaxL+14dYOoW+5ssGeLb7ci/W3W5+8M0qepG7InEWQREExBiQVuRq CA/bjUHV --0000000000008028ed05b34d2137-- From nobody Wed Nov 4 12:49:41 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C8F3A0E21; Wed, 4 Nov 2020 12:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 huWKr7244FyY; Wed, 4 Nov 2020 12:49:39 -0800 (PST) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 D91113A0DEF; Wed, 4 Nov 2020 12:49:38 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 0A4KmSeq002275; Wed, 4 Nov 2020 12:49:37 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=dv7+PpZ8bA5H59efy0f1bZ5qXZNmMXq9ujgNxtp2E/0=; b=kbbMugq+fJoxntX5CO84KLVCUGVdeKqwC0DObvi09j+Kpdedm718vHWkXD/+1maRGxd3 +5Vrzas5YQLA5B+u92lbQY9rX/Xacss/YNQ+1NHLsfDmEAoDW1+dAc01a3yerNfm6S1q srE7nTThLpD4QQFc205v08O59irOrsOUSM2ZrFVJITj67Vzk/TqzkU+i6MOEt48HDVEB F6cs6/LiHUgSE61i7PEZuj3o/j0QLZpykzWibCcOpOSDGKbXhovSAQbW9RtIj6Xb8sju Trbsy4M7uIS1uqu1KBJpKR9ZHJQuaeN0OoJ0N9jcQbqEntKZ/lAXp/xg6NSHy/zanVo3 1g== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 34h4kuddyy-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 04 Nov 2020 12:49:37 -0800 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QJA00T30HUOACD0@rn-mailsvcp-mta-lapp03.rno.apple.com>; Wed, 04 Nov 2020 12:49:36 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QJA00R00HT54S00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 04 Nov 2020 12:49:36 -0800 (PST) X-Va-A: X-Va-T-CD: e72da815dcb01dab2f988f94f1719970 X-Va-E-CD: 97de42ee73d1653b034b3fece4277d12 X-Va-R-CD: 8eff5a00d73fb7eb55a144beda73e8f7 X-Va-CD: 0 X-Va-ID: 857d7149-4d98-42b6-8314-99a62f15a68e X-V-A: X-V-T-CD: e72da815dcb01dab2f988f94f1719970 X-V-E-CD: 97de42ee73d1653b034b3fece4277d12 X-V-R-CD: 8eff5a00d73fb7eb55a144beda73e8f7 X-V-CD: 0 X-V-ID: 83d03221-4033-4b0a-a118-2cb8486f1bab X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-04_14:2020-11-04, 2020-11-04 signatures=0 Received: from localhost.localdomain (unknown [17.232.173.204]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QJA00K67HUIRN00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 04 Nov 2020 12:49:36 -0800 (PST) From: Tommy Pauly Message-id: <5AD96E9B-B27B-4C0E-BC9C-C2BD832843D6@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_C02A3702-557D-4CE5-A625-C33DD386E4DF" MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\)) Date: Wed, 04 Nov 2020 12:49:28 -0800 In-reply-to: Cc: ADD Mailing list To: Ben Schwartz References: <9DE350EE-F438-435A-8C34-9C15A9744E7A@apple.com> X-Mailer: Apple Mail (2.3654.0.3.2.26) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-04_14:2020-11-04, 2020-11-04 signatures=0 Archived-At: Subject: Re: [Add] Discovery of Equivalent Encrypted Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 20:49:41 -0000 --Apple-Mail=_C02A3702-557D-4CE5-A625-C33DD386E4DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the review, Ben! Responses inline. > On Nov 3, 2020, at 9:35 AM, Ben Schwartz = wrote: >=20 > Thanks for this draft. I support this approach, and I think the clear = distinction between named, IP-authenticated, and opportunistic modes is = very helpful. >=20 > Some notes: >=20 > A. Security design > > "In order to be considered an authenticated Equivalent Encrypted = Resolver, the TLS certificate presented by the Encrypted Resolver MUST = contain both the domain name (from the SVCB answer) and the IP address = of its equivalent Unencrypted Resolver" >=20 > Requiring the certificate to cover the TargetName is unusual. Why = does it help for the certificate to contain this domain name, if it is = also required to authenticate or match the DNS server IP? Is a = nontrivial TargetName always required? >=20 > > "An attacker might try to direct Encrypted DNS traffic to itself by = causing the client to think that a discovered Equivalent Encrypted = Resolver uses a different IP address from the Unencrypted Resolver." >=20 > It seems like you are contemplating an attacker who controls the DNS = path but not the RA/DHCP path. I'd appreciate seeing a few more words = on that beyond the current reference to RA protection. >=20 > In general, some text on threat modeling might help to justify the = design decisions. Partly, I=E2=80=99m imagining we can rely on or take some of the threat = modeling text from the requirements document here. However, I agree that = that should be referenced or included. https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/issues/143 = >=20 > B. Interaction with other options > I would appreciate a sentence on how the opportunistic mode interacts = with "probe port 853 for DoT". Good point! We can add text for that. I think if you have an SVCB record = indicating a DoT (or DoH) server, that supplants needing to probe port = 853, but they are essentially equivalent. https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/issues/144 = >=20 > C. Hints > > "These address hints ... avoid additional DNS lookup for the A and = AAAA records of the Encrypted Resolver name." >=20 > Strictly speaking, a compliant SVCB client is expected to perform the = additional lookups anyway. The hints just avoid a delay while those = queries complete. If you think it's important to "skip" those followup = queries, we would have to make a deeper change. Otherwise, you could = say "avoid *waiting for* DNS lookup...". Yes, I think it would be better to just =E2=80=9Cavoid waiting for=E2=80=9D= here. https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/issues/145 = Best, Tommy >=20 > On Tue, Nov 3, 2020 at 11:34 AM Tommy Pauly = > wrote: > Hello ADD, >=20 > A few of us have written up a simplified description of the mechanism = to use DNS records to discover encrypted DNS servers, focusing on the = clearest cases discussed in the previous interim (bootstrapping from an = unencrypted resolver, etc). >=20 > https://www.ietf.org/archive/id/draft-pauly-add-deer-00.html = >=20 > Your comments and thoughts are welcome and appreciated! >=20 > Best, > Tommy > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add = --Apple-Mail=_C02A3702-557D-4CE5-A625-C33DD386E4DF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for the review, Ben! Responses inline.

On Nov 3, 2020, at 9:35 AM, Ben Schwartz <bemasc=3D40google.com@dmarc.ietf.org> wrote:

Thanks for this draft.  I support this approach, and I = think the clear distinction between named, IP-authenticated, and = opportunistic modes is very helpful.

Some notes:

A. Security design
> "In order to be considered an authenticated Equivalent = Encrypted Resolver, the TLS certificate presented by the Encrypted = Resolver MUST contain both the domain name (from the SVCB answer) and = the IP address of its equivalent Unencrypted Resolver"

Requiring the = certificate to cover the TargetName is unusual.  Why does it help = for the certificate to contain this domain name, if it is also required = to authenticate or match the DNS server IP?  Is a nontrivial = TargetName always required?
> "An attacker might try to direct = Encrypted DNS traffic to itself by causing the client to think that a = discovered Equivalent Encrypted Resolver uses a different IP address = from the Unencrypted Resolver."

It seems like you are contemplating an = attacker who controls the DNS path but not the RA/DHCP path.  I'd = appreciate seeing a few more words on that beyond the current = reference to RA protection.

In general, some text on threat modeling might help to = justify the design decisions.

Partly, I=E2=80=99m imagining we can rely on or = take some of the threat modeling text from the requirements document = here. However, I agree that that should be referenced or = included.

https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/iss= ues/143

B. Interaction with other = options
I would appreciate a sentence on how the = opportunistic mode interacts with "probe port 853 for DoT".

Good point! We can add text for that. I think if = you have an SVCB record indicating a DoT (or DoH) server, that supplants = needing to probe port 853, but they are essentially = equivalent.

https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/iss= ues/144

C. Hints
> = "These address hints ... avoid additional DNS lookup for the A and AAAA = records of the Encrypted Resolver name."

Strictly speaking, a compliant SVCB = client is expected to perform the additional lookups anyway.  The = hints just avoid a delay while those queries complete.  If you = think it's important to "skip" those followup queries, we would have to = make a deeper change.  Otherwise, you could say "avoid *waiting = for* DNS lookup...".

Yes, I think it would be better to just =E2=80=9Cavoid = waiting for=E2=80=9D here.



Best,
Tommy

On Tue, Nov = 3, 2020 at 11:34 AM Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:
Hello ADD,

A few of us have written = up a simplified description of the mechanism to use DNS records to = discover encrypted DNS servers, focusing on the clearest cases discussed = in the previous interim (bootstrapping from an unencrypted resolver, = etc).

https://www.ietf.org/archive/id/draft-pauly-add-deer-00.html

Your comments and = thoughts are welcome and appreciated!

Best,
Tommy
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add

= --Apple-Mail=_C02A3702-557D-4CE5-A625-C33DD386E4DF-- From nobody Wed Nov 4 17:34:44 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671CC3A124E for ; Wed, 4 Nov 2020 17:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=SbHqku4+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CNFcRCpA 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 vVBrGZUQGm94 for ; Wed, 4 Nov 2020 17:34:41 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 188E03A124F for ; Wed, 4 Nov 2020 17:34:40 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 27053E69 for ; Wed, 4 Nov 2020 20:34:40 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Wed, 04 Nov 2020 20:34:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm3; bh=upDQV FDXRjuhUWuJALz5U/QZ8JEd6NwsERgVDTBW/J4=; b=SbHqku4+KZeBGl4JHBWbb FhjDyZ6wDSMI+pOO9rL2d0C+OFhO3lrUbISbU+hJe4cqSraiQhECdLbD7+WNgsLv UQyfmguUbIZC6RzIOzYpDDyxj02oMTdDixIZwRoP2FfhUPJS/r+GidPlWAd6srD0 bUEASwG6Fr+LqvjeUgECKojlR7+OjSCSABlttfHK2+GhbQafFRagzuc8RRTgxNmw ABN3DFrbIl5U/0m0KfbpDwYuFzp+SxBdIFVa4NKlAFd/2Vj39t2lVXiJfauL+GOm D6DTORHMMdqepqwEWid564+zlbg7jv/d+qnuuw0dVoo4o1jYpzxNZibJcX/fyzG/ A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=upDQVFDXRjuhUWuJALz5U/QZ8JEd6NwsERgVDTBW/ J4=; b=CNFcRCpAdlB2ejEECPgUlhOySdo9pQAvThIGc66NvmmpXVuw/iqbiXC5e Gys8Z1eitlllMoxaUscwU6zFQQLb+WJo+L0lt/aDzZxMYvSK2vlc3cDQitttcz0+ jCcTcqehvym+7bkGTYertywFBlck2LY/Hq4hlNnlGZEfJ1AbAHgiunmBIMHMUbMV YjkBMz/gQhDWJmwh3vc7E8JzsrM1+0i0Jj5Au3+de7lNB+brwNnpO3csnCJ7WNM2 IDKffMlNooCCnaIzRPSGPZt3zKMabJ8xGo8q6FjNSmVzl9EcnBRWjfK0EzXgawaU rm/8/VFKu1t32SYRtO1ZyZ/59I8EA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddtiedgfeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepjefhffelheevudefje efvddvhfdvieetudehueffudevudeugeelfeffffelvdefnecuffhomhgrihhnpehgihht hhhusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 75F6D20093; Wed, 4 Nov 2020 20:34:39 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-530-g8da6958-fm-20201021.003-g69105b13-v35 Mime-Version: 1.0 Message-Id: <5e4274de-970f-45a3-8fb4-5893aa6391cb@www.fastmail.com> In-Reply-To: <5AD96E9B-B27B-4C0E-BC9C-C2BD832843D6@apple.com> References: <9DE350EE-F438-435A-8C34-9C15A9744E7A@apple.com> <5AD96E9B-B27B-4C0E-BC9C-C2BD832843D6@apple.com> Date: Thu, 05 Nov 2020 12:34:20 +1100 From: "Martin Thomson" To: add@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Add] Discovery of Equivalent Encrypted Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 01:34:42 -0000 On Thu, Nov 5, 2020, at 07:49, Tommy Pauly wrote: > > It seems like you are contemplating an attacker who controls the DNS= path but not the RA/DHCP path. I'd appreciate seeing a few more words = on that beyond the current reference to RA protection. > > Partly, I=E2=80=99m imagining we can rely on or take some of the threa= t=20 > modeling text from the requirements document here. However, I agree=20= > that that should be referenced or included. >=20 > https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/issues/143= (Also posted on the issue.) I think that for equivalence, it is sufficient to include just the ipAdd= ress SAN. Clients have to have a single target identity to match, or it = gets a little tricky. This assumes that the provenance of the IP is somehow not subject to att= ack. This includes DHCP/RA, manual configuration, and other forms of con= figuration like enterprise policy systems. But it's not really that. This isn't about establishing whether the IP a= ddress is the right one, it's about saying affirmatively that this is th= e same as this other thing. For that, you don't need to worry about wher= e the IP address came from. Of course, this is a stronger assertion rega= rding the DoT/DoH server than you can make about the Do53 server. The fo= rmer is authenticated; the latter relies on the integrity of the route. From nobody Thu Nov 5 06:18:15 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091903A11CB for ; Thu, 5 Nov 2020 06:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLmdBbhL9wdb for ; Thu, 5 Nov 2020 06:18:12 -0800 (PST) Received: from ayla.bortzmeyer.org (ayla.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fe27:3d3f]) (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 E36723A11FC for ; Thu, 5 Nov 2020 06:18:11 -0800 (PST) Received: by ayla.bortzmeyer.org (Postfix, from userid 10) id D30DFA02A5; Thu, 5 Nov 2020 15:18:08 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id 9CBDA190032; Thu, 5 Nov 2020 14:59:28 +0100 (CET) Date: Thu, 5 Nov 2020 14:59:28 +0100 From: Stephane Bortzmeyer To: Tommy Pauly Cc: ADD Mailing list Message-ID: <20201105135928.GA31848@sources.org> References: <9DE350EE-F438-435A-8C34-9C15A9744E7A@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9DE350EE-F438-435A-8C34-9C15A9744E7A@apple.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 10.6 X-Charlie: Je suis Charlie User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Add] Discovery of Equivalent Encrypted Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 14:18:14 -0000 On Tue, Nov 03, 2020 at 08:34:14AM -0800, Tommy Pauly wrote a message of 47 lines which said: > A few of us have written up a simplified description of the > mechanism to use DNS records to discover encrypted DNS servers, > focusing on the clearest cases discussed in the previous interim > (bootstrapping from an unencrypted resolver, etc). > > https://www.ietf.org/archive/id/draft-pauly-add-deer-00.html I like the name and specially the fact that this name says clearly that the encrypted resolver is not "better" (more trustable) than the unencrypted one. This is reasonable. > The client MUST check the SubjectAlternativeName field for both the > Unencrypted Resolver's IP address How do you think we can address the case of unencrypted resolvers on RFC 1918 addresses? Should this practice be discouraged? > Resolver owners that support authenticated discovery will need to > list valid referring IP addresses in their TLS certificates. This > may pose challenges for resolvers with a large number of referring > IP addresses. And also with the many CA that do not accept to put IP addresses in certificates (the most important one being Let's Encrypt). From nobody Thu Nov 5 08:12:38 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20BF3A17E0; Thu, 5 Nov 2020 08:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 aYl_8cFs1Gr0; Thu, 5 Nov 2020 08:12:35 -0800 (PST) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 7BBFC3A144A; Thu, 5 Nov 2020 08:12:35 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 0A5FqdnL021461; Thu, 5 Nov 2020 08:12:34 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=8BhNb+Ov4azwk7OurVn9HHl00tXBIfQ6kLy9Jxulfxk=; b=rQiNsC5NE+jzfJY6+8ORnhvUT13jyDvA1LiBF/WAlB3kfOIaAR16kfHPnZBdLr69tSWo MBLXYcwaTWgruhKnPC8IFebE7QUfnSU8u8+4ichoGTYGgP29YiVw1A1fLIClHKT+M4M3 7uFHy4Z99TlGqQnEKfiOCgs+m3zyhMyy8Vvkkdm8sxLU2tv4C1lX7M9da7jEGupYxErN lpidxUK7Ubs6r21jrqJzGsYBiQw1AmTIsy+Yi0lnfOTh8yY0JcBKgLTJpM/Uk3YJvSQ/ BBD5B68iB51EVYPhIxC6gWPVP0Xjp2V7k+PnKMcrOTWhpVqAjaL7SH5ma7OHcmDxkc3s Ug== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 34h4kv04ke-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 05 Nov 2020 08:12:34 -0800 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QJB00OO6ZOXJY40@rn-mailsvcp-mta-lapp02.rno.apple.com>; Thu, 05 Nov 2020 08:12:33 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QJB00E00ZMUEN00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Thu, 05 Nov 2020 08:12:33 -0800 (PST) X-Va-A: X-Va-T-CD: 8257fa42410ffc74ae8b7ca4241707a0 X-Va-E-CD: 97de42ee73d1653b034b3fece4277d12 X-Va-R-CD: 8eff5a00d73fb7eb55a144beda73e8f7 X-Va-CD: 0 X-Va-ID: 1c52c3a1-2ebf-4edf-b28b-c8da082cc657 X-V-A: X-V-T-CD: 8257fa42410ffc74ae8b7ca4241707a0 X-V-E-CD: 97de42ee73d1653b034b3fece4277d12 X-V-R-CD: 8eff5a00d73fb7eb55a144beda73e8f7 X-V-CD: 0 X-V-ID: 13b26c43-ae45-425e-ab33-14fa10f90650 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-05_09:2020-11-05, 2020-11-05 signatures=0 Received: from localhost.localdomain (unknown [17.232.173.204]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QJB00SOWZORFP00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Thu, 05 Nov 2020 08:12:33 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\)) From: Tommy Pauly In-reply-to: <20201105135928.GA31848@sources.org> Date: Thu, 05 Nov 2020 08:12:24 -0800 Cc: Tommy Pauly , ADD Mailing list Content-transfer-encoding: quoted-printable Message-id: <9E81934A-447E-4A08-9B6E-4FADAD98F7AF@apple.com> References: <9DE350EE-F438-435A-8C34-9C15A9744E7A@apple.com> <20201105135928.GA31848@sources.org> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.3654.0.3.2.26) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-05_10:2020-11-05, 2020-11-05 signatures=0 Archived-At: Subject: Re: [Add] Discovery of Equivalent Encrypted Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 16:12:37 -0000 > On Nov 5, 2020, at 5:59 AM, Stephane Bortzmeyer = wrote: >=20 > On Tue, Nov 03, 2020 at 08:34:14AM -0800, > Tommy Pauly wrote=20 > a message of 47 lines which said: >=20 >> A few of us have written up a simplified description of the >> mechanism to use DNS records to discover encrypted DNS servers, >> focusing on the clearest cases discussed in the previous interim >> (bootstrapping from an unencrypted resolver, etc). >>=20 >> https://www.ietf.org/archive/id/draft-pauly-add-deer-00.html = >=20 > I like the name and specially the fact that this name says clearly = that the > encrypted resolver is not "better" (more trustable) than the > unencrypted one. This is reasonable. >=20 >> The client MUST check the SubjectAlternativeName field for both the >> Unencrypted Resolver's IP address >=20 > How do you think we can address the case of unencrypted resolvers on > RFC 1918 addresses? Should this practice be discouraged? If your unencrypted resolver is on a private address, you essentially = have two options: 1. Host your equivalent encrypted resolver on the same IP address, which = puts us in the =E2=80=9Copportunistic=E2=80=9D bucket defined in the = draft. This isn=E2=80=99t strongly authenticated, but it works and still = lets you discover the right path for DoH, etc. 2. Provision the name of the encrypted resolver via DHCP/RA, which means = we don=E2=80=99t need to worry about IP addresses matching. The case for having IP addresses be in certs is for cases where the IP = address is public and can be in a cert=E2=80=94i.e., I could send the = resolver.arpa query to 1.1.1.1 and learn about it=E2=80=99s DoT and DoH = capabilities. >=20 >> Resolver owners that support authenticated discovery will need to >> list valid referring IP addresses in their TLS certificates. This >> may pose challenges for resolvers with a large number of referring >> IP addresses. >=20 > And also with the many CA that do not accept to put IP addresses in > certificates (the most important one being Let's Encrypt). Indeed. However, this is possible and already done for some resolvers = with public IP addresses, so it is still a useful mechanism for those = cases. Best, Tommy >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add From nobody Thu Nov 5 17:25:52 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0161C3A0A71; Thu, 5 Nov 2020 17:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 zzRdbZGMHd82; Thu, 5 Nov 2020 17:25:47 -0800 (PST) Received: from ppsw-31.csi.cam.ac.uk (ppsw-31.csi.cam.ac.uk [131.111.8.131]) (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 3F2713A0A6E; Thu, 5 Nov 2020 17:25:46 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:51628) by ppsw-31.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1kaqVc-00115m-LN (Exim 4.92.3) (return-path ); Fri, 06 Nov 2020 01:25:44 +0000 Date: Fri, 6 Nov 2020 01:25:44 +0000 From: Tony Finch To: Tommy Pauly cc: ADD Mailing list In-Reply-To: <9DE350EE-F438-435A-8C34-9C15A9744E7A@apple.com> Message-ID: References: <9DE350EE-F438-435A-8C34-9C15A9744E7A@apple.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Add] Discovery of Equivalent Encrypted Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 01:25:50 -0000 Tommy Pauly wrote: > > https://www.ietf.org/archive/id/draft-pauly-add-deer-00.html Re. section 4, queries for _dns.resolver.arpa: A neat way to support this would be if the resolver could reply with _dns.resolver.arpa. CNAME _dns.resolvers-own-hostname At least some resolvers know their own hostnames, so they could have a built-in default resolver.arpa zone, allowing the resolver admin to provision the SVCB records under the real resolver hostname(s) without also having to explicitly set up the special-use name. So section 8.1 is correct to say that resolver.arpa needs to be the special zone name, so that _dns.resolver.arpa can be a CNAME. [ related but off-topic, I'm eagerly looking for RFC 8738 support at atttps://letsencrypt.org/upcoming-features/ ] Tony. -- f.anthony.n.finch http://dotat.at/ The Minch: South or southwest 5 to 7, decreasing 3 to 5. Slight or moderate, but rough near northern and southern entrances. Occasional drizzle. Moderate or good, occasionally poor. From nobody Fri Nov 6 01:28:23 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA5C3A0FC6 for ; Fri, 6 Nov 2020 01:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ci9SQZpfvjBU for ; Fri, 6 Nov 2020 01:28:20 -0800 (PST) Received: from ayla.bortzmeyer.org (ayla.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fe27:3d3f]) (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 0F74C3A1006 for ; Fri, 6 Nov 2020 01:28:09 -0800 (PST) Received: by ayla.bortzmeyer.org (Postfix, from userid 10) id 68962A02A5; Fri, 6 Nov 2020 10:28:06 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id C91EA190032; Fri, 6 Nov 2020 10:23:55 +0100 (CET) Date: Fri, 6 Nov 2020 10:23:55 +0100 From: Stephane Bortzmeyer To: "Chris Box (BT)" Cc: ADD Mailing list Message-ID: <20201106092355.GA9142@sources.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 10.6 X-Charlie: Je suis Charlie User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Add] Updated requirements draft X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 09:28:22 -0000 On Tue, Nov 03, 2020 at 07:04:47PM +0000, Chris Box (BT) wrote a message of 79 lines which said: > One of those is a first revision to > draft-box-add-requirements. Following the feedback from the first > interim, this is now tightly focussed on the "single use case", that > of discovering the encrypted resolvers that are claimed to be > equivalent to a resolver (e.g. Do53) that the client already knows > about. This narrower focus This is more reasonable, indeed. But it lets open an important question: what's left? If the encrypted resolver is equivalent to the unencrypted (for instance if they both lie in the same way, e. g. they both censor SciHub), encryption provides only a small benefit. Sure, it is always better to encrypt but, since the default unencrypted resolver is probably close to the user, in the same AS, the benefit is not so important. Speaking of this, the draft says: > Using an encrypted and authenticated resolver that is equivalent to > the one provisioned by the network can provide several benefits The first benefit, "Prevent other devices on the network from observing client DNS messages", is OK but the two others are questionable: * "Authenticate that the DNS resolver is the correct one" If you got it from DHCP or RA, which are not very safe, authenticating is not so important. If an attacker can hijack the DNS traffic to a rogue encrypted resolver, he or she can also probably spoof DHCP or RA. * "Verify that answers come from the selected DNS resolver" Same remark. Also, the introduction: > While it is possible for clients to statically configure encrypted > DNS resolvers to use, dynamic discovery and provisioning of > encrypted resolvers can expand the usefulness and applicability of > encrypted DNS to many more use cases. Does not convince me. The good thing about DoT and DoH is that you can safely use a resolver that you choosed. It means it was configured statically. An encrypted resolver discovered by automatic means, from hints of the access network, is only marginally better than an unencrypted one. From nobody Fri Nov 6 04:49:17 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B104D3A113D for ; Fri, 6 Nov 2020 04:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 QE-K31P5ufnt for ; Fri, 6 Nov 2020 04:49:14 -0800 (PST) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 0091B3A1143 for ; Fri, 6 Nov 2020 04:49:13 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:59792) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1kb1B1-000Qq1-eS (Exim 4.92.3) (return-path ); Fri, 06 Nov 2020 12:49:11 +0000 Date: Fri, 6 Nov 2020 12:49:11 +0000 From: Tony Finch To: Stephane Bortzmeyer cc: "Chris Box (BT)" , ADD Mailing list In-Reply-To: <20201106092355.GA9142@sources.org> Message-ID: References: <20201106092355.GA9142@sources.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Add] Updated requirements draft X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 12:49:16 -0000 Stephane Bortzmeyer wrote: > > The first benefit, "Prevent other devices on the network from > observing client DNS messages", is OK but the two others are > questionable: > > * "Authenticate that the DNS resolver is the correct one" If you got > it from DHCP or RA, which are not very safe, authenticating is not so > important. If an attacker can hijack the DNS traffic to a rogue > encrypted resolver, he or she can also probably spoof DHCP or RA. There are layer 2 mechanisms to make that very difficult. > * "Verify that answers come from the selected DNS resolver" Same > remark. If you have layer 2 DHCP/RA security then it's reasonable for the network to tell you how to authenticate the resolver as well as its address. The resolver is often going to be some number of links away, so authenticating it has the effect of stretching your layer 2 DHCP/RA security to reach the more distant DNS service. > Does not convince me. The good thing about DoT and DoH is that you can > safely use a resolver that you choosed. It means it was configured > statically. An encrypted resolver discovered by automatic means, from > hints of the access network, is only marginally better than an > unencrypted one. True, but almost nobody is going to use it unless it is configured automatically. Tony. -- f.anthony.n.finch http://dotat.at/ Hebrides, South Bailey: Southwesterly 4 to 6, becoming variable 2 to 4. Rough or very rough. Occasional rain or drizzle. Moderate or good, occasionally poor. From nobody Fri Nov 6 05:28:34 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948483A117C for ; Fri, 6 Nov 2020 05:28:32 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 WJphE95a6egY for ; Fri, 6 Nov 2020 05:28:30 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 C485E3A117F for ; Fri, 6 Nov 2020 05:28:29 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 1C98A280B1B; Fri, 6 Nov 2020 14:28:28 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 1625A2816E6; Fri, 6 Nov 2020 14:28:28 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 105AF280B1B; Fri, 6 Nov 2020 14:28:28 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 0A687602CD34; Fri, 6 Nov 2020 14:28:28 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id EBBC23FE4B; Fri, 6 Nov 2020 14:28:02 +0100 (CET) Date: Fri, 6 Nov 2020 14:28:02 +0100 From: Stephane Bortzmeyer To: Tony Finch Cc: Stephane Bortzmeyer , "Chris Box (BT)" , ADD Mailing list Message-ID: <20201106132802.GB32068@nic.fr> References: <20201106092355.GA9142@sources.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 10.6 X-Kernel: Linux 4.19.0-12-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.4.9.2830568, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.11.6.131816, AntiVirus-Engine: 5.77.0, AntiVirus-Data: 2020.11.6.5770001 Archived-At: Subject: Re: [Add] Updated requirements draft X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 13:28:33 -0000 On Fri, Nov 06, 2020 at 12:49:11PM +0000, Tony Finch wrote a message of 37 lines which said: > > Does not convince me. The good thing about DoT and DoH is that you > > can safely use a resolver that you choosed. It means it was > > configured statically. > True, but almost nobody is going to use it unless it is configured > automatically. "statically" does not mean by the end user. It can be by the OS, for instance (systemd forwards to 8.8.8.8 by default...) From nobody Fri Nov 6 08:26:37 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80FCE3A07EA for ; Fri, 6 Nov 2020 08:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 aTlBPktFdQ6S for ; Fri, 6 Nov 2020 08:26:34 -0800 (PST) Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (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 4A01C3A0808 for ; Fri, 6 Nov 2020 08:26:34 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.43/8.16.0.42) with SMTP id 0A6GPvZZ013721; Fri, 6 Nov 2020 08:26:31 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=V8kO0nfmFevwVF3wZXmsudB3Xn8tH1hZiATfBSxnBTU=; b=L0hZ9kDO4vI8mBbWWn0YpWNtepwFdyhTxH2XKOrMzfNy8MtpI/xbNtXIth51Gsy4zoep x7p21VEgVI1jUVG0li7CwAQvoaXahtXr83uetD7SOGGzVLgXWzj9/WRKlIup7AGsoab9 B8KEB8pZ9Lh9vIgusGAL+8VjDgHzz+mlcXLhfx6eK7FObpTLU45p/KaWk30yN/r4lYk0 O8U9YPZYTIkv0bEHNbO2ojwVvAArUtsfNlI/WKuu7j2bJUFJgNa7zjmYl4u6UslFU9Su Ce1a5V7/PTSF+nGTTvTbzGLB3DQlSmbx6flSm0Vjc8rrZ+u7JrnkS9+bzE1DQA4pY6ra +g== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by nwk-aaemail-lapp01.apple.com with ESMTP id 34h6v1veh7-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 06 Nov 2020 08:26:31 -0800 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QJD00WE5V062LC0@rn-mailsvcp-mta-lapp02.rno.apple.com>; Fri, 06 Nov 2020 08:26:30 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QJD00W00TS7F200@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Fri, 06 Nov 2020 08:26:30 -0800 (PST) X-Va-A: X-Va-T-CD: 93fe2c52fc0f0faa2d20f66255cb22f7 X-Va-E-CD: 97de42ee73d1653b034b3fece4277d12 X-Va-R-CD: 8eff5a00d73fb7eb55a144beda73e8f7 X-Va-CD: 0 X-Va-ID: a317ada4-351f-4f1d-8782-a21e057c57a7 X-V-A: X-V-T-CD: 93fe2c52fc0f0faa2d20f66255cb22f7 X-V-E-CD: 97de42ee73d1653b034b3fece4277d12 X-V-R-CD: 8eff5a00d73fb7eb55a144beda73e8f7 X-V-CD: 0 X-V-ID: 32a3136a-1787-4c1b-bf86-6ca247a612fb X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-06_06:2020-11-05, 2020-11-06 signatures=0 Received: from localhost.localdomain (unknown [17.232.181.227]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QJD000EXV00IH00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Fri, 06 Nov 2020 08:26:30 -0800 (PST) Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\)) From: Tommy Pauly In-reply-to: Date: Fri, 06 Nov 2020 08:26:22 -0800 Cc: Tommy Pauly , ADD Mailing list Content-transfer-encoding: quoted-printable Message-id: <9DD41AB3-A079-4EEC-8084-7AB4D3E321FD@apple.com> References: <9DE350EE-F438-435A-8C34-9C15A9744E7A@apple.com> To: Tony Finch X-Mailer: Apple Mail (2.3654.0.3.2.26) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-06_06:2020-11-05, 2020-11-06 signatures=0 Archived-At: Subject: Re: [Add] Discovery of Equivalent Encrypted Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 16:26:36 -0000 Yes, a CNAME could be used. Note that SVCB also allows the name to be = provided in the answer. So, the answer could be: _dns.resolver.arpa 7200 IN SVCB 1 resolver-hostname.net ( alpn=3Ddot ipv4hint=3Dx.y.z.w ) Thanks, Tommy > On Nov 5, 2020, at 5:25 PM, Tony Finch wrote: >=20 > Tommy Pauly wrote: >>=20 >> https://www.ietf.org/archive/id/draft-pauly-add-deer-00.html >=20 > Re. section 4, queries for _dns.resolver.arpa: >=20 > A neat way to support this would be if the resolver could reply with >=20 > _dns.resolver.arpa. CNAME _dns.resolvers-own-hostname >=20 > At least some resolvers know their own hostnames, so they could have a > built-in default resolver.arpa zone, allowing the resolver admin to > provision the SVCB records under the real resolver hostname(s) without > also having to explicitly set up the special-use name. >=20 > So section 8.1 is correct to say that resolver.arpa needs to be the > special zone name, so that _dns.resolver.arpa can be a CNAME. >=20 > [ related but off-topic, I'm eagerly looking for RFC 8738 support at > atttps://letsencrypt.org/upcoming-features/ ] >=20 > Tony. > --=20 > f.anthony.n.finch http://dotat.at/ > The Minch: South or southwest 5 to 7, decreasing 3 to 5. Slight or = moderate, > but rough near northern and southern entrances. Occasional drizzle. = Moderate > or good, occasionally poor. >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add From nobody Sat Nov 7 23:41:06 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA6C3A10A4 for ; Sat, 7 Nov 2020 23:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=HtPYXY+4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FGIkpGBU 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 rkmnt6Jj9eCe for ; Sat, 7 Nov 2020 23:40:58 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFEDD3A109F for ; Sat, 7 Nov 2020 23:40:58 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 953E651E for ; Sun, 8 Nov 2020 02:32:58 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 08 Nov 2020 02:32:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=SiXr5B1nhS/RiVyXJwUBO4I2LcUmumc1lOSnF5ur2ik=; b=HtPYXY+4 qpCWyRMwKTlC+Ov+OxNPDZY+WZfuQlSlj6ozKmvGWuS8b/sQFDm0gopxwNS1WAJQ LdVz97BXqCpGUYIderaHqs8nmPjG1Ke9cry54XpzMTAWc33hp1dx6mAhe81S0rnW 46z+qsLpINICr6LtiHDcnp4ttOCph7XVCpUl2UIHyNPAqFLW9Z2xSdAEuNmGWxkV dVWcW6jJ6iQ7aMKgkkxfBnjMzcNRlc9/ycx+EdlPyAxSuSGYjrT1yh6FUpmZ+ViV oe1mWEb/TuRiH8c1sxOLfCBnFSUlikeeKFoZDRJCevul4a/jfcJw4KlU/dbcm/2f 1aT6k1IcR6wM2A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=SiXr5B1nhS/RiVyXJwUBO4I2LcUmu mc1lOSnF5ur2ik=; b=FGIkpGBUdXFwx+Pss6CODJ7LEozH9B5a09i9IBTtSU0Dt SJOup2tL7jFTfTXQpd1RStrVIjRanTj0FwBuU8Uk5gZTVXTGJ+4mnFukBWAC6zj6 /bYI7NSlltAzhkY4RuccrhtzWb3f6HoSsP6JxxinO8Sef6NuUiDPG+rxCs4unXxg mGN50HNEJrViFYCxJ0fHgd0l7KBTLx+03r+6/KySlCiiwEGeC58qNTm6PB7pdTiE 26oQR9gaRfqciYQ18q4fUOycA0865wxDNsG7iQe2sI4IsVPaeTWEJcehrEnjO163 mSec3udSy7JKbPNzP3mCo5BVaN8iNnZe1Dxocss0w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudduvddguddtiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeehvddrudefkedrkedurd egjeenucevlhhushhtvghrufhiiigvpeeinecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az59-950.internal.cloudapp.net (unknown [52.138.81.47]) by mail.messagingengine.com (Postfix) with ESMTPA id 1988E3280059 for ; Sun, 8 Nov 2020 02:32:58 -0500 (EST) Content-Type: multipart/alternative; boundary="===============8944069895800311712==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: add@ietf.org Message-Id: <20201108073258.1988E3280059@mailuser.nyi.internal> Date: Sun, 8 Nov 2020 02:32:58 -0500 (EST) Archived-At: Subject: [Add] Weekly github digest (ADD Activity Summary) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2020 07:41:00 -0000 --===============8944069895800311712== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * ietf-wg-add/draft-add-requirements (+0/-7/=F0=9F=92=AC8) 8 issues received 8 new comments: - #17 Limit this to equivalent resolvers (1 by chris-box) https://github.com/ietf-wg-add/draft-add-requirements/issues/17 [design= ]=20 - #16 Associated discovery security differences (1 by chris-box) https://github.com/ietf-wg-add/draft-add-requirements/issues/16 [design= ] [help wanted]=20 - #12 Enhance BYOD description (1 by chris-box) https://github.com/ietf-wg-add/draft-add-requirements/issues/12 [enhanc= ement]=20 - #11 Import use case description from draft-btw-add-ipsecme-ike-00 (1 by= chris-box) https://github.com/ietf-wg-add/draft-add-requirements/issues/11 [enhanc= ement]=20 - #9 Feasibility of requiring the protocol to prove that the encrypted an= d unencrypted resolvers are operated by the same entity (1 by chris-box) https://github.com/ietf-wg-add/draft-add-requirements/issues/9 [design]= =20 - #6 Requirements needed in Privacy and Security (section 5) (1 by chris-= box) https://github.com/ietf-wg-add/draft-add-requirements/issues/6 [design]= =20 - #5 Requirements needed in Discovery of Limited Domain Resolvers (sectio= n 4) (1 by chris-box) https://github.com/ietf-wg-add/draft-add-requirements/issues/5 [design]= =20 - #4 Requirements needed in Discovery of Associated Resolvers (section 3)= (1 by chris-box) https://github.com/ietf-wg-add/draft-add-requirements/issues/4 [design]= =20 7 issues closed: - Limit this to equivalent resolvers https://github.com/ietf-wg-add/draft= -add-requirements/issues/17 [design]=20 - Enhance BYOD description https://github.com/ietf-wg-add/draft-add-requi= rements/issues/12 [enhancement]=20 - Import use case description from draft-btw-add-ipsecme-ike-00 https://g= ithub.com/ietf-wg-add/draft-add-requirements/issues/11 [enhancement]=20 - Feasibility of requiring the protocol to prove that the encrypted and u= nencrypted resolvers are operated by the same entity https://github.com/iet= f-wg-add/draft-add-requirements/issues/9 [design]=20 - Requirements needed in Privacy and Security (section 5) https://github.= com/ietf-wg-add/draft-add-requirements/issues/6 [design]=20 - Requirements needed in Discovery of Limited Domain Resolvers (section 4= ) https://github.com/ietf-wg-add/draft-add-requirements/issues/5 [design]=20 - Requirements needed in Discovery of Associated Resolvers (section 3) ht= tps://github.com/ietf-wg-add/draft-add-requirements/issues/4 [design]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-add/draft-add-requirements * https://github.com/ietf-wg-add/wg-materials --===============8944069895800311712== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (ADD Activity Summary)

Sunday November 08, 2020

Events without label "editorial"

Issues

ietf-wg-add/draft-add-requirements (+0/-7/=F0=9F=92=AC8)

8 issues received 8 new comments:

7 issues closed:

Repositories tracked by this digest:

--===============8944069895800311712==-- From nobody Wed Nov 11 08:07:06 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DE03A0E19 for ; Wed, 11 Nov 2020 08:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 0j4IhsOp0W0h for ; Wed, 11 Nov 2020 08:07:03 -0800 (PST) Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.77]) (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 6329F3A0C8E for ; Wed, 11 Nov 2020 08:06:55 -0800 (PST) Received: from pps.filterd (m0156895.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0ABFwd3u031160 for ; Wed, 11 Nov 2020 11:06:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=6zLMfeC34v3+1FHBTgxwAZL9fgSYAt1o7LzHee18IFI=; b=HvN5988F0mukaOgq626DyUOuqHwsQwStL5C77myrOljRvb7bKQ8jwIbYW0SNWRfkRR8P ON2qWp1gOB6agWgEp5mWeXR65an6flFOhYZfVLZohItgLNN3RrEbbYViCgkcIXrTDJ34 nUaqaWAkCPYaF+9jDat2fw96EqnY7Hp4rcIas4ryGh+ZseAeVVVR+g6t2oafyM1WnNJH ao3RMpBN8M/YXUNrqwxa1AboCjlOTOaaNmpKNL0Zqcp9ofcquAkmiWT6nl+a0TVtgOkb bQjVL52NZBCpTW8xosHX19uWQdqaG2QmFfaU9ZgM8IGMQzIZOmzWeZdT5w+3g291jUFS 6g== Received: from pacdcex56.cable.comcast.com (dlppfpt-wc-1p.slb.comcast.com [96.99.226.136]) by mx0b-00143702.pphosted.com with ESMTP id 34p55wnjcd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 11 Nov 2020 11:06:54 -0500 Received: from PACDCEX43.cable.comcast.com (24.40.2.142) by PACDCEX56.cable.comcast.com (24.40.2.155) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 11 Nov 2020 11:06:51 -0500 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX43.cable.comcast.com (24.40.2.142) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 11 Nov 2020 11:06:51 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.172) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 11 Nov 2020 11:06:43 -0500 Received: from BYAPR11MB3111.namprd11.prod.outlook.com (2603:10b6:a03:90::25) by SJ0PR11MB5071.namprd11.prod.outlook.com (2603:10b6:a03:2d7::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Wed, 11 Nov 2020 16:06:40 +0000 Received: from BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::190a:85b7:803:2fc7]) by BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::190a:85b7:803:2fc7%6]) with mapi id 15.20.3541.025; Wed, 11 Nov 2020 16:06:40 +0000 From: "Deen, Glenn" To: ADD Mailing list Thread-Topic: Requesting NomCom feedback Thread-Index: AQHWuESkIU7CSa5S9E+Kz9043uJtJw== Date: Wed, 11 Nov 2020 16:06:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2605:e000:141b:121:4dd9:b913:5dfe:1c91] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2e1a3933-fc77-4ce9-cfd0-08d8865bc6d7 x-ms-traffictypediagnostic: SJ0PR11MB5071: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QyyV0Jx/q4XWiG602IAimf8hFB+IM3DrjPt030YyKX5QgY6zHUxUKDiIwDy0YgGrzPHJkiE02ixL4mdL+edcAgqV12qSVc2Iol/++ftO7Vh673+yLDN2T4nYn3FsqBQnjFbxLjt5nFQTOr5KbMi0dxFRrkbynrGMfMeCkWTbD0m4pokpnu4y+uK7zeDu4MvO+E9jOau7ScVkHVOsaYLNFrBy9xpxVpk2cOCGUAHXCXAWYF+PbUj5Og+XA05dq7IE1ppwUNiuY6sEZIu0VK+9RDRRQckPmPR3pVYWh+/dftZbK+N7cpSzkEB2LZwWTvsTfkn2+o/PnR8WUTdNkt5XcuYG6Lb5uQa668AFcTuXcDwDu3RVXIMYU3J/sRjkIsydVQLlXXjsItPpRGfIGygnmA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3111.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(396003)(136003)(366004)(376002)(346002)(71200400001)(6916009)(64756008)(66556008)(6512007)(66446008)(36756003)(8676002)(186003)(66946007)(5660300002)(76116006)(66476007)(8936002)(83380400001)(6486002)(9686003)(86362001)(2906002)(316002)(6506007)(966005)(33656002)(478600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: dOvWGZ6wAyRRlXrLu79Yj/5tu5jp5lVC7y06HadgeE/HcpByhWRAhwG7BczkzPucq62e1fMXaFq/PDTh4LcE0+BluGVCck7CUMWNarWEjl0KtWUpVeTfMi2S7NFF8PY8pN35k/N1m9C//MN/9ft2K6SlQIgIR3OO4Y7XsGpQVZ6UodaSynFAuaTz0Ta5WZtDRkDLCFvXjxDB16phuH6ROH3qvWg+cI3lngimzC94IIxQ7Imd9u9PvDeKQzrbSSECQ/jaUGZpnR8dpNfn1ZphRiAJnRos4DWN6snit5oJ1DUUdoKR+r3WAP5lUdlT+nKvm31dDmYGT6FQoyZmmfiWTQfNJsNVStY7YH4SNUCXhjhe/OiDWsUmB9MPehJ9b6xhLDLX7zcn75TOhsArQgdWS+pLaoMvxd9NSN6jaRR/6H4hBy2b97LmK6QLMnKfoo2CVG/EcroQkrc3A6A7px3qAxmTg843jwI/kjcfMP1ZT0oqbJBTsxBU1cuElSsg2G9V1rZDoq9pQ9AyhP/QvdqUx4/NqlGz5OrtEZn/J5IGUWuHwQE4WtgdxN2m/QIDx2cQcSUNq1Km1RUiSpOaJiqubeyvGdPVK60t6y8cXS1S9FBorxJ/Im69irp3hj+WP7Mz0IGZbunkQ5UZLFFt/EjOXk0JZuNSuGCt1Bw4OhyGZOKk7XbF66xN2DZee1SqlW+xAHfXRt5eSb7rtjSDwzZ54E3Xrdu8UTxLca3iWTg3aGbQ/Qjzh3SYVyqLSngqVf0HpA8p4Ix1famBRV6EK7pVfzlapvI0KO1lwOQ0dLlqcab6+uqyRcD7SM0QB7STpVNosS/y0lUNaV0NcuOSpQXo2SSwB62h8fwm2SyLJTuZyfipOyvpdfcIaUCpiJlN2I15StwNJv+qr0qNexFTYBexV8qYefQUYoYA4hMtrCoI6tRRobOxw+LMUbqxH2UTCh4IL7GE9mEoG94H/XFrTbGEhA== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fuDIx6B2XoW7D70AHJVLvWK6eyIZ1DlSyImewfzfn38HnfSCx2r8nrQ7hiZ6ct3ZZzfhU/i3UjeWLLuNrVP7LH46IZRBJEoYeZ5TvP85qiwI7a4fDq4TVPf+y2TRXa8bOgq7nxxqECLRhFZJS3e36hHcVUkBZQfJYCk/Zg/BWuddtG54+weFKm9oUHsXqCvmd/y05k+Hr8hjgmqfm0nkYJgHiujMwNJxFm5HVm4tcqq8nPHvIRuBLPtTiNMaOQLtMvly772Dv4HWWOWWRr3GMGaDMI7+0/3FcWVNFEdsJsSySPjlGUiBqTZag0r7w3WExaq1/ceHnbDhlShgd6tz4w== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8VpprkFy943K1uG4fGasWWK2bWMYIoc8WJZsEUr10QA=; b=A4406SFxLF3zCoYWFJILr98MPJqjYVCtlUCVikt3KqPxgkk85Ikj+oMKwliuMeiwGJkyGmI99plNY6ZjO7CeS3nQBTywAl8JQ5tLOooAraRz/Pzz/u1ZK2KnFwwF/IRugdTKNVl14It5iRnVOnWCJIK42KrmKJFlhVowxa3bguC0Jll6J/gk/EoqsIO09zZFsK2iBmLYDmnGx90yTrFBsK6/wIbgDb8J2Tb/0MX/nDxlYnepfH8h7Am8nSMDJ5deSrK47+PvLadLMx/0+7fbEGk0GNAy1Ya84HHs+fkUptyQkmMxSpZha++D3jHs1rwsaIjVBMcgzyj1gyl/ghZJ1g== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: BYAPR11MB3111.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 2e1a3933-fc77-4ce9-cfd0-08d8865bc6d7 x-ms-exchange-crosstenant-originalarrivaltime: 11 Nov 2020 16:06:40.8123 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: mr286sVWG67Z3Y2vuzixBjwoav/CHQXv8tUbeirxUa9quC4UcPfWw1lw/4I0ZCOW5a6/LiV0OBHuynDY/nJ/nuTE4f6ZhnECPTyuh2y/xmc= x-ms-exchange-transport-crosstenantheadersstamped: SJ0PR11MB5071 x-originatororg: comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <915D3166251C4847BB56A7218C81F6FA@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWQ X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-11_07:2020-11-10, 2020-11-11 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [Add] FW: Requesting NomCom feedback X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:07:05 -0000 SGkgRXZlcnlvbmUsDQoNClRoZSBOb21jb20gaXMgcmVxdWVzdGluZyBmZWVkYmFjayBvbiBjYW5k aWRhdGVzLg0KDQpJJ20gdGhlIElFVEYgVHJ1c3QgbGlhaXNvbiB0byB0aGUgbm9tY29tIHRoaXMg eWVhLCBhbmQgSSdkIGxpa2UgdG8gYWRkIHRoZSBhZGRpdGlvbmFsIG51ZGdlIHRvIGVhY2ggb2Yg eW91OiAgVGhpcyB5ZWFyIGl0J3MgZXNwZWNpYWxseSBpbXBvcnRhbnQgZm9yIHRoZSBjb21tdW5p dHkgdG8gcHJvdmlkZSBmZWVkYmFjayB0aGlzIHllYXIgYXMgdGhpcyBOb21jb20gaXMgc2VsZWN0 aW5nIHRoZSBuZXh0IElFVEYgQ2hhaXIsIHF1aXRlIGEgZmV3IEFEJ3MsIElBQiBtZW1iZXJzLCBh biBMTEMgQm9hcmQgTWVtYmVyLCBhbmQgYW4gSUVURiBUcnVzdGVlLiAgICBUaGlzIGlzIHlvdXIg Y2hhbmNlIHRvIHByb3ZpZGUgZmVlZGJhY2sgLSBib3RoIGZvciBhbmQgYWdhaW5zdCBjYW5kaWRh dGVzIC0gYW5kIC0gdG8gZ2l2ZSBnZW5lcmFsIGZlZWRiYWNrIG9uIHdoYXQgdGhlIE5vbWNvbSBz aG91bGQgYmUgbG9va2luZyBmb3IgaW4gdGhlIHZhcmlvdXMgcG9zaXRpb25zLg0KDQpSZWdhcmRz DQpHbGVubg0KDQoNCkZvcndhcmRlZCBNZXNzYWdlLi4uLg0KDQrvu79PbiAxMS8xMC8yMCwgNDox NCBQTSwgIldHQ2hhaXJzIG9uIGJlaGFsZiBvZiBTVEFSSywgQkFSQkFSQSBIIiA8d2djaGFpcnMt Ym91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgYnM3NjUyQGF0dC5jb20+IHdyb3RlOg0KDQog ICAgTm9tQ29tIGlzIGNvbnNpZGVyaW5nIG5vbWluZWVzIGZvciBBRCBwb3NpdGlvbnMsIElFVEYg Q2hhaXIsIElBQiwgTExDIEJvYXJkLCBhbmQgSUVURiBUcnVzdC4gV2UgbmVlZCBtb3JlIGlucHV0 IGZyb20gdGhlIGNvbW11bml0eSBib3RoIG9uIHNwZWNpZmljIG5vbWluZWVzIGFuZCBvbiBvdmVy LWFyY2hpbmcgdG9waWNzIHJlZ2FyZGluZyB3aGF0IHRoZSBjb21tdW5pdHkgd2FudHMgZnJvbSB0 aGVzZSBzcGVjaWZpYyBncm91cHMgYW5kIHdhbnRzIGZyb20gaXRzIGxlYWRlcnNoaXAgaW4gZ2Vu ZXJhbC4gV2UgbmVlZCAqeW91ciogaW5wdXQuDQoNCiAgICAqKiBEZWFkbGluZSBmb3IgY29tbXVu aXR5IGZlZWRiYWNrIGlzIEZyaWRheSBOb3ZlbWJlciAyMC4gKioNCg0KICAgIFdlJ3ZlIHBhaWQg YXR0ZW50aW9uIHRvIGRpc2N1c3Npb25zIG9uIHRoZSBpZXRmIGxpc3QuIElzc3VlcyByYWlzZWQg dGhlcmUgaGF2ZSBiZWVuIGJyb3VnaHQgdXAgaW4gaW50ZXJ2aWV3cy4NCg0KICAgIFdlJ3ZlIGFs c28gYXNrZWQgcXVlc3Rpb25zIG9mIG5vbWluZWVzIGJhc2VkIG9uIGZlZWRiYWNrIHJlY2VpdmVk LCBhbmQgYmFzZWQgb24gdGhlICJUb3BpY3MiIHRoYXQgcGVvcGxlIHNhaWQgd2VyZSBpbXBvcnRh bnQuDQogICAgV2UncmUgbGlzdGVuaW5nIHRvIHlvdS4NCg0KICAgIEJ1dCBtb3N0IG9mIHRoZSBp bnB1dCB0byBkYXRlIGhhcyBjb21lIGZyb20gYSBmZXcgY29uc2lzdGVudGx5IHZvY2FsIHBlb3Bs ZS4gV2UgbmVlZCB0byBoZWFyIGZyb20gbW9yZSBvZiB5b3UuDQoNCiAgICBJIHNjaGVkdWxlZCBv dXIgb2ZmaWNlIGhvdXJzIGR1cmluZyB0aGUgMiB3ZWVrcyBiZWZvcmUgbmV4dCB3ZWVrJ3MgSUVU RiwgYmVjYXVzZSBJRVRGIHdlZWsgaXMgc28gYnVzeS4gV2UgaGF2ZSBvbmUgbW9yZSBsZWZ0ICgx ODowMC0xOTowMCBVVEMgTm92ZW1iZXIgMTEpLiBOby1vbmUgYnV0IE5vbUNvbSBtZW1iZXJzIHNo b3dlZCB1cCBmb3Igb3VyIGZpcnN0IDMuIOKYuSBJZiB0aGVyZSBpcyBkZW1hbmQgZm9yIG1vcmUg b2ZmaWNlIGhvdXJzLCBJJ2xsIHNjaGVkdWxlIHRoZW07IGJ1dCB0aGlzIHJlYWxseSBkb2Vzbid0 IHNlZW0gdG8gYmUgdGhlIHByZWZlcnJlZCBmb3JtYXQgZm9yIGlucHV0Lg0KDQogICAgTW9zdCBp bnB1dCBpcyBjb21pbmcgaW4gYXMgZWl0aGVyDQogICAgLSBlbWFpbCB0byBub21jb20yMEBpZXRm Lm9yZw0KICAgIC0gZmVlZGJhY2sgb24gaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbm9tY29tLzIwMjAvZmVlZGJhY2svX187ISFQSVplZVc1 d3NjeW5SUSE4QzRNUFJybmFubTFWMmdaUG1OUDV4U2Zld3hSdjFST1ROZEw5TEFKQ0RUaFJLOEF5 QmlKcnlqNWpHZldWeFBOJA0KICAgIE9uIHRoZSBmZWVkYmFjayBwYWdlLCB0aGUgc3BlY2lmaWMg bm9taW5lZXMgYXJlIGFsbCBsaXN0ZWQgYXQgdGhlIHRvcC4gR2VuZXJhbCBUb3BpY3MgYXJlIGF0 IHRoZSBib3R0b20uDQogICAgV2UgcGF5IGF0dGVudGlvbiB0byBhbGwgdGhlIGNvbW1lbnRzIHdl IGdldCB0aHJvdWdoIHRoZXNlIGNoYW5uZWxzLg0KDQogICAgSSdsbCBhbHNvIHRyeSB0byBoYW5n IG91dCBpbiBHYXRoZXIuVG93biBkdXJpbmcgSUVURiBicmVha3MgbmV4dCB3ZWVrLg0KICAgIEkn bSBub3QgZ29pbmcgdG8gaGF2ZSBhIHNwZWNpZmljIE5vbUNvbSBhcmVhIGluIEdhdGhlci5Ub3du LCBiZWNhdXNlIGl0IHdhcyByZWFsbHkgbG9uZWx5IGhhbmdpbmcgb3V0IHRoZXJlIGR1cmluZyBJ RVRGIDEwOC4NCiAgICBCdXQgcGxlYXNlIGZlZWwgZnJlZSB0byBodW50IG1lIGRvd24gYW5kIGJl bmQgbXkgZWFyIC0tIG9uIE5vbUNvbSBpc3N1ZXMgb3IganVzdCB0byBjaGF0Lg0KICAgIEkgbWlz cyBzZWVpbmcgYWxsIG9mIHknYWxsIQ0KICAgIEJhcmJhcmENCg0KICAgIEJhcmJhcmEgU3RhcmsN CiAgICBOb21Db20gMjAyMCBDaGFpcg0KDQoNCg== From nobody Wed Nov 11 10:36:39 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D693A09BD for ; Wed, 11 Nov 2020 10:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.854 X-Spam-Level: X-Spam-Status: No, score=-0.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 j4H17VNvglO8 for ; Wed, 11 Nov 2020 10:36:36 -0800 (PST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 45EC23A098A for ; Wed, 11 Nov 2020 10:36:36 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id l2so2690032qkf.0 for ; Wed, 11 Nov 2020 10:36:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E+XWK+e4GeZ3+wx4ubdex2KZU1oa0HT4Rlpp5a+f1r8=; b=SZ2Yu/RoRpfIyZp3z1hfmerRZ1fmDWHUNXuChUApJWiZqV9XRF4+Ru7IbXpLdQ/b/g zBvqFW58LEM8mpq0Z4SmtRvuEjli7fVgvF74WqH3ZjCziK/lTxSc18bPIu7/JWkG2lfH gZCDkSrXydCDtZSjXcbNVf2y2ELbJINVeIblpP2DelOtbvejVDN41//CXPDPGJZa+hz8 R30sIRQ+9up65UaJ2F1L4gQE8HNONmJPZGsrivdQEf7HJhZH7bMziFWNY9ZzmiWj+bEm JyXVe3vl6bRLGgwrt5yTm8PtH72Tr3E4g/mEoT5RMaVoeAt9WGWefVG5wpXanjhYHr7g j0Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=E+XWK+e4GeZ3+wx4ubdex2KZU1oa0HT4Rlpp5a+f1r8=; b=JWONeAVdkaXX4LIc9nmtlGAtT5Q2C662vCJGsCvtkiisphhEDTnkiWnsKPZxhsqxWk HkwJf0c8q+6Q5tYROlMCS3T5nqYyVY+5eUhWQ22KeigMv1kIq9HNU+5k6gxdNZCpVDB8 WhK79Q3UFGwSxOMUCRJSZup8ypcw6kBiHH/9GusVs0yog7y1DjSat3rVq5l1OAplaV1A F6maokN8UWVlZbvFzRHu3j2GKPYna/OrIOdVg8CO62czQJSiOYu1MxxQTItoDtPBAlpl wgrV4cpEeq4TfgKg6VxIWQ9sRjWFw/ufHJqOpCKtMgkxUhVlsAevODHPu0nderIQduf/ Zxig== X-Gm-Message-State: AOAM5317mlwxcXsGE6v1vF8nlXRrDNI+ZsOayoENO1nkGlM48PRccdof 6Dm+wUuitNaSaLd1hYcqfImdBxgH/cR+ta+sZ2U= X-Google-Smtp-Source: ABdhPJz0kujlPvRnlr8BljXB2Kt2ZRrCUKUUmSsiT8/1Zl4o/TkKpCEjO8UOzNtSH6iVcUX401xbqL+tuBRyj98f75Y= X-Received: by 2002:a37:d0c:: with SMTP id 12mr25637443qkn.418.1605119795222; Wed, 11 Nov 2020 10:36:35 -0800 (PST) MIME-Version: 1.0 References: <9DE350EE-F438-435A-8C34-9C15A9744E7A@apple.com> <20201105135928.GA31848@sources.org> <9E81934A-447E-4A08-9B6E-4FADAD98F7AF@apple.com> In-Reply-To: <9E81934A-447E-4A08-9B6E-4FADAD98F7AF@apple.com> From: Chris Box Date: Wed, 11 Nov 2020 18:36:24 +0000 Message-ID: To: Tommy Pauly Cc: Stephane Bortzmeyer , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000375a8e05b3d913f0" Archived-At: Subject: Re: [Add] Discovery of Equivalent Encrypted Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 18:36:38 -0000 --000000000000375a8e05b3d913f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 5 Nov 2020 at 16:12, Tommy Pauly wrote: > > If your unencrypted resolver is on a private address, you essentially hav= e > two options: > > 1. Host your equivalent encrypted resolver on the same IP address, which > puts us in the =E2=80=9Copportunistic=E2=80=9D bucket defined in the draf= t. This isn=E2=80=99t > strongly authenticated, but it works and still lets you discover the righ= t > path for DoH, etc. > 2. Provision the name of the encrypted resolver via DHCP/RA, which means > we don=E2=80=99t need to worry about IP addresses matching. > Tommy, For option 1, consider a case where a home CPE isn't able, or isn't considered secure enough, to run a TLS server. Would it be acceptable for this CPE to operate a simple TCP proxy to a more distant equivalent encrypted resolver, so that 192.168.0.1:853 is proxied at TCP level to :853? At first glance this would seem to meet your opportunistic validation requirement. But option 2, such as that enabled by draft-btw-add-home-10, appears to be better. Chris --000000000000375a8e05b3d913f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, 5 Nov 2020 at 16:12, Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:

If your unencrypted resolver is on a private address, you essentially have = two options:

1. Host your equivalent encrypted resolver on the same IP address, which pu= ts us in the =E2=80=9Copportunistic=E2=80=9D bucket defined in the draft. T= his isn=E2=80=99t strongly authenticated, but it works and still lets you d= iscover the right path for DoH, etc.
2. Provision the name of the encrypted resolver via DHCP/RA, which means we= don=E2=80=99t need to worry about IP addresses matching.
<= div>
Tommy,

For option 1, consider a= case where a home CPE isn't able, or isn't considered secure enoug= h, to run a TLS server. Would it be acceptable for this CPE to operate a si= mple TCP proxy to a more distant equivalent encrypted resolver, so that 192.168.0.1:853 is proxied at TCP level= to <public IP>:853? At first glance this would seem to meet your opp= ortunistic validation requirement.

But option 2, s= uch as that enabled by draft-btw-add-home-10, appears to be better.

Chris
--000000000000375a8e05b3d913f0-- From nobody Wed Nov 11 17:03:58 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B773A128B for ; Wed, 11 Nov 2020 17:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.858 X-Spam-Level: X-Spam-Status: No, score=-0.858 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 GIv5Vilz5-Xs for ; Wed, 11 Nov 2020 17:03:55 -0800 (PST) Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (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 0153A3A128A for ; Wed, 11 Nov 2020 17:03:54 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 0AC10tAe043254; Wed, 11 Nov 2020 17:03:53 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=WrBvNo1YAcQasqqJvPlYBKPJQa0ZMFxkWsTtqjFGmiI=; b=uDBgNzJz6VcuNWtuF3u3fbmH2hES5gllpNrvoSZMcV++CFelZGpgU/+k8uGOEkA12eJg 6I4Yva6mT8PIdczAfE7VBZ/ypk5bRwVfWoKV02TAOIsH6TG9pP+YICjscLjKCUGDgs7C zk6DcOnfzwW5bOkp9QTof7PuThyk/qcL6gfFsDI8wPsCPEF2gQeHPUZq8QUcXVZ1VqwY pgPZ6aMWhwlRWRTySNpU6Beki3j5iDUq/dK++tMy0Nmxoe/BkkDxuJmv054MnKmmud8o NfOWiZboXT7CuMnhR3MrHwatbNfDg/7RzXx+5P4My8fD6Zm3cQCU96vCl68kwSlm4S1W Bw== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by nwk-aaemail-lapp03.apple.com with ESMTP id 34pc5wknxs-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Nov 2020 17:03:53 -0800 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QJN007POSAHGHK0@rn-mailsvcp-mta-lapp03.rno.apple.com>; Wed, 11 Nov 2020 17:03:53 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QJN00300S5LXT00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Wed, 11 Nov 2020 17:03:53 -0800 (PST) X-Va-A: X-Va-T-CD: 4ca98f54ad25041595a24022c271a789 X-Va-E-CD: 97de42ee73d1653b034b3fece4277d12 X-Va-R-CD: 8eff5a00d73fb7eb55a144beda73e8f7 X-Va-CD: 0 X-Va-ID: f54cff70-4af3-46a0-9cf3-594e1548be6d X-V-A: X-V-T-CD: 4ca98f54ad25041595a24022c271a789 X-V-E-CD: 97de42ee73d1653b034b3fece4277d12 X-V-R-CD: 8eff5a00d73fb7eb55a144beda73e8f7 X-V-CD: 0 X-V-ID: eda6739f-6760-4eea-ad08-232bbb56f388 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-11_12:2020-11-10, 2020-11-11 signatures=0 Received: from localhost.localdomain (unknown [17.235.36.148]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QJN00WBSSAGZR00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Wed, 11 Nov 2020 17:03:53 -0800 (PST) From: Tommy Pauly Message-id: <6865A42F-1760-4037-9F1B-72F0D1F214BF@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_5F31431C-55F4-454B-9BEE-7CED033F0382" MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\)) Date: Wed, 11 Nov 2020 17:03:52 -0800 In-reply-to: Cc: Stephane Bortzmeyer , ADD Mailing list To: Chris Box References: <9DE350EE-F438-435A-8C34-9C15A9744E7A@apple.com> <20201105135928.GA31848@sources.org> <9E81934A-447E-4A08-9B6E-4FADAD98F7AF@apple.com> X-Mailer: Apple Mail (2.3654.0.3.2.26) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-11_12:2020-11-10, 2020-11-11 signatures=0 Archived-At: Subject: Re: [Add] Discovery of Equivalent Encrypted Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 01:03:57 -0000 --Apple-Mail=_5F31431C-55F4-454B-9BEE-7CED033F0382 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 11, 2020, at 10:36 AM, Chris Box = wrote: >=20 > On Thu, 5 Nov 2020 at 16:12, Tommy Pauly = > wrote: >=20 > If your unencrypted resolver is on a private address, you essentially = have two options: >=20 > 1. Host your equivalent encrypted resolver on the same IP address, = which puts us in the =E2=80=9Copportunistic=E2=80=9D bucket defined in = the draft. This isn=E2=80=99t strongly authenticated, but it works and = still lets you discover the right path for DoH, etc. > 2. Provision the name of the encrypted resolver via DHCP/RA, which = means we don=E2=80=99t need to worry about IP addresses matching. >=20 > Tommy, >=20 > For option 1, consider a case where a home CPE isn't able, or isn't = considered secure enough, to run a TLS server. Would it be acceptable = for this CPE to operate a simple TCP proxy to a more distant equivalent = encrypted resolver, so that 192.168.0.1:853 is = proxied at TCP level to :853? At first glance this would seem = to meet your opportunistic validation requirement. Yes, I think that would meet the bar for opportunistic. Effectively, we = would have confirmation that the local resolver (or whoever controls the = local resolver=E2=80=99s IP address) is handling the traffic, even if it = is just forwarded. This is definitely better than just pointing the = client to an entirely different IP address. >=20 > But option 2, such as that enabled by draft-btw-add-home-10, appears = to be better. Agreed. Best, Tommy >=20 > Chris --Apple-Mail=_5F31431C-55F4-454B-9BEE-7CED033F0382 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 11, 2020, at 10:36 AM, Chris Box <chris.box.ietf@gmail.com> wrote:

On Thu, 5 Nov 2020 at 16:12, Tommy Pauly = <tpauly=3D40apple.com@dmarc.ietf.org> wrote:

If your unencrypted resolver is on a private address, you essentially = have two options:

1. Host your equivalent encrypted resolver on the same IP address, which = puts us in the =E2=80=9Copportunistic=E2=80=9D bucket defined in the = draft. This isn=E2=80=99t strongly authenticated, but it works and still = lets you discover the right path for DoH, etc.
2. Provision the name of the encrypted resolver via DHCP/RA, which means = we don=E2=80=99t need to worry about IP addresses matching.

Tommy,

For option 1, consider a case where a home CPE isn't able, or = isn't considered secure enough, to run a TLS server. Would it be = acceptable for this CPE to operate a simple TCP proxy to a more distant = equivalent encrypted resolver, so that 192.168.0.1:853 is proxied at TCP level to <public = IP>:853? At first glance this would seem to meet your opportunistic = validation requirement.

Yes, I think that would meet the bar for opportunistic. = Effectively, we would have confirmation that the local resolver (or = whoever controls the local resolver=E2=80=99s IP address) is handling = the traffic, even if it is just forwarded. This is definitely better = than just pointing the client to an entirely different IP address.

But option 2, such as that enabled by = draft-btw-add-home-10, appears to be = better.

Agreed.

Best,
Tommy

Chris

= --Apple-Mail=_5F31431C-55F4-454B-9BEE-7CED033F0382-- From nobody Sat Nov 14 15:50:02 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7B33A0A21 for ; Sat, 14 Nov 2020 15:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 5DBIzk0gsVnc for ; Sat, 14 Nov 2020 15:49:58 -0800 (PST) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 3839D3A0A20 for ; Sat, 14 Nov 2020 15:49:58 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id r9so19516345lfn.11 for ; Sat, 14 Nov 2020 15:49:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Drx7NB3Ehan8xsbAyPxScXqnpw9XwLxOT7s90kn+VtY=; b=lLf5mLziCVlveSTT7x9UcPVMgryd6JxNFG0zyxs0HrcA3S2atjvUID2iHQmlM8J+iK FRb9D7DmTWDP4tSscmLUCuqYv7iSPFiXelz8vB98Mk2tt2211aFfPIFdG9Smg9DxH2Aj luASw+7TMRp+q2m5c396CREJ2iC0hW/O+UWy2bNcG/7C7Ur4Hm+lf3g3KJe6wLleC9zG 1N2oQKpUeyPpCtw04sBW8MJEtvjHG8y/6prHrOEQHXgVGAqoFfdhQDpOhIwZrZmXWkT2 jDHMQUX564ABJev2DPmsXrkbRIgLgMc2Et2DBTvG565o8UHsA7RAjHQqwXkM/8OM+79l J9Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Drx7NB3Ehan8xsbAyPxScXqnpw9XwLxOT7s90kn+VtY=; b=eFJa5wZSrFS9VBdXcjeWX1IN8R+Rf4Xxm22P2gL6PwhKSKYrD4fbfW8Jk6m0e3eB2R 9BT1U4O6TThOgGU+aEc2HcD+/TuttW/HvUrCxLRQzlpzRCJqNyE1Hnx9hRrzO5ykxgJd BGxPcuItaD8bFF8l2o+dhKjLd9im1MJzaynSTfjFKr8bCshEPOv/Z+p4CStrOzrU+7tJ Hc8Nuqn36GLkr/ddPyrGoE3BJfF6igxaeIe45OoRj3n1P34mC5ocDo3ucnVSlGXR51cd Z71jdB8Y7e7QlEhlzHitgBnAYRfH76JHJBdeuruLANwWuRJ1XwE5EW+BJJo4rE7+Cba0 wC5w== X-Gm-Message-State: AOAM532OFT+SZ06YnU7nL0+UfnjTpJFmT+0WXB04dwBpEskDGKDTiEoG cPVuLjCNwWnmjZ7+uUSQgpU5CEMYfORoVMC+8lOCyyX1jc6ij97A X-Google-Smtp-Source: ABdhPJy8y3xIZHY77ViUZFnnynDMgHB1HB+KDMFFIVtFtcy0gW61nrMCqmPpg2NSwR9/q3+QSORuMAXEspHhnKZpfcA= X-Received: by 2002:a19:c3cd:: with SMTP id t196mr3058651lff.26.1605397795784; Sat, 14 Nov 2020 15:49:55 -0800 (PST) MIME-Version: 1.0 From: Eric Rescorla Date: Sat, 14 Nov 2020 15:49:19 -0800 Message-ID: To: ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000057626605b419cdd9" Archived-At: Subject: [Add] Review of draft-box-add-requirements-01.txt X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2020 23:50:01 -0000 --00000000000057626605b419cdd9 Content-Type: text/plain; charset="UTF-8" This document is improved by restricting itself to one use case. Thanks. More comments below. S 3. The network's recommended unencrypted resolver may have a number of properties that differ from a generic resolver. It may be able to answer names that are not known globally, it may exclude some names (for positive or negative reasons), and it may provide address answers that have improved proximity. In this use case it is assumed that the user who chose to join this network would also like to make use of these properties of the network's unencrypted resolver, at least some of the time. This seems like a terrible assumption. As has been discussed many times, users basically have no idea about IETF, and so why would you think they want to "make use of" various filtering or surveillance properties, let alone cases where the resolver injects its own data as in captive portals. I understand what you're trying to do here, but I think what you need to say is something quite different: The objective of this use case is simply to replace Do53 with an encrypted DNS protocol to the same resolver. Note that the network's recommended unencrypted resolver may have a number of properties that differ from a generic resolver. It may be able to answer names that are not known globally, it may exclude some names (for positive or negative reasons), and it may provide address answers that have improved proximity. The user may or may not desire these properties and may or may not be aware of them, but for the purposes of this use case, we are not attempting to change these properties, but merely to provide the user with encrypted transport. Using an encrypted and authenticated resolver that is equivalent to the one provisioned by the network can provide several benefits that are not possible if only unencrypted DNS is used: ... * Authenticate that the DNS resolver is the correct one * Verify that answers come from the selected DNS resolver "can" is doing a lot more work here than I am comfortable with. Ignoring the case where the resolver is *not* equivalent to the one provided by the network, which you're just assuming is not the case, in many cases there is real uncertainty about which network is being joined. The most obvious case is coffee shop networks, hotspots, etc. in which the user may think they are joining the network associated with a given establishment (say Starbucks) but they are in fact joining the attacker's network. While it may be the case that they are legitimately upgraded to the attacker's Do[HTQ] server, I don't think you can call this "authenticating that the DNS resolver is the correct one". S 3.1. Given two resolvers A and B, equivalence is the claim that A and B can provide the same upper-layer DNS function to the client. This does not include the DNS transport protocol (e.g. Do53 or DNS-over- HTTPS) which can differ between equivalent resolvers. To provide equivalence it is frequently likely to be the case that A and B are operated by the same administrative domain, but this document does not require that. This doesn't seem right. Suppose I stand up a fake DoT resolver that just proxies traffic to the Do53 resolver and then sends me a copy. That's providing the same service as the Do53 resolver (you might argue that the Do53 resolver isn't leaking the traffic to me and so the service isn't the same, but if I'm an on-path attacker, the service actually is the same as I get the data that way). * The local network can claim that one or more encrypted DNS resolvers (B, C, etc) are equivalent to the Do53 resolver (A) it has offered. This is known as network-identified. * During communication with the (often unencrypted) resolver (A), this resolver can claim that one or more encrypted DNS resolvers (B, C, etc) are equivalent. This is known as resolver-identified. These seem like two options, but they're not the only one. For instance, neither of these covers the preconfigured SPAU lists that Chrome and Edge use. Network-identified is preferred since it comes from the same source of information, and removes the need to talk to the Do53 resolver at all. However it cannot be the sole mechanism, at least for several years, since there is a large installed base of local network equipment that is difficult to upgrade with new features. Hence the second mechanism must support being able to announce an equivalent resolver using only existing widely-deployed DNS features. I'd prefer this document not to take a position on what technical approach is preferred at this time. For instance, if we have to do resolver-identified anyway, it's not clear that having two mechanisms is in fact better. It's not clear to me if 3.2 and 4 are requiring support for network-identified, but if so it should be a topic of discussion. S 5. The way that this section is written implies that it is preferable to have encrypted transport terminated at the local resolver rather than at some central caching resolver. While I agree that this has certain benefits, it also has a number of operational drawbacks (for instance, these local access points/routers are often quite insecure). This section should be adjusted to be more neutral. S 6. * Cause clients to use a discovered resolver which has no authenticated delegation from a client-known entity. It's not clear to me what this means. As read literally, why doesn't it rule out basically all of the versions where the client receives some unauthenticated Do53 message that says "DoT at this same address"? S 7. | R1.1 | Discovery MUST provide a local network the | | | ability to announce to clients a set of, or | | | absence of, equivalent resolvers. | I don't agree that this is a requirement. See my comments about S 3.1. above. | R1.3 | Discovery MUST support at least one encrypted | | | DNS protocol. | +-------------+-------------------------------------------------+ | R1.4 | Discovery SHOULD support all standardised | | | encrypted DNS protocols. | I don't understand these. Are you saying it's not a requirement to be able to indicate all the standardized protocols? That seems like it would be a fail. | R2.1 | Networks MUST be able to announce one or more | | | equivalent encrypted DNS resolvers using | | | existing mechanisms such as DHCPv4, DHCPv6, | | | IPv6 Router Advertisement, and the Point-to- | | | Point Protocol. | Again, I don't agree. | R2.2 | The format for resolver information MUST be | | | specified such that provisioning mechanisms | | | defined outside of the IETF can advertise | | | encrypted DNS resolvers. | At most a SHOULD | R5.2 | Threat modelling MUST assume that there is a | | | passive eavesdropping attacker on the local | | | network. | +-------------+-------------------------------------------------+ | R5.3 | Threat modelling MUST assume that an attacker | | | can actively attack from outside the local | | | network. | Normally one wouldn't call these requirements. -Ekr --00000000000057626605b419cdd9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This document is improved by restricting itself to one use= case.
Thanks.

More comments below.

S 3.

=C2=A0 =C2= =A0The network's recommended unencrypted resolver may have a number of<= br>=C2=A0 =C2=A0properties that differ from a generic resolver.=C2=A0 It ma= y be able to
=C2=A0 =C2=A0answer names that are not known globally, it m= ay exclude some names
=C2=A0 =C2=A0(for positive or negative reasons), a= nd it may provide address
=C2=A0 =C2=A0answers that have improved proxim= ity.=C2=A0 In this use case it is assumed
=C2=A0 =C2=A0that the user who= chose to join this network would also like to make
=C2=A0 =C2=A0use of = these properties of the network's unencrypted resolver, at
=C2=A0 = =C2=A0least some of the time.

This seems like a terrible assumption.= As has been discussed many
times, users basically have no idea about IE= TF, and so why would you
think they want to "make use of" vari= ous filtering or surveillance
properties, let alone cases where the reso= lver injects its own data
as in captive portals. I understand what you&#= 39;re trying to do here,
but I think what you need to say is something q= uite different:

=C2=A0 =C2=A0The objective of this use case is simpl= y to replace Do53 with
=C2=A0 =C2=A0an encrypted DNS protocol to the sam= e resolver. Note that
=C2=A0 =C2=A0the network's recommended unencry= pted resolver may have a number of
=C2=A0 =C2=A0properties that differ f= rom a generic resolver.=C2=A0 It may be able to
=C2=A0 =C2=A0answer name= s that are not known globally, it may exclude some names
=C2=A0 =C2=A0(f= or positive or negative reasons), and it may provide address
=C2=A0 =C2= =A0answers that have improved proximity. The user may or may not
=C2=A0 = =C2=A0desire these properties and may or may not be aware of them,
=C2= =A0 =C2=A0but for the purposes of this use case, we are not attempting
= =C2=A0 =C2=A0to change these properties, but merely to provide the user
= =C2=A0 =C2=A0with encrypted transport.



=C2=A0 =C2=A0Using an= encrypted and authenticated resolver that is equivalent to
=C2=A0 =C2= =A0the one provisioned by the network can provide several benefits that
= =C2=A0 =C2=A0are not possible if only unencrypted DNS is used:

=C2= =A0 =C2=A0...

=C2=A0 =C2=A0* =C2=A0Authenticate that the DNS resolve= r is the correct one

=C2=A0 =C2=A0* =C2=A0Verify that answers come f= rom the selected DNS resolver

"can" is doing a lot more wo= rk here than I am comfortable with.
Ignoring the case where the resolver= is *not* equivalent to the one
provided by the network, which you'r= e just assuming is not the case,
in many cases there is real uncertainty= about which network is being
joined. The most obvious case is coffee sh= op networks, hotspots,
etc. in which the user may think they are joining= the network
associated with a given establishment (say Starbucks) but t= hey are in
fact joining the attacker's network. While it may be the = case that
they are legitimately upgraded to the attacker's Do[HTQ] s= erver, I
don't think you can call this "authenticating that the= DNS resolver is
the correct one".


S 3.1.
=C2=A0 =C2= =A0Given two resolvers A and B, equivalence is the claim that A and B
= =C2=A0 =C2=A0can provide the same upper-layer DNS function to the client.= =C2=A0 This
=C2=A0 =C2=A0does not include the DNS transport protocol (e.= g.=C2=A0 Do53 or DNS-over-
=C2=A0 =C2=A0HTTPS) which can differ between = equivalent resolvers.=C2=A0 To provide
=C2=A0 =C2=A0equivalence it is fr= equently likely to be the case that A and B are
=C2=A0 =C2=A0operated by= the same administrative domain, but this document does
=C2=A0 =C2=A0not= require that.

This doesn't seem right. Suppose I stand up a fak= e DoT resolver that
just proxies traffic to the Do53 resolver and then s= ends me a copy.
That's providing the same service as the Do53 resolv= er (you might
argue that the Do53 resolver isn't leaking the traffic= to me and
so the service isn't the same, but if I'm an on-path = attacker, the
service actually is the same as I get the data that way).<= br>
=C2=A0 =C2=A0* =C2=A0The local network can claim that one or more en= crypted DNS
=C2=A0 =C2=A0 =C2=A0 resolvers (B, C, etc) are equivalent to= the Do53 resolver (A) it
=C2=A0 =C2=A0 =C2=A0 has offered.=C2=A0 This i= s known as network-identified.

=C2=A0 =C2=A0* =C2=A0During communica= tion with the (often unencrypted) resolver (A),
=C2=A0 =C2=A0 =C2=A0 thi= s resolver can claim that one or more encrypted DNS resolvers
=C2=A0 =C2= =A0 =C2=A0 (B, C, etc) are equivalent.=C2=A0 This is known as resolver-iden= tified.

These seem like two options, but they're not the only on= e. For instance,
neither of these covers the preconfigured SPAU lists th= at Chrome and
Edge use.

=C2=A0 =C2=A0Network-identified is prefer= red since it comes from the same source
=C2=A0 =C2=A0of information, and= removes the need to talk to the Do53 resolver at
=C2=A0 =C2=A0all.=C2= =A0 However it cannot be the sole mechanism, at least for several
=C2=A0= =C2=A0years, since there is a large installed base of local network
=C2= =A0 =C2=A0equipment that is difficult to upgrade with new features.=C2=A0 H= ence the
=C2=A0 =C2=A0second mechanism must support being able to announ= ce an equivalent
=C2=A0 =C2=A0resolver using only existing widely-deploy= ed DNS features.

I'd prefer this document not to take a position= on what technical
approach is preferred at this time. For instance, if = we have to do
resolver-identified anyway, it's not clear that having= two mechanisms
is in fact better.=C2=A0 It's not clear to me if 3.2= and 4 are requiring
support for network-identified, but if so it should= be a topic of
discussion.


S 5.
The way that this section = is written implies that it is preferable
to have encrypted transport ter= minated at the local resolver rather
than at some central caching resolv= er. While I agree that this has
certain benefits, it also has a number o= f operational drawbacks
(for instance, these local access points/routers= are often quite
insecure). This section should be adjusted to be more n= eutral.



S 6.
=C2=A0 =C2=A0* =C2=A0Cause clients to use a = discovered resolver which has no
=C2=A0 =C2=A0 =C2=A0 authenticated dele= gation from a client-known entity.

It's not clear to me what thi= s means. As read literally, why
doesn't it rule out basically all of= the versions where
the client receives some unauthenticated Do53 messag= e that
says "DoT at this same address"?


S 7.
=C2= =A0 =C2=A0 =C2=A0| R1.1 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Discovery MUST provide= a local network the =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | ability to announce to clients a set o= f, or =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | absence of, equivalent resolvers. =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

I don't agree that this is a requirem= ent. See my comments about S 3.1.
above.


=C2=A0 =C2=A0 =C2=A0= | R1.3 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Discovery MUST support at least one enc= rypted =C2=A0 |
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 | DNS protocol. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
= =C2=A0 =C2=A0 =C2=A0+-------------+----------------------------------------= ---------+
=C2=A0 =C2=A0 =C2=A0| R1.4 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Disco= very SHOULD support all standardised =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | encrypted DNS proto= cols. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0|

I don't understand these. Are you saying it'= s not a requirement to
be able to indicate all the standardized protocol= s? That seems like
it would be a fail.

=C2=A0 =C2=A0 =C2=A0| R2.1= =C2=A0 =C2=A0 =C2=A0 =C2=A0| Networks MUST be able to announce one or more= =C2=A0 |
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | equivalent encrypted DNS resolvers using =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | exist= ing mechanisms such as DHCPv4, DHCPv6, =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2= =A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | IPv6 Router Advertisement,= and the Point-to- =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Point Protocol. =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |

Again, I don't agree.

=C2=A0 =C2=A0 =C2=A0| = R2.2 =C2=A0 =C2=A0 =C2=A0 =C2=A0| The format for resolver information MUST = be =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | specified such that provisioning mechanisms =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | defined = outside of the IETF can advertise =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 = =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | encrypted DNS resolvers= . =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|

At most a SHOULD

=C2=A0 =C2=A0 =C2=A0| R5.2 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| Threat modelling MUST assume that there is a =C2= =A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | passive eavesdropping attacker on the local =C2=A0 =C2=A0 |
=C2=A0= =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | network. =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2= =A0 =C2=A0+-------------+-------------------------------------------------+=
=C2=A0 =C2=A0 =C2=A0| R5.3 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Threat modellin= g MUST assume that an attacker =C2=A0 |
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | can actively attack from outside the loca= l =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | network. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|

Normally one wouldn't call these requireme= nts.

-Ekr


--00000000000057626605b419cdd9-- From nobody Sat Nov 14 16:13:31 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34093A0C5D for ; Sat, 14 Nov 2020 16:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 vHTjAuRIwACT for ; Sat, 14 Nov 2020 16:13:28 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 126623A0C4D for ; Sat, 14 Nov 2020 16:13:28 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id 74so19559909lfo.5 for ; Sat, 14 Nov 2020 16:13:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=e38iU9n/ZcE734L+Q2rT+HMCem7tZzlmoUHL+dcedhQ=; b=q2SZ97r+SZdt80cTlFGYBTZOUkBqQ0FkjkJ+jLPl+3eGs8jcKM3sfRgLCQz5gNti1/ ccfAW0XXzIyWIRGcZIqZHAzqVcjVkNkmOI+Mozx5Rjm14QnzJE5eGKtS2nWh9I+qQxv6 eREypxPZTFhlE7HF4//Plb19HKMrS3WP7DQlUrnEsgSCGt8c4EeH5n9hhvr5PMDDbn4T b+Y6tEfKsdcB38jERvBEZpoUYzaqanEtzUdZAjR59AhxPT+1qCsnCrV0qZw8eZ4luZ8W r5vh28sALKtzdMQgiVHnxSWsMj2wUzbhQsqHlmbsYdPbp53F3RRpoW//8U7fZmOqWyaJ Npzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=e38iU9n/ZcE734L+Q2rT+HMCem7tZzlmoUHL+dcedhQ=; b=X2UYRVZ/H+/vGg8sLn61cfO/jtl7WYHnmPx86yyMIMmX8PVn51iq8HS5ecaOkgSc0t dXe8o9a5DL7e0cuN21LS+W+Sr9yoPEykcPBz5nqo4oaXKb2Ia+ksskp2XJtC/ZD3JcO3 4ZYsAjnxtY0XT/J70iFeDFaaTqQay4eFcwJhMs6t+L/YC+Iv0n9sXW7bfczkpwcI7tma hGhAZauTn+T/S2T/4neCptiq1y+N2bJUbqYyhyULnEVoLWoYVld+Avarv4gDpmP03XPE XAm5F3tEkZN6w4SpnD7lC5fWz75qjaUX3ghWJ8Me2HHYj24YVcTN+BTasy54d7+JR+Vx Ly2w== X-Gm-Message-State: AOAM533tUa3rqP+MTfYVrcYnzP83x0UzvSGsLg/dIZ3LXX4NK0MEt8ht iPRLqqqZn0RIfV0n+i5Qga79cwA+dHsCJLYontaeHT1wUQTouxOO X-Google-Smtp-Source: ABdhPJwqneozOL0zov5cv+JnTUjEuBvsLPB2rAlmAgQK4kmbTi5/lOn6O42OO7N2v1eBq1I7cg1CFM9nmtOT7pWONeE= X-Received: by 2002:a05:6512:368a:: with SMTP id d10mr3018296lfs.579.1605399206154; Sat, 14 Nov 2020 16:13:26 -0800 (PST) MIME-Version: 1.0 From: Eric Rescorla Date: Sat, 14 Nov 2020 16:12:50 -0800 Message-ID: To: ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000067f01705b41a21b7" Archived-At: Subject: [Add] Review of draft-pauly-add-deer-00.txt+ X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 00:13:30 -0000 --00000000000067f01705b41a21b7 Content-Type: text/plain; charset="UTF-8" Document: draft-pauly-add-deer-00.txt This seems overall like a fairly sensible mechanism if we assume that HTTPSVC is viable for this purpose. We're working on how to gather some data here and will hopefully have something soon; would be great to hear what others have. Some comments below. S 2. Equivalent Encrypted Resolver: An Encrypted Resolver which is considered to provide answers equivalent to a given resolver. This equivalency can be authenticated with TLS certificates. This has the same problem as with draft-box. If the attacker stands up a resolver that proxies to the given resolver, it would meet this definition, but would not provide confidentiality, which is one of the prime motivators for this work. I know this kind of thing is difficult to formalize, but I think we actually need to. There are two properties we need to capture (1) that your data is only going to the EER (2) that the answers are somehow similar. Perhaps. An Equivalent Encrypted Resolver is one in which (1) the client receives equivalent answers to and (2) the attacker learns no more information than if the client's queries/responses were delivered directly to/from the given resolver without any access by the attacker. Note that the definition of equivalent answers is still somewhat problematic. Ideally we would like to say that the attacker cannot influence the answers at all, but consider the case where the EER is located in some different part of the network topology then an attacker can influence your responses by sending you to an EER or not. S 7. I think it would be useful to clarify what you think the security implications of the opportunistic versus non-opportunistic approaches are. I think I know, but you should lay it out. S 8.1. I think it would be useful to specify some sort of draft SUDN so that we can experiment. --00000000000067f01705b41a21b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Document: draft-pauly-add-deer-00.txt

This seems ov= erall like a fairly sensible mechanism if we
assume that HTTPSVC is viab= le for this purpose. We're working
on how to gather some data here a= nd will hopefully have
something soon; would be great to hear what other= s have.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0
Some comments below.

S 2.
=C2=A0 =C2=A0Equivale= nt Encrypted Resolver: =C2=A0An Encrypted Resolver which is
=C2=A0 =C2= =A0 =C2=A0 considered to provide answers equivalent to a given resolver.=C2=A0 =C2=A0 =C2=A0 This equivalency can be authenticated with TLS certif= icates.

This has the same problem as with draft-box. If the attacker=
stands up a resolver that proxies to the given resolver, it would
me= et this definition, but would not provide confidentiality,
which is one = of the prime motivators for this work.

I know this kind of thing is = difficult to formalize, but I think
we actually need to. There are two p= roperties we need to capture
(1) that your data is only going to the EER= (2) that the answers
are somehow similar. Perhaps.

=C2=A0 =C2=A0= An Equivalent Encrypted Resolver is one in which (1) the client
=C2=A0 = =C2=A0receives equivalent answers to and (2) the attacker learns no more=C2=A0 =C2=A0information than if the client's queries/responses were d= elivered
=C2=A0 =C2=A0directly to/from the given resolver without any ac= cess by the
=C2=A0 =C2=A0attacker.

Note that the definition of eq= uivalent answers is still somewhat
problematic. Ideally we would like to= say that the attacker cannot
influence the answers at all, but consider= the case where the
EER is located in some different part of the network= topology
then an attacker can influence your responses by sending you t= o
an EER or not.


S 7.
I think it would be useful to clarif= y what you think the security
implications of the opportunistic versus n= on-opportunistic approaches
are. I think I know, but you should lay it o= ut.


S 8.1.
I think it would be useful to specify some sort of= draft SUDN
so that we can experiment.


=C2=A0 =C2=A0
=C2= =A0 =C2=A0












--00000000000067f01705b41a21b7-- From nobody Sat Nov 14 17:05:35 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E043A0DD5 for ; Sat, 14 Nov 2020 17:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 Vzoa-sI2LCKZ for ; Sat, 14 Nov 2020 17:05:32 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 CF9543A0DD4 for ; Sat, 14 Nov 2020 17:05:31 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id l10so15493815lji.4 for ; Sat, 14 Nov 2020 17:05:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=HSmqSprO/ZurFpSnxOcgS3qNo0HVyvVSLCmvdxUongo=; b=jxBY0/tojXBQuNCt1ryKtIgxzELWrbxwkoFVwffA7G2VReaQ8Geve4ORsBsKBOAQwQ 8MVGeDidleDaCuKHh7x0dE9BBwRL3FEeWiePmMdK5tobuANel5MQTo5pT5RnuMkvnNmV +wseSkOPaLObjB9IA9vqAxMm0sf59Sh8He5u5cjp7qtFKuvgogRxmpJGjlPxJglf2yCa ao0+1fQeSzDWT9/cLvzAbst5n9uQ2+2s230q1ifG8GbUUVEa+0a5ShWr8WomhI7tG0lL niMd/cvMclylk2WLAg0BEux2hbW6cb9jGS4DfOX8ak89lR3DaEwu+PN2mL4r1GmFP67e lvfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=HSmqSprO/ZurFpSnxOcgS3qNo0HVyvVSLCmvdxUongo=; b=d6k1gBSEapCBb7qtZJZf6fqRfmYW5qsYbW/9+5tH4edVXOSUn8IIAZVB5cHLKSTsXS EzCvqPwMrjduQQGZbGLr1VBEwG6XBrza8Rh0UDiS8gY98Mr8WdTx6YCVdBAlohdEx4l4 g3dswwSN00eU3FEdMlhgqtfpHzAKiNEpC4Hy+zev3r0WL1sIIs2RGCsUSEHyX/rlAuK6 e/avofMxAJSftIiHo6shij5pBycWzSvtQZc7H3VbTq+Q+jrRSDugydrIT38YiovgQ7nj zg4+2hN13Ps9aBZnhva8o/Cs4fHYxc8RgJ21Euzz3JHPvzte1VOU92bWGrp287EdWiu+ bnyw== X-Gm-Message-State: AOAM530rPA0D4DptpQqhKZGzNZUSLRphzLj/QCPnKpTaZKB26Xjaxjb4 zKlMed8BdE6tfH1w7/SoTbwpCFib5Wg+VuOD4mW1a9HbFVDsqA== X-Google-Smtp-Source: ABdhPJzhlEP8G+m6SP9wrf+gwVWnES2VV6pRmHzI+8B5pkH//byrQgxbe8iH89UN6Ix4WULLLYlwqlvECmsAZ+wwg04= X-Received: by 2002:a05:651c:113b:: with SMTP id e27mr3397763ljo.17.1605402329919; Sat, 14 Nov 2020 17:05:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Sat, 14 Nov 2020 17:04:54 -0800 Message-ID: To: ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000098f7e005b41adb23" Archived-At: Subject: Re: [Add] Review of draft-pauly-add-deer-00.txt+ X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 01:05:34 -0000 --00000000000098f7e005b41adb23 Content-Type: text/plain; charset="UTF-8" On Sat, Nov 14, 2020 at 4:12 PM Eric Rescorla wrote: > Document: draft-pauly-add-deer-00.txt > > This seems overall like a fairly sensible mechanism if we > assume that HTTPSVC is viable for this purpose. We're working > on how to gather some data here and will hopefully have > something soon; would be great to hear what others have. > > Some comments below. > > S 2. > Equivalent Encrypted Resolver: An Encrypted Resolver which is > considered to provide answers equivalent to a given resolver. > This equivalency can be authenticated with TLS certificates. > > This has the same problem as with draft-box. If the attacker > stands up a resolver that proxies to the given resolver, it would > meet this definition, but would not provide confidentiality, > which is one of the prime motivators for this work. > > I know this kind of thing is difficult to formalize, but I think > we actually need to. There are two properties we need to capture > (1) that your data is only going to the EER (2) that the answers > are somehow similar. Perhaps. > > An Equivalent Encrypted Resolver is one in which (1) the client > receives equivalent answers to and (2) the attacker learns no more > information than if the client's queries/responses were delivered > directly to/from the given resolver without any access by the > attacker. > > Note that the definition of equivalent answers is still somewhat > problematic. Ideally we would like to say that the attacker cannot > influence the answers at all, but consider the case where the > EER is located in some different part of the network topology > then an attacker can influence your responses by sending you to > an EER or not. > Following up on this point. Consider the case where we have a Do53 resolver at 192.1.2.1 The ISP operates a DoT resolver at 192.1.2.2, so it would have the record: _dns.example.net 7200 IN SVCB 1 dot.example.net ( alpn=dot port=8530 ipv4hint=192.1.2.2 ) Now, if that DoT resolver provides different responses based on the client's apparent IP address, then an on-network attacker can serve their own record: _dns.example.net 7200 IN SVCB 1 dot.example.net ( alpn=dot port=8530 ipv4hint=203.1.113.1) Where the ipv4hint refers to something they control. They then proxy the TLS connection to the true DoT server. Because the SAN only needs to contain the Unencrypted Resolver address and *not* the Encrypted Resolver address, then this will succeed, with the result that the client gets different data than it would if the attacker had not been present. This raises several questions: 1. Do we think this is bad? 2. If the answer to (1) is yes, how do we redefine equivalence to cover it? 3. What does DEER need to do to stop it? [Off the top of my head, perhaps have the ER's address also be in the SAN field of the cert and check that] -Ekr --00000000000098f7e005b41adb23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Nov 14, 2020 at 4:12 PM Eric = Rescorla <ekr@rtfm.com= > wrote:
=
Document: draft-pauly-add-deer-00.txt

This seems ov= erall like a fairly sensible mechanism if we
assume that HTTPSVC is viab= le for this purpose. We're working
on how to gather some data here a= nd will hopefully have
something soon; would be great to hear what other= s have.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0
Some comments below.

S 2.
=C2=A0 =C2=A0Equivale= nt Encrypted Resolver: =C2=A0An Encrypted Resolver which is
=C2=A0 =C2= =A0 =C2=A0 considered to provide answers equivalent to a given resolver.=C2=A0 =C2=A0 =C2=A0 This equivalency can be authenticated with TLS certif= icates.

This has the same problem as with draft-box. If the attacker=
stands up a resolver that proxies to the given resolver, it would
me= et this definition, but would not provide confidentiality,
which is one = of the prime motivators for this work.

I know this kind of thing is = difficult to formalize, but I think
we actually need to. There are two p= roperties we need to capture
(1) that your data is only going to the EER= (2) that the answers
are somehow similar. Perhaps.

=C2=A0 =C2=A0= An Equivalent Encrypted Resolver is one in which (1) the client
=C2=A0 = =C2=A0receives equivalent answers to and (2) the attacker learns no more=C2=A0 =C2=A0information than if the client's queries/responses were d= elivered
=C2=A0 =C2=A0directly to/from the given resolver without any ac= cess by the
=C2=A0 =C2=A0attacker.

Note that the definition of eq= uivalent answers is still somewhat
problematic. Ideally we would like to= say that the attacker cannot
influence the answers at all, but consider= the case where the
EER is located in some different part of the network= topology
then an attacker can influence your responses by sending you t= o
an EER or not.

Following up = on this point. Consider the case where we have a Do53 resolver
at= 192.1.2.1 The ISP operates a DoT resolver at 192.1.2.2, so it would
<= div>have the record:

=C2=A0=C2=A0 _dns.example.net =C2=A07200 =C2=A0= IN SVCB 1 dot.example.= net (
=C2=A0 =C2=A0 =C2=A0 =C2=A0 alpn=3Ddot port=3D8530 ipv4hint=3D= 192.1.2.2 )

Now, if that DoT resolver provides dif= ferent responses based on the client's
apparent IP address, t= hen an on-network attacker can serve their own record:

=
=C2=A0=C2=A0 _dns= .example.net =C2=A07200 =C2=A0IN SVCB 1 dot.example.net (
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = alpn=3Ddot port=3D8530 ipv4hint=3D203.1.113.1)

Whe= re the ipv4hint refers to something they control. They then proxy the
=
TLS connection to the true DoT server. Because the SAN only needs to
contain the Unencrypted Resolver address and *not* the Encrypted R= esolver
address, then this will succeed, with the result that the= client gets different
data than it would if the attacker had not= been present. This raises several
questions:

1. Do we think this is bad?
2. If the answer to (1) is yes,= how do we redefine equivalence to cover it?
3. What does DEER ne= ed to do to stop it? [Off the top of my head,
=C2=A0=C2=A0= =C2=A0 perhaps have the ER's address also be in the SAN field of the ce= rt and
=C2=A0=C2=A0 check that]

-Ekr=
--00000000000098f7e005b41adb23-- From nobody Sat Nov 14 20:34:22 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D723A10EB for ; Sat, 14 Nov 2020 20:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 UX7tlbbzqvi5 for ; Sat, 14 Nov 2020 20:34:18 -0800 (PST) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 A9AC13A10E9 for ; Sat, 14 Nov 2020 20:34:18 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 0AF4XHXO004548; Sat, 14 Nov 2020 20:34:17 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=tsDh2x3aUOusQBDrlRM4LwtTDFknAJGd+sD3xbjOTBQ=; b=j2awJkYo6G/FfaIvegltncrZuC4tSFP4p7BhJK/fCUhCctdpteQiJMQ8bFq8LnH9yEF7 O07LRe5EJKvGqVL4XJkQdlqcNJFn0NyJqvWpysTyG3VQRtGTxdiVv2tT0Ro1kMd7JRdn 0qh6DrGdiHYI/VAYugR5LVoM2pMiGRI8zvhWdszPzOoyBrQSiB5edqVEPa/FxBUpcyaa wyjkaK6HFhK/g4XGsGEJbRXNL+B7wsj+uFxPj7Yj66HZ7sY9ssM2uD9nmi/6cu87rTUy +4Q1zadwtEupDp17y8+hL0Uh6IUFaxpMxXcyIbFTywSBpn8mZvTHX3bN0kPtr/EywUUM mw== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 34tes4xc1v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 14 Nov 2020 20:34:17 -0800 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QJT00F0XM1569A0@rn-mailsvcp-mta-lapp02.rno.apple.com>; Sat, 14 Nov 2020 20:34:17 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QJT00C00KK06D00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Sat, 14 Nov 2020 20:34:17 -0800 (PST) X-Va-A: X-Va-T-CD: 7a77f9138d60728e010dfb6f2118f5e7 X-Va-E-CD: 24f3ebbf8b788c1aab6bacb5c29f0af9 X-Va-R-CD: 1f0d918176e7f4f2fb174bea149a4773 X-Va-CD: 0 X-Va-ID: 5b09062d-3868-447f-8b99-f5900ba5f270 X-V-A: X-V-T-CD: 7a77f9138d60728e010dfb6f2118f5e7 X-V-E-CD: 24f3ebbf8b788c1aab6bacb5c29f0af9 X-V-R-CD: 1f0d918176e7f4f2fb174bea149a4773 X-V-CD: 0 X-V-ID: 8be9f626-66a6-41d1-b4f1-e8a6a739ecd7 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-15_01:2020-11-13, 2020-11-15 signatures=0 Received: from localhost.localdomain (unknown [17.232.204.125]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QJT00S64M11RR00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Sat, 14 Nov 2020 20:34:16 -0800 (PST) From: Tommy Pauly Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_86124F39-00A1-4305-8655-20B9FDDD369D" MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\)) Date: Sat, 14 Nov 2020 20:34:13 -0800 In-reply-to: Cc: ADD Mailing list To: Eric Rescorla References: X-Mailer: Apple Mail (2.3654.0.3.2.26) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-15_01:2020-11-13, 2020-11-15 signatures=0 Archived-At: Subject: Re: [Add] Review of draft-pauly-add-deer-00.txt+ X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 04:34:21 -0000 --Apple-Mail=_86124F39-00A1-4305-8655-20B9FDDD369D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ekr, Thanks for the review! Some initial responses inline. > On Nov 14, 2020, at 5:04 PM, Eric Rescorla > wrote: >=20 >=20 >=20 > On Sat, Nov 14, 2020 at 4:12 PM Eric Rescorla > wrote: > Document: draft-pauly-add-deer-00.txt >=20 > This seems overall like a fairly sensible mechanism if we > assume that HTTPSVC is viable for this purpose. We're working > on how to gather some data here and will hopefully have > something soon; would be great to hear what others have. Happy to hear how your SVCB measurements look. Now that iOS and macOS = are sending out HTTPS SVCB queries on all DNS queries for HTTP sites, = we=E2=80=99ve been able to get some more data at scale. Worldwide, I=E2=80=99m seeing that 1.53% of domains are currently = getting SVCB responses=E2=80=94that=E2=80=99s largely because the record = type is quite new, and mainly only Cloudflare has been adding the = records. A rate of 1-2% of domains seems quite consistent across = different network providers and geographic regions. There are a few = networks that seem to be filtering the responses (they get 0%), but = these seem to be exceptional. Importantly, we aren't seeing functional breakage due to sending the = queries. > =20 > Some comments below. >=20 > S 2. > Equivalent Encrypted Resolver: An Encrypted Resolver which is > considered to provide answers equivalent to a given resolver. > This equivalency can be authenticated with TLS certificates. >=20 > This has the same problem as with draft-box. If the attacker > stands up a resolver that proxies to the given resolver, it would > meet this definition, but would not provide confidentiality, > which is one of the prime motivators for this work. >=20 > I know this kind of thing is difficult to formalize, but I think > we actually need to. There are two properties we need to capture > (1) that your data is only going to the EER (2) that the answers > are somehow similar. The definition here is indeed similar to the one in the requirements = draft, and I agree that both definitions of equivalency ought to be = formalized to be more clear about these kinds of attacks. A scenario where the attacker is able to intercept all the DNS messages = should indeed not be deemed equivalent. > Perhaps. >=20 > An Equivalent Encrypted Resolver is one in which (1) the client > receives equivalent answers to and (2) the attacker learns no more > information than if the client's queries/responses were delivered > directly to/from the given resolver without any access by the > attacker. >=20 > Note that the definition of equivalent answers is still somewhat > problematic. Ideally we would like to say that the attacker cannot > influence the answers at all, but consider the case where the > EER is located in some different part of the network topology > then an attacker can influence your responses by sending you to > an EER or not. >=20 > Following up on this point. Consider the case where we have a Do53 = resolver > at 192.1.2.1 The ISP operates a DoT resolver at 192.1.2.2, so it would > have the record: >=20 > _dns.example.net 7200 IN SVCB 1 = dot.example.net ( > alpn=3Ddot port=3D8530 ipv4hint=3D192.1.2.2 ) >=20 > Now, if that DoT resolver provides different responses based on the = client's > apparent IP address, then an on-network attacker can serve their own = record: >=20 > _dns.example.net 7200 IN SVCB 1 = dot.example.net ( > alpn=3Ddot port=3D8530 ipv4hint=3D203.1.113.1) >=20 > Where the ipv4hint refers to something they control. They then proxy = the > TLS connection to the true DoT server. Because the SAN only needs to > contain the Unencrypted Resolver address and *not* the Encrypted = Resolver > address, then this will succeed, with the result that the client gets = different > data than it would if the attacker had not been present. This raises = several > questions: >=20 > 1. Do we think this is bad? > 2. If the answer to (1) is yes, how do we redefine equivalence to = cover it? > 3. What does DEER need to do to stop it? [Off the top of my head,=20 > perhaps have the ER's address also be in the SAN field of the cert = and > check that] Thanks for bringing up this point. Our initial version of the DEER draft did require that the certificate = cover both the original Do53 resolver=E2=80=99s IP address and the = EER=E2=80=99s IP address. However, we were having trouble articulating = the scenario that required including the EER=E2=80=99s IP address. (One = thing to note for this list is that if the Do53 and EER are both on the = same IP address, this is already covered). Specifically, we did consider that it would be possible for an attacker = to proxy TCP connections to a TLS-protected EER, but that alone didn't = allow the attacker to observe or directly modify the DNS messages. If = that is the extent of the attack (being a transparent TCP proxy), I = think we can argue that this might not be bad. The point you bring up here that we didn=E2=80=99t consider was the fact = that such a proxy would be changing the client IP address that the EER = would observe, and thus might change the actual DNS answers if they are = based on the client IP address or client subnet. I think the main question is if the definition of using an equivalent = resolver means that the DNS answers need to take the same client IP = address into account. This may be good to discuss in the WG meeting. Thanks, Tommy >=20 > -Ekr > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add = --Apple-Mail=_86124F39-00A1-4305-8655-20B9FDDD369D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Ekr,

Thanks for the review! = Some initial responses inline.

On Nov = 14, 2020, at 5:04 PM, Eric Rescorla <ekr@rtfm.com> wrote:



On Sat, Nov = 14, 2020 at 4:12 PM Eric Rescorla <ekr@rtfm.com> wrote:
Document: draft-pauly-add-deer-00.txt

This seems overall like a fairly sensible = mechanism if we
assume that HTTPSVC is viable for this = purpose. We're working
on how to gather some data here and = will hopefully have
something soon; would be great to hear = what others have.

Happy to hear how your = SVCB measurements look. Now that iOS and macOS are sending out HTTPS = SVCB queries on all DNS queries for HTTP sites, we=E2=80=99ve been able = to get some more data at scale.

Worldwide, I=E2=80=99m seeing that = 1.53% of domains are currently getting SVCB responses=E2=80=94that=E2=80=99= s largely because the record type is quite new, and mainly only = Cloudflare has been adding the records. A rate of 1-2% of domains seems = quite consistent across different network providers and geographic = regions. There are a few networks that seem to be filtering the = responses (they get 0%), but these seem to be exceptional.

Importantly, we aren't = seeing functional breakage due to sending the queries.

 =                   =   
Some comments below.

S 2.
   Equivalent Encrypted Resolver:  An = Encrypted Resolver which is
      considered to provide = answers equivalent to a given resolver.
    =   This = equivalency can be authenticated with TLS certificates.

This has the same problem as with draft-box. If the = attacker
stands up a resolver that proxies to the given = resolver, it would
meet this definition, but would not = provide confidentiality,
which is one of the prime = motivators for this work.

I know this kind = of thing is difficult to formalize, but I think
we = actually need to. There are two properties we need to capture
(1) that your data is only going to the EER (2) that the = answers
are somehow = similar.

The definition here is = indeed similar to the one in the requirements draft, and I agree that = both definitions of equivalency ought to be formalized to be more clear = about these kinds of attacks.

A scenario where the attacker is able = to intercept all the DNS messages should indeed not be deemed = equivalent.

Perhaps.

   An = Equivalent Encrypted Resolver is one in which (1) the client
   receives equivalent answers to and (2) the = attacker learns no more
   information than if = the client's queries/responses were delivered
  =  directly to/from the given resolver without any access by the
   attacker.

Note that = the definition of equivalent answers is still somewhat
problematic. Ideally we would like to say that the attacker = cannot
influence the answers at all, but consider the case = where the
EER is located in some different part of the = network topology
then an attacker can influence your = responses by sending you to
an EER or not.

Following up on this point. Consider the case where we have a = Do53 resolver
at 192.1.2.1 The ISP operates a DoT = resolver at 192.1.2.2, so it would
have the = record:

   _dns.example.net  7200  IN SVCB = 1 dot.example.net (
  =       alpn=3Ddot port=3D8530 ipv4hint=3D192.1.2.2 = )

Now, if that = DoT resolver provides different responses based on the = client's
apparent IP address, then an on-network = attacker can serve their own record:

   _dns.example.net  7200  IN SVCB = 1 dot.example.net (
  =       alpn=3Ddot port=3D8530 = ipv4hint=3D203.1.113.1)

Where the ipv4hint refers to something they control. They = then proxy the
TLS connection to the true DoT = server. Because the SAN only needs to
contain the = Unencrypted Resolver address and *not* the Encrypted Resolver
address, then this will succeed, with the result that the = client gets different
data than it would if the = attacker had not been present. This raises several
questions:

1. Do we think this is bad?
2. If the = answer to (1) is yes, how do we redefine equivalence to cover = it?
3. What does DEER need to do to stop it? [Off = the top of my head, 
    perhaps have the = ER's address also be in the SAN field of the cert and
   check that]

Thanks for bringing up this = point.

Our = initial version of the DEER draft did require that the certificate cover = both the original Do53 resolver=E2=80=99s IP address = and the EER=E2=80=99s IP address. However, we were having trouble = articulating the scenario that required including the EER=E2=80=99s IP = address. (One thing to note for this list is that if the Do53 and EER = are both on the same IP address, this is already covered).

Specifically, we did = consider that it would be possible for an attacker to proxy TCP = connections to a TLS-protected EER, but that alone didn't allow the = attacker to observe or directly modify the DNS messages. If that is the = extent of the attack (being a transparent TCP proxy), I think we can = argue that this might not be bad.

The point you bring up here that we = didn=E2=80=99t consider was the fact that such a proxy would be changing = the client IP address that the EER would observe, and thus might change = the actual DNS answers if they are based on the client IP address or = client subnet.

I= think the main question is if the definition of using an equivalent = resolver means that the DNS answers need to take the same client IP = address into account. This may be good to discuss in the WG = meeting.

Thanks,
Tommy


-Ekr
-- 
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add

= --Apple-Mail=_86124F39-00A1-4305-8655-20B9FDDD369D-- From nobody Sat Nov 14 23:41:28 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E8C3A0A08 for ; Sat, 14 Nov 2020 23:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=PJBeQp9T; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jw7MhR3s 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 Bzq5AFJtJ6BH for ; Sat, 14 Nov 2020 23:41:14 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7210A3A0A35 for ; Sat, 14 Nov 2020 23:41:01 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id C829AA03 for ; Sun, 15 Nov 2020 02:32:48 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 15 Nov 2020 02:32:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=HGOQM9pz971shntFBHQySTQlzl0qPqcyyntLJCTA7JQ=; b=PJBeQp9T WT18HGMa5qCSMz7Wm3Sub6woWpo2/t61LEWkPPhk8m8N2lFfaSXkYIu/2h5aIggs uHnyjX6B2Wpzw7ybgnZk7v+Cgn2ljGQnPlrxIRlKAdrwHix4KdTQqyoOwZoeKOoA YPCuw4yIW/Mz1oU8QYTuu+ehmE387q2UPL6pzLed8d8YsdfiPylPDbDkhMai+dda jrxAviqTzVhc14vt0GFR0NljPAnSAv4PRi4AP63JdHPa8al1n118sjuc+vOKwNBw PMvOUcHR6oxDL9oJuUuaJOAwmDLYKEpY4bsQV6AIj37vX2AjGI24bjLNsgR81VNi B/qbDOD1kqAtKQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=HGOQM9pz971shntFBHQySTQlzl0qP qcyyntLJCTA7JQ=; b=jw7MhR3sf9UkE6AcInLGuS0iO/wpiyGVCkk4W24FLMpf+ LWltrV1q38Ok7Go0yefQDic9onPP4BwkAxbNXreMkJRREGGMoXXDPAZJDswVpAmR hvY1FciMfnKWK7zOoE5HLTGUWjtjjeASTncM0LrWUkqliudyOUGmIJTT9GVFYzzt BRqe9dYz8wh9jC0R9cwTaCNIYtXObJRICe68jpKUcR3cm5l0fH/9YUrw7g2+QuKs OkhrxW9JdPfXcSKLV0tf3fqDPfh+nFf7SUaiFuMMobgo6nD9Z7PDltw/MQoWDIKf Za/Moj0ocdkge/SIsE19zG3GWUbBoKT1GlGWbBA5g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddvkedguddtkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppedutdegrddvtdelrddufe elrdduheejnecuvehluhhsthgvrhfuihiivgepgeenucfrrghrrghmpehmrghilhhfrhho mhepughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az60-705.internal.cloudapp.net (unknown [104.209.139.157]) by mail.messagingengine.com (Postfix) with ESMTPA id 4C0323280059 for ; Sun, 15 Nov 2020 02:32:48 -0500 (EST) Content-Type: multipart/alternative; boundary="===============1386826837849499426==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: add@ietf.org Message-Id: <20201115073248.4C0323280059@mailuser.nyi.internal> Date: Sun, 15 Nov 2020 02:32:48 -0500 (EST) Archived-At: Subject: [Add] Weekly github digest (ADD Activity Summary) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 07:41:18 -0000 --===============1386826837849499426== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * ietf-wg-add/draft-add-requirements (+1/-7/=F0=9F=92=AC8) 1 issues created: - Limit encrypted DNS protocols to those defined by IETF (by chris-box) https://github.com/ietf-wg-add/draft-add-requirements/issues/32 [design= ]=20 8 issues received 8 new comments: - #30 Section 5: Clarification (1 by chris-box) https://github.com/ietf-wg-add/draft-add-requirements/issues/30=20 - #29 Section 3.2: Add to Requirements (1 by chris-box) https://github.com/ietf-wg-add/draft-add-requirements/issues/29=20 - #28 Section 3.2: Add to listed benefits (1 by chris-box) https://github.com/ietf-wg-add/draft-add-requirements/issues/28=20 - #27 Section 2. Terminology: add definition to terms (1 by chris-box) https://github.com/ietf-wg-add/draft-add-requirements/issues/27=20 - #26 This should really be two documents (1 by chris-box) https://github.com/ietf-wg-add/draft-add-requirements/issues/26=20 - #25 VPNs can also use DNS for routing decisions (section 3.3) (1 by chr= is-box) https://github.com/ietf-wg-add/draft-add-requirements/issues/25=20 - #24 Usefulness of limited domains (1 by chris-box) https://github.com/ietf-wg-add/draft-add-requirements/issues/24=20 - #23 VPN requirements reduce to nothing (1 by chris-box) https://github.com/ietf-wg-add/draft-add-requirements/issues/23=20 7 issues closed: - Setup weekly-digest mailer https://github.com/ietf-wg-add/draft-add-re= quirements/issues/1 [repository]=20 - Section 3.2: Add to Requirements https://github.com/ietf-wg-add/draft-a= dd-requirements/issues/29=20 - Section 2. Terminology: add definition to terms https://github.com/ietf= -wg-add/draft-add-requirements/issues/27=20 - This should really be two documents https://github.com/ietf-wg-add/draf= t-add-requirements/issues/26=20 - VPNs can also use DNS for routing decisions (section 3.3) https://githu= b.com/ietf-wg-add/draft-add-requirements/issues/25=20 - Usefulness of limited domains https://github.com/ietf-wg-add/draft-add-= requirements/issues/24=20 - VPN requirements reduce to nothing https://github.com/ietf-wg-add/draft= -add-requirements/issues/23=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-add/draft-add-requirements * https://github.com/ietf-wg-add/wg-materials --===============1386826837849499426== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (ADD Activity Summary)

Sunday November 15, 2020

Events without label "editorial"

Issues

ietf-wg-add/draft-add-requirements (+1/-7/=F0=9F=92=AC8)

1 issues created:

8 issues received 8 new comments:

7 issues closed:

Repositories tracked by this digest:

--===============1386826837849499426==-- From nobody Sun Nov 15 11:04:42 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C183A097F for ; Sun, 15 Nov 2020 11:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 dJVRfwRjMI3i for ; Sun, 15 Nov 2020 11:04:39 -0800 (PST) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 E82343A097A for ; Sun, 15 Nov 2020 11:04:38 -0800 (PST) Received: by mail-qt1-x833.google.com with SMTP id m65so11112546qte.11 for ; Sun, 15 Nov 2020 11:04:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=olLAAvOOZ7qX2xyn4n4Ia8FBhkcX08ZlaJSa5hVNUmY=; b=vfPT2pF/dAqldHKTWYenZG8RGLxNP0Z1Fh+lAIWGsvLTqDhj2CtTKd/hCP/VumWzWu RW2cu9PqdfcNoZ0ky2gG7IR92R8m0AHiL1INZwhWM9XKferXs/mUpC/wa8JP6WG6AkSa 2YNIfieBxcOp6mBBKCxwPrkv3PcDwa8vhjb2D6/G5ABAEJPvawRexcpQHyKQaJlbNQ9G 32UYDx+GausqMYRTGyvcg7UfoPNdNF5dKUOBJNBXr8rrr93oFVtQZK/eQhKu9261Ugeg r2zJcnhKeWr6ESe+fygv1B4DQUGFElHVBcFsRdLMHpMuRhDuxUnVHC6KLya6kzEOmNO/ 98OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=olLAAvOOZ7qX2xyn4n4Ia8FBhkcX08ZlaJSa5hVNUmY=; b=DeiJFhbDfDkaOjZItcz903+unkwKqFZv8iA704RXkN9OrCBuBUSPe63xdL+I8fipVH NcZQajueItFEygUzJx5pCpRzI2J08lo5CAuw1AhJhCtAh1qND75FbDkT6MVF7pzUMThp 0030ExOUxOC4eQgJL78jJmxAsY9wkiHD5Yv/dfUnukENsjMLCm/eR6G3/zUJkeB4qewh nm7uUa3NGe50eKrusTgIF77mtTZOaxFwgPzMPd6sW0W5H1/OLy3on4sdni42UsVuna7N k9lmpKNhdMSM+Wk3sQomPNaLir7+o/YYUa8RavbdsWbOvWwA9asUHOZY8bI3b/4Nc7+T +4rA== X-Gm-Message-State: AOAM53156wpmrszi3xTNs51E1zqxBmlTlzkinfrf+25dyFTTmjHakw5v 6HR8UoweigNFUNuLdBN3R3DmZHPZywvEx184WVW4jJDl X-Google-Smtp-Source: ABdhPJzSkjgx8qj9mhz3kG6OsZAV4+ViIaTjL/KrnuKcyUMUi4McT/W7ebj1cAYYhaq1BsSPMwIavjmltGWohQGGtL8= X-Received: by 2002:aed:31c5:: with SMTP id 63mr11416225qth.367.1605467077862; Sun, 15 Nov 2020 11:04:37 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Chris Box Date: Sun, 15 Nov 2020 19:04:26 +0000 Message-ID: To: Eric Rescorla Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000dfe6cc05b429ee3d" Archived-At: Subject: Re: [Add] Review of draft-box-add-requirements-01.txt X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 19:04:41 -0000 --000000000000dfe6cc05b429ee3d Content-Type: text/plain; charset="UTF-8" Ekr, Thanks for the review. Some quick answers to your points below. On Sat, 14 Nov 2020 at 23:50, Eric Rescorla wrote: > I understand what you're trying to do here, > but I think what you need to say is something quite different: > > The objective of this use case is simply to replace Do53 with > an encrypted DNS protocol to the same resolver. Note that > the network's recommended unencrypted resolver may have a number of > properties that differ from a generic resolver. It may be able to > answer names that are not known globally, it may exclude some names > (for positive or negative reasons), and it may provide address > answers that have improved proximity. The user may or may not > desire these properties and may or may not be aware of them, > but for the purposes of this use case, we are not attempting > to change these properties, but merely to provide the user > with encrypted transport. > Your wording, especially the last half, is a substantial improvement. I'll look to merge this. In the first sentence I'd like to modify "to the same resolver", since we are only trying to reach an equivalent resolver, and it may be physically separate from the Do53 so I wouldn't consider them "same". > > in many cases there is real uncertainty about which network is being > joined. The most obvious case is coffee shop networks, hotspots, > etc. in which the user may think they are joining the network > associated with a given establishment (say Starbucks) but they are in > fact joining the attacker's network. While it may be the case that > they are legitimately upgraded to the attacker's Do[HTQ] server, I > don't think you can call this "authenticating that the DNS resolver is > the correct one". > Agree on the uncertainty, but not yet sure what the right wording is here. > > S 3.1. > Given two resolvers A and B, equivalence is the claim that A and B > can provide the same upper-layer DNS function to the client. This > does not include the DNS transport protocol (e.g. Do53 or DNS-over- > HTTPS) which can differ between equivalent resolvers. To provide > equivalence it is frequently likely to be the case that A and B are > operated by the same administrative domain, but this document does > not require that. > > This doesn't seem right. [Discussion of B being an attacker that offers > the same DNS responses but also shares communications] > Again, not sure what kind of different/stronger definition would remove this risk. Perhaps it can be explored in the meeting tomorrow. > * The local network can claim that one or more encrypted DNS > resolvers (B, C, etc) are equivalent to the Do53 resolver (A) it > has offered. This is known as network-identified. > > * During communication with the (often unencrypted) resolver (A), > this resolver can claim that one or more encrypted DNS resolvers > (B, C, etc) are equivalent. This is known as resolver-identified. > > These seem like two options, but they're not the only one. For instance, > neither of these covers the preconfigured SPAU lists that Chrome and > Edge use. > Yes, preconfigured lists could be another way to claim equivalence. But are they useful in the context of ADD which is all about automatic discovery? > > Network-identified is preferred since it comes from the same source > of information, and removes the need to talk to the Do53 resolver at > all. However it cannot be the sole mechanism, at least for several > years, since there is a large installed base of local network > equipment that is difficult to upgrade with new features. Hence the > second mechanism must support being able to announce an equivalent > resolver using only existing widely-deployed DNS features. > > I'd prefer this document not to take a position on what technical > approach is preferred at this time. > Agree - you're not the first to point this out and it will be removed. > > S 5. > The way that this section is written implies that it is preferable > to have encrypted transport terminated at the local resolver rather > than at some central caching resolver. While I agree that this has > certain benefits, it also has a number of operational drawbacks > (for instance, these local access points/routers are often quite > insecure). This section should be adjusted to be more neutral. > > Agree. Central can be better. > > S 6. > * Cause clients to use a discovered resolver which has no > authenticated delegation from a client-known entity. > > It's not clear to me what this means. As read literally, why > doesn't it rule out basically all of the versions where > the client receives some unauthenticated Do53 message that > says "DoT at this same address"? > I'll need to think about this some more. > > > S 7. > | R1.1 | Discovery MUST provide a local network the | > | | ability to announce to clients a set of, or | > | | absence of, equivalent resolvers. | > > I don't agree that this is a requirement. See my comments about S 3.1. > above. > I think you're saying that network-identified is not mandatory, and may not feature at all in the solution? > > > | R1.3 | Discovery MUST support at least one encrypted | > | | DNS protocol. | > +-------------+-------------------------------------------------+ > | R1.4 | Discovery SHOULD support all standardised | > | | encrypted DNS protocols. | > > I don't understand these. Are you saying it's not a requirement to > be able to indicate all the standardized protocols? That seems like > it would be a fail. > I'm saying it needs the ability to point users to DoT resolvers and DoH resolvers. If it couldn't do one of those it would be less desirable. If DoQ is published as an RFC, it would be useful for the ADD discovery protocol to support DoQ too. This is *not *the same as having reserved bits for each transport protocol, as draft-btw-add-home-10 does. | R2.2 | The format for resolver information MUST be | > | | specified such that provisioning mechanisms | > | | defined outside of the IETF can advertise | > | | encrypted DNS resolvers. | > > At most a SHOULD > Agree. > > | R5.2 | Threat modelling MUST assume that there is a | > | | passive eavesdropping attacker on the local | > | | network. | > +-------------+-------------------------------------------------+ > | R5.3 | Threat modelling MUST assume that an attacker | > | | can actively attack from outside the local | > | | network. | > > Normally one wouldn't call these requirements. > Are you proposing they are deleted? Chris --000000000000dfe6cc05b429ee3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Ekr,

<= div>Thanks for the review. Some quick answers to your points below.

On Sat, 14 Nov 2020 at 23:50, Eric Rescorla <ekr@rtfm.com> wrote:
=C2=A0
I understan= d what you're trying to do here,
but I think what you need to say is= something quite different:

=C2=A0 =C2=A0The objective of this use c= ase is simply to replace Do53 with
=C2=A0 =C2=A0an encrypted DNS protoco= l to the same resolver. Note that
=C2=A0 =C2=A0the network's recomme= nded unencrypted resolver may have a number of
=C2=A0 =C2=A0properties t= hat differ from a generic resolver.=C2=A0 It may be able to
=C2=A0 =C2= =A0answer names that are not known globally, it may exclude some names
= =C2=A0 =C2=A0(for positive or negative reasons), and it may provide address=
=C2=A0 =C2=A0answers that have improved proximity. The user may or may = not
=C2=A0 =C2=A0desire these properties and may or may not be aware of = them,
=C2=A0 =C2=A0but for the purposes of this use case, we are not att= empting
=C2=A0 =C2=A0to change these properties, but merely to provide t= he user
=C2=A0 =C2=A0with encrypted transport.

Your wording, especially the last half, is a substantial i= mprovement. I'll look to merge this. In the first sentence I'd like= to modify "to the same resolver", since we are only trying to re= ach an equivalent resolver, and it may be physically separate from the Do53= so I wouldn't consider them "same".

=C2=A0

in many cases there is real uncertainty abo= ut which network is being
joined. The most obvious case is coffee shop n= etworks, hotspots,
etc. in which the user may think they are joining the= network
associated with a given establishment (say Starbucks) but they = are in
fact joining the attacker's network. While it may be the case= that
they are legitimately upgraded to the attacker's Do[HTQ] serve= r, I
don't think you can call this "authenticating that the DNS= resolver is
the correct one".

Agree on the uncertainty, but not yet sure what the right wording is = here.
=C2=A0

S 3.1.
=C2=A0 =C2=A0Given two resolvers A an= d B, equivalence is the claim that A and B
=C2=A0 =C2=A0can provide the = same upper-layer DNS function to the client.=C2=A0 This
=C2=A0 =C2=A0doe= s not include the DNS transport protocol (e.g.=C2=A0 Do53 or DNS-over-
= =C2=A0 =C2=A0HTTPS) which can differ between equivalent resolvers.=C2=A0 To= provide
=C2=A0 =C2=A0equivalence it is frequently likely to be the case= that A and B are
=C2=A0 =C2=A0operated by the same administrative domai= n, but this document does
=C2=A0 =C2=A0not require that.

This doe= sn't seem right. [Discussion of B being an attacker that offers the sam= e DNS responses but also shares communications]
=
Again, not sure what kind of different/stronger definition w= ould remove this risk. Perhaps it can be explored in the meeting tomorrow.<= /div>



=C2=A0=C2=A0 * =C2=A0The local network can = claim that one or more encrypted DNS
=C2=A0 =C2=A0 =C2=A0 resolvers (B, = C, etc) are equivalent to the Do53 resolver (A) it
=C2=A0 =C2=A0 =C2=A0 = has offered.=C2=A0 This is known as network-identified.

=C2=A0 =C2= =A0* =C2=A0During communication with the (often unencrypted) resolver (A),<= br>=C2=A0 =C2=A0 =C2=A0 this resolver can claim that one or more encrypted = DNS resolvers
=C2=A0 =C2=A0 =C2=A0 (B, C, etc) are equivalent.=C2=A0 Thi= s is known as resolver-identified.

These seem like two options, but = they're not the only one. For instance,
neither of these covers the = preconfigured SPAU lists that Chrome and
Edge use.

Yes, preconfigured lists could be another way to claim= equivalence. But are they useful in the context of ADD which is all about = automatic discovery?
=C2=A0

=C2=A0 =C2=A0Network-= identified is preferred since it comes from the same source
=C2=A0 =C2= =A0of information, and removes the need to talk to the Do53 resolver at
= =C2=A0 =C2=A0all.=C2=A0 However it cannot be the sole mechanism, at least f= or several
=C2=A0 =C2=A0years, since there is a large installed base of = local network
=C2=A0 =C2=A0equipment that is difficult to upgrade with n= ew features.=C2=A0 Hence the
=C2=A0 =C2=A0second mechanism must support = being able to announce an equivalent
=C2=A0 =C2=A0resolver using only ex= isting widely-deployed DNS features.

I'd prefer this document no= t to take a position on what technical
approach is preferred at this tim= e.

Agree - you're not the first t= o point this out and it will be removed.
=C2=A0

S 5.
The = way that this section is written implies that it is preferable
to have e= ncrypted transport terminated at the local resolver rather
than at some = central caching resolver. While I agree that this has
certain benefits, = it also has a number of operational drawbacks
(for instance, these local= access points/routers are often quite
insecure). This section should be= adjusted to be more neutral.


Agree. Central can be better.
=C2=A0

S 6.
=C2=A0 =C2=A0= * =C2=A0Cause clients to use a discovered resolver which has no
=C2=A0 = =C2=A0 =C2=A0 authenticated delegation from a client-known entity.

I= t's not clear to me what this means. As read literally, why
doesn= 9;t it rule out basically all of the versions where
the client receives = some unauthenticated Do53 message that
says "DoT at this same addre= ss"?

I'll need to think = about this some more.
=C2=A0


S 7.
=C2=A0 =C2=A0 =C2= =A0| R1.1 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Discovery MUST provide a local netwo= rk the =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | ability to announce to clients a set of, or =C2=A0 = =C2=A0 |
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | absence of, equivalent resolvers. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |

I don't agree that this is a requirement. See my co= mments about S 3.1.
above.

I t= hink you're saying that network-identified is not mandatory, and may no= t feature at all in the solution?
=C2=A0


=C2=A0 =C2=A0 = =C2=A0| R1.3 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Discovery MUST support at least o= ne encrypted =C2=A0 |
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | DNS protocol. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=
=C2=A0 =C2=A0 =C2=A0+-------------+------------------------------------= -------------+
=C2=A0 =C2=A0 =C2=A0| R1.4 =C2=A0 =C2=A0 =C2=A0 =C2=A0| D= iscovery SHOULD support all standardised =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 = =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | encrypted DNS pr= otocols. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|

I don't understand these. Are you saying it&#= 39;s not a requirement to
be able to indicate all the standardized proto= cols? That seems like
it would be a fail.
I'm saying it needs the ability to point users to DoT resol= vers and DoH resolvers. If it couldn't do one of those it would be less= desirable. If DoQ is published as an RFC, it would be useful for the ADD d= iscovery protocol to support DoQ too. This is not the same as having= reserved bits for each transport protocol, as draft-btw-add-home-10 does.<= /div>
=C2=A0

=C2=A0 =C2=A0 =C2=A0| R2.2 =C2=A0 =C2=A0 =C2=A0 =C2=A0| The form= at for resolver information MUST be =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0= | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | specified such that provision= ing mechanisms =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | defined outside of the IETF can advertise =C2=A0= =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | encrypted DNS resolvers. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

At most a SHOULD

Agree.
=C2=A0

=C2=A0 =C2=A0 =C2=A0| R5.2 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| Threat modelling MUST assume that there is a = =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | passive eavesdropping attacker on the local =C2=A0 =C2=A0 |
=C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | network. =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 = =C2=A0 =C2=A0+-------------+-----------------------------------------------= --+
=C2=A0 =C2=A0 =C2=A0| R5.3 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Threat model= ling MUST assume that an attacker =C2=A0 |
=C2=A0 =C2=A0 =C2=A0| =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | can actively attack from outside the l= ocal =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | network. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|

Normally one wouldn't call these requi= rements.

Are you proposing they are del= eted?

Chris
--000000000000dfe6cc05b429ee3d-- From nobody Sun Nov 15 11:45:27 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5CA3A0896 for ; Sun, 15 Nov 2020 11:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 J81-PiWW9zxE for ; Sun, 15 Nov 2020 11:45:25 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 66AED3A0880 for ; Sun, 15 Nov 2020 11:45:25 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id v20so17495208ljk.8 for ; Sun, 15 Nov 2020 11:45:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=44PIYMo9aiqS6njOd7/G6ke31MFqDLyZoPid0wTAIfk=; b=Xf0qbfzKnZrmt3assmEOP5cNqt2nuJE3EXkZqtjTDaXMShCQqI3HfrWmhBRPKWxiIj QEfR1NBRp1iUQxl8MeBuiOL+X4604K0QtusKqsTZM9IzlRwJw9bL+z+IQ6dg8ta83nhc QQN8f6QYQu0851FmGUtFP1XRd8kzKbNDAmqklzvVx6i/87g5rW5OXozcrGQPro6KAJLs bqGjU234K2Od9fahOvlCvCxlIZfxT/TL7jz6Ms6TphcSjG9dLL5b1sgOm6iEHmgcfbJh K0+NOdBLk0SzROuGHrpC9Pl8bocmnIfyXdbrsCOg6gSvSm2Ogkp0Km7J5G/Vd4x7mbgZ qOCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=44PIYMo9aiqS6njOd7/G6ke31MFqDLyZoPid0wTAIfk=; b=d3ALsvu2pXxa4q0P/6GPNADxhVOCdnRWt2K8ChR5jhnKPQDlq3VpkK+JBEVUT495go fzkPeLW2D4r7rOP99XAeWHizhy+OK9WS1bkRSvrr9rlomZSsndc7lSPSvIpAteZGLxNp iIyAvRzLj1mFpyLgk4ZtSvIsUHm7txpvCdewzxARxOFF3bgJB064dqGPL9QcR4WxIpoB Wpu33Wo1tz6VtqNorc/Ea+UPdz3d0b1lD1eWAWbnFKw6mitvPZ2JmrwN+LvdjZBXpdJI ZgVkjBno5MiW8oPJP+WSPrkHxjfMnbRQq332NWKi05FM9Aml1a9gKYuPB5IrEXxOX/lA 0c4g== X-Gm-Message-State: AOAM532dbnjCbsay7lztzZeqlQNWFhjTx3VooEhz9fE7NmUSP5RHiiGr sBhjmwCOxZZoA1iCx6KgwAFuQoaz0A5NkhbXJggYgw== X-Google-Smtp-Source: ABdhPJyIK/lcd1GEFFbUgBX4iiaQ552eVYX6b2k23rvjpu8lVHrvLz17Z2nZmcQ+DUjsKXUf69Z+6muOlkTEjtJl7hk= X-Received: by 2002:a05:651c:113b:: with SMTP id e27mr4571809ljo.17.1605469523628; Sun, 15 Nov 2020 11:45:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Sun, 15 Nov 2020 11:44:47 -0800 Message-ID: To: Chris Box Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000a76a9a05b42a80fb" Archived-At: Subject: Re: [Add] Review of draft-box-add-requirements-01.txt X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 19:45:27 -0000 --000000000000a76a9a05b42a80fb Content-Type: text/plain; charset="UTF-8" On Sun, Nov 15, 2020 at 11:04 AM Chris Box wrote: > > Ekr, > > Thanks for the review. Some quick answers to your points below. > > On Sat, 14 Nov 2020 at 23:50, Eric Rescorla wrote: > > >> I understand what you're trying to do here, >> but I think what you need to say is something quite different: >> >> The objective of this use case is simply to replace Do53 with >> an encrypted DNS protocol to the same resolver. Note that >> the network's recommended unencrypted resolver may have a number of >> properties that differ from a generic resolver. It may be able to >> answer names that are not known globally, it may exclude some names >> (for positive or negative reasons), and it may provide address >> answers that have improved proximity. The user may or may not >> desire these properties and may or may not be aware of them, >> but for the purposes of this use case, we are not attempting >> to change these properties, but merely to provide the user >> with encrypted transport. >> > > Your wording, especially the last half, is a substantial improvement. I'll > look to merge this. In the first sentence I'd like to modify "to the same > resolver", since we are only trying to reach an equivalent resolver, and it > may be physically separate from the Do53 so I wouldn't consider them "same". > Agreed. > > >> >> in many cases there is real uncertainty about which network is being >> joined. The most obvious case is coffee shop networks, hotspots, >> etc. in which the user may think they are joining the network >> associated with a given establishment (say Starbucks) but they are in >> fact joining the attacker's network. While it may be the case that >> they are legitimately upgraded to the attacker's Do[HTQ] server, I >> don't think you can call this "authenticating that the DNS resolver is >> the correct one". >> > > Agree on the uncertainty, but not yet sure what the right wording is here. > Yeah, I think the whole thing just needs to be a lot more nuanced. > > >> >> S 3.1. >> Given two resolvers A and B, equivalence is the claim that A and B >> can provide the same upper-layer DNS function to the client. This >> does not include the DNS transport protocol (e.g. Do53 or DNS-over- >> HTTPS) which can differ between equivalent resolvers. To provide >> equivalence it is frequently likely to be the case that A and B are >> operated by the same administrative domain, but this document does >> not require that. >> >> This doesn't seem right. [Discussion of B being an attacker that offers >> the same DNS responses but also shares communications] >> > > Again, not sure what kind of different/stronger definition would remove > this risk. Perhaps it can be explored in the meeting tomorrow. > I suggested some text in the DEER thread. > >> * The local network can claim that one or more encrypted DNS >> resolvers (B, C, etc) are equivalent to the Do53 resolver (A) it >> has offered. This is known as network-identified. >> >> * During communication with the (often unencrypted) resolver (A), >> this resolver can claim that one or more encrypted DNS resolvers >> (B, C, etc) are equivalent. This is known as resolver-identified. >> >> These seem like two options, but they're not the only one. For instance, >> neither of these covers the preconfigured SPAU lists that Chrome and >> Edge use. >> > > Yes, preconfigured lists could be another way to claim equivalence. But > are they useful in the context of ADD which is all about automatic > discovery? > Well, they are automatic for the client, no? Imagine a central database that listed the IPs of resolvers and their corresponding equivalent resolvers (with the mechanism for populating that database TBD, but potentially via an ACME-like verification of control mechanism). This seems like it would be roughly isomorphic in functionality to the proposals you have here, except with a different signaling mechanism. I'm not saying it's the best design, but rather that it's not an invalid design. This document should not constrain the design space. >> >> S 7. >> | R1.1 | Discovery MUST provide a local network the | >> | | ability to announce to clients a set of, or | >> | | absence of, equivalent resolvers. | >> >> I don't agree that this is a requirement. See my comments about S 3.1. >> above. >> > > I think you're saying that network-identified is not mandatory, and may > not feature at all in the solution? > Yes. > >> >> >> | R1.3 | Discovery MUST support at least one encrypted | >> | | DNS protocol. | >> +-------------+-------------------------------------------------+ >> | R1.4 | Discovery SHOULD support all standardised | >> | | encrypted DNS protocols. | >> >> I don't understand these. Are you saying it's not a requirement to >> be able to indicate all the standardized protocols? That seems like >> it would be a fail. >> > > I'm saying it needs the ability to point users to DoT resolvers and DoH > resolvers. If it couldn't do one of those it would be less desirable. If > DoQ is published as an RFC, it would be useful for the ADD discovery > protocol to support DoQ too. This is *not *the same as having reserved > bits for each transport protocol, as draft-btw-add-home-10 does. > So, this text would be satisfied if this solution could only point users at DoH resolvers but not DoT resolvers. If we are to list requirements like this (which I am somewhat skeptical of ) then I think this document ought to require that the solution be able to support both DoH and DoT and be extensible to new protocols. > > | R5.2 | Threat modelling MUST assume that there is a | > | | passive eavesdropping attacker on the local | > | | network. | > +-------------+-------------------------------------------------+ > | R5.3 | Threat modelling MUST assume that an attacker | > | | can actively attack from outside the local | > | | network. | > > Normally one wouldn't call these requirements. > > Are you proposing they are deleted? Yes. -Ekr --000000000000a76a9a05b42a80fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Nov 15, 2020 at 11:04 AM Chri= s Box <chris.box.ietf@gmail.= com> wrote:

Ekr,

Thanks for the review. Some quick answers to your points below.
<= /div>

On Sat, 14 Nov 2020 at 23:50, Eric Rescorla <ekr@rtfm.com> wrote:
=C2=A0
I understand what you're trying to do here,
but I think w= hat you need to say is something quite different:

=C2=A0 =C2=A0The o= bjective of this use case is simply to replace Do53 with
=C2=A0 =C2=A0an= encrypted DNS protocol to the same resolver. Note that
=C2=A0 =C2=A0the= network's recommended unencrypted resolver may have a number of
=C2= =A0 =C2=A0properties that differ from a generic resolver.=C2=A0 It may be a= ble to
=C2=A0 =C2=A0answer names that are not known globally, it may exc= lude some names
=C2=A0 =C2=A0(for positive or negative reasons), and it = may provide address
=C2=A0 =C2=A0answers that have improved proximity. T= he user may or may not
=C2=A0 =C2=A0desire these properties and may or m= ay not be aware of them,
=C2=A0 =C2=A0but for the purposes of this use c= ase, we are not attempting
=C2=A0 =C2=A0to change these properties, but = merely to provide the user
=C2=A0 =C2=A0with encrypted transport.

Your wording, especially the last half,= is a substantial improvement. I'll look to merge this. In the first se= ntence I'd like to modify "to the same resolver", since we ar= e only trying to reach an equivalent resolver, and it may be physically sep= arate from the Do53 so I wouldn't consider them "same".
=

Agreed.


=C2= =A0

in many cases there is real uncertainty about which network is beingjoined. The most obvious case is coffee shop networks, hotspots,
etc. = in which the user may think they are joining the network
associated with= a given establishment (say Starbucks) but they are in
fact joining the = attacker's network. While it may be the case that
they are legitimat= ely upgraded to the attacker's Do[HTQ] server, I
don't think you= can call this "authenticating that the DNS resolver is
the correct= one".

Agree on the uncertai= nty, but not yet sure what the right wording is here.
=

Yeah, I think the whole thing just n= eeds to be a lot more nuanced.
=
=C2=A0

S 3.1.
=C2=A0 =C2=A0Given two resolvers A and B, equivalenc= e is the claim that A and B
=C2=A0 =C2=A0can provide the same upper-laye= r DNS function to the client.=C2=A0 This
=C2=A0 =C2=A0does not include t= he DNS transport protocol (e.g.=C2=A0 Do53 or DNS-over-
=C2=A0 =C2=A0HTT= PS) which can differ between equivalent resolvers.=C2=A0 To provide
=C2= =A0 =C2=A0equivalence it is frequently likely to be the case that A and B a= re
=C2=A0 =C2=A0operated by the same administrative domain, but this doc= ument does
=C2=A0 =C2=A0not require that.

This doesn't seem r= ight. [Discussion of B being an attacker that offers the same DNS responses= but also shares communications]

= Again, not sure what kind of different/stronger definition would remove thi= s risk. Perhaps it can be explored in the meeting tomorrow.

I suggested some text in the DEER = thread.


<= br>=C2=A0=C2=A0 * =C2=A0The local network can claim that one or more encryp= ted DNS
=C2=A0 =C2=A0 =C2=A0 resolvers (B, C, etc) are equivalent to the= Do53 resolver (A) it
=C2=A0 =C2=A0 =C2=A0 has offered.=C2=A0 This is kn= own as network-identified.

=C2=A0 =C2=A0* =C2=A0During communication= with the (often unencrypted) resolver (A),
=C2=A0 =C2=A0 =C2=A0 this re= solver can claim that one or more encrypted DNS resolvers
=C2=A0 =C2=A0 = =C2=A0 (B, C, etc) are equivalent.=C2=A0 This is known as resolver-identifi= ed.

These seem like two options, but they're not the only one. F= or instance,
neither of these covers the preconfigured SPAU lists that C= hrome and
Edge use.

Yes, preco= nfigured lists could be another way to claim equivalence. But are they usef= ul in the context of ADD which is all about automatic discovery?
<= /div>

Well, they are automatic = for the client, no?

Imagine a central database tha= t listed the IPs of resolvers and their corresponding equivalent resolvers = (with the mechanism for populating that database TBD, but potentially via a= n ACME-like verification of control mechanism). This seems like it would be= roughly isomorphic in functionality to the proposals you have here, except= with a different signaling mechanism. I'm not saying it's the best= design, but rather that it's not an invalid design. This document shou= ld not constrain the design space.



S 7= .
=C2=A0 =C2=A0 =C2=A0| R1.1 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Discovery MUST= provide a local network the =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | ability to announce to clients= a set of, or =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 | absence of, equivalent resolvers. =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |

I don't agree that this is a r= equirement. See my comments about S 3.1.
above.

I think you're saying that network-identified is not = mandatory, and may not feature at all in the solution?

Yes.

=C2=A0


=C2=A0 =C2=A0 =C2=A0| R1.3 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| Discovery MUST support at least one encrypted =C2= =A0 |
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | = DNS protocol. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2= =A0 =C2=A0+-------------+-------------------------------------------------+=
=C2=A0 =C2=A0 =C2=A0| R1.4 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Discovery SHOUL= D support all standardised =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | encrypted DNS protocols. =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|

I don't understand these. Are you saying it's not a req= uirement to
be able to indicate all the standardized protocols? That see= ms like
it would be a fail.

I&= #39;m saying it needs the ability to point users to DoT resolvers and DoH r= esolvers. If it couldn't do one of those it would be less desirable. If= DoQ is published as an RFC, it would be useful for the ADD discovery proto= col to support DoQ too. This is not the same as having reserved bits= for each transport protocol, as draft-btw-add-home-10 does.

So, this text would be satisfied = if this solution could only point users at DoH resolvers but not DoT resolv= ers. If we are to list requirements like this (which I am somewhat skeptica= l of ) then I think this document ought to require that the solution be abl= e to support both DoH and DoT and be extensible to new protocols.
=



=C2=A0

=C2=A0 =C2=A0 =C2=A0| R5.2 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| Threat modelling MUST assume that there is a = =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | passive eavesdropping attacker on the local =C2=A0 =C2=A0 |
=C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | network. =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 = =C2=A0 =C2=A0+-------------+-----------------------------------------------= --+
=C2=A0 =C2=A0 =C2=A0| R5.3 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Threat model= ling MUST assume that an attacker =C2=A0 |
=C2=A0 =C2=A0 =C2=A0| =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | can actively attack from outside the l= ocal =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | network. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|

Normally one wouldn't call these requi= rements.

> Are you proposing they ar= e deleted?

Yes.

-Ekr<= /div>

--000000000000a76a9a05b42a80fb-- From nobody Sun Nov 15 13:17:38 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E46DF3A0DB5 for ; Sun, 15 Nov 2020 13:17:36 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.onmicrosoft.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 9enjTK0lZm8a for ; Sun, 15 Nov 2020 13:17:35 -0800 (PST) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100065.outbound.protection.outlook.com [40.107.10.65]) (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 DB9EA3A0DB4 for ; Sun, 15 Nov 2020 13:17:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=USU4mqqD/K2TRUwP/Xc6mlJuh0lqt5oKT4JRw/zc6wwLJdxVrpizBR9l47zX6AlQV+Fee66K5PtCrYsyyMpa15nPfNK4uSOye6AzzDpfZ1xOYoXqce9X54SoudCHitNbkt/yaIFKbNwqBRwGps7EuegYXZiw3mUc7c7irJe1vgqth8f6trD6lLYJQqF1FRzWJiQ+OPUW2GSz7uDd/nGWUwbaDOXHCxR95vyY5mTz62wRbky6tp7ovHH8M7o3ksbE2c7c+9f5Xyi/KsYfxOx5KMcGWZAcQFTN76Wa2B6oUl2PIHzTttj9c3CWaGqPvOKYrel2d13/3BOnM9jzo+cDFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4NUIQLdVlit8Y8mStrU0XY7uRF7Nrcwc7YU9xPUExzA=; b=d5kbomVdBeKRuK0JC1+8Kac7VjMjCST6yGD4ed+MS//hQK/kccZpQKPLUeCfyr7IcSHm8kIyO/d63Z+L63p3igZmmFJpJ3H5NOGoxwYOhqF+E18vdzCnkmpx9PGIJV8ac8KPFzHCxTpe1rOBwF4Hn7xRUSJRgavK3RCOizhDR0BJtRBTpUnvil06EUp72LSckGpuEr63cP4ezpXIpXX+JbmEpdvGCqwDQTFbPSLcMlOjEhfVSwzRXkQZact2EPcjRoauQeDuzBc1x8fynVUPw6WJ768sLloPGzgPE0DPNaE7KytzxjlFgOBNe1Cqhc40/bNu8HPGt6WFkvEWgr4BBg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4NUIQLdVlit8Y8mStrU0XY7uRF7Nrcwc7YU9xPUExzA=; b=iN0AAjSLChnSmZZGMnPDa0KWbtAnJ4UsqHXwABQsrd44Gij8LkBvGEegAa9ZI5uzUw6dQ/RXD8YU59YOICC3OqMWvBADF6zv/swhLwa8JIneBQ0ysJPoKzWzBkfvOJ3ScE0E9MDLsjYKllZqCUq3RR6RQq30uGcxJtyze/tgU/c= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:71::15) by LNXP265MB0186.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:15::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Sun, 15 Nov 2020 21:17:32 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::199b:a430:6264:9bf6]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::199b:a430:6264:9bf6%7]) with mapi id 15.20.3564.028; Sun, 15 Nov 2020 21:17:32 +0000 From: Andrew Campling To: Eric Rescorla , Chris Box CC: ADD Mailing list Thread-Topic: [Add] Review of draft-box-add-requirements-01.txt Thread-Index: AQHWu4oZy+jMKkjigUSgtAiS8ZlExanJsHew Date: Sun, 15 Nov 2020 21:17:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=419.consulting; x-originating-ip: [86.144.97.96] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 679af77d-3189-4d46-e7d4-08d889abdd86 x-ms-traffictypediagnostic: LNXP265MB0186: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pHbQ5ICjBC48RbFjfKPdadNw+FCHjO3gwHWZfip5bIWK/14+vOO79uY5hyZH3aoCVx0cWKaXG2OfxGiK0kIhL/W0C2MJK6mpYO1ecyj2v9e1T24Icn7KTCpErVKQYVqt/DrD0BpUiJdfLJQfFGil1fLanh/roLh6IRQB1C5nTQxHEVql9nKlP2Hswz/V3zm/SAs1WTIH8WTtJvqGMVxx18M+RTysbfy//gAqus6W02Do8oAspAmFIgI2nVHBdso/fCFq+32t5FCVnKMZEX+BeZAu3XMWH0RRi61mUQkVOT7nJUf/vlJHPw0u9daqu8xxqQmO7VgczxdX/eZNF4nhQ6YdKzXNbVmTm7BaoUIQje5Zw0PQH1fqNpXZUzy8Xyxo x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39830400003)(346002)(396003)(136003)(366004)(376002)(33656002)(86362001)(8936002)(7696005)(4326008)(55016002)(9686003)(478600001)(316002)(110136005)(26005)(2906002)(83380400001)(53546011)(8676002)(186003)(6506007)(44832011)(66476007)(64756008)(66446008)(66556008)(71200400001)(76116006)(52536014)(66946007)(5660300002)(46492008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 2K+7ttZRUxRkz6UCNuR6NDKDgQBHjQc4a9MzT6ed71IeiNXGP8FsYsjjeGhFwGV4RlLtEVk4O8tqLyu1IYbIacb4ZIpgsf6SOOAxxa6Db+BkrNkFDT2qeIeu/P0vmpjQS2QRxR/ep2XoTJtLBo4sK+DXRsjvdtH1GYTvXsaSL0Qa8XcckopnY6TLc3m9DkZ8nKCfepJfEoL3jXyfR1owcbM53W7/4Qaekz/bSMIT0/4A9VPbvST2SAZTamBMR/HS+IZbhiNjBYHfmno6iCAeSLH4jGpnB+FuCvhDg75zYJFWoLvHLa7atM8kBSWtm+OFAjjWJF0vqfQuSOnINy5QESYqmSNIVzaWoN7zcZu8UbAqU3KkYSeV7o07NHwv61ZXRMNg7LlMNzAb306DhQ6N1wQP9Mw62rhFajn3oY0GPHu+LNRBwVPIxCePiePBxnhE7KRvPT4UdwR6Cx/TvZk3FyH1kV4rIhsmyUUQ64zTnTnxv7IzNyx5Jy051xoljBukMHlN7/swjms31YwJIv2g+h7qisH5ctwmtAKgm24rTAZk+ukjVBUZTUfay8QMU87MCKNefOnbiN6CCZQABpcWKI7X/VxJ4mjmJcMf1QgKN2LTFz9bNBstshpSzMLznYwR0UoePW4gnBZuTiT5ys1fcrL1hP2mEBafB+ehPC70OqdAxeIhwQGOalzdNuYTt4Xsp1KKev6vlZcH9QNnsgm/5SZ9N+O5cNgANfNNsqyj9N9ulariVFPs26NgYvxNBAlKvoWEIHnnYzOofEZQ/jZSlCQXAX+063u7jzS0LnxBm9fiK+r+PE9mVSoZKvP0rd8ajzKQAHAeMPf56DBGDWC5C0/x5n9ZR6+zznmGbhDPcJ7I8BRkIoFRmLInEv+UQu3Chz3FAxWi9QZy8QvmVZXcIw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P265MB0573EF75A726577EC06B7E2DC2E40LO2P265MB0573GBRP_" MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 679af77d-3189-4d46-e7d4-08d889abdd86 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2020 21:17:31.9685 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PVjW14A6tKXuNYaY+w0Q3EjmxZs1bPs1em2t7R0BSDNauQDeO0S9QA4lV3e9UqgiNBgwJ7urbjTVD82OeQ2imNOjZ1qW31m/8CBPv4a+sec= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP265MB0186 Archived-At: Subject: Re: [Add] Review of draft-box-add-requirements-01.txt X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 21:17:37 -0000 --_000_LO2P265MB0573EF75A726577EC06B7E2DC2E40LO2P265MB0573GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gU3VuLCBOb3YgMTUsIDIwMjAgYXQgMTk6NDUgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29t PG1haWx0bzpla3JAcnRmbS5jb20+PiB3cm90ZToNCg0KDQo+IE9uIFN1biwgTm92IDE1LCAyMDIw IGF0IDExOjA0IEFNIENocmlzIEJveCA8Y2hyaXMuYm94LmlldGZAZ21haWwuY29tPG1haWx0bzpj aHJpcy5ib3guaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCg0KT24gU2F0LCAxNCBOb3YgMjAyMCBh dCAyMzo1MCwgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+ PiB3cm90ZToNCg0KICAgKiAgVGhlIGxvY2FsIG5ldHdvcmsgY2FuIGNsYWltIHRoYXQgb25lIG9y IG1vcmUgZW5jcnlwdGVkIEROUw0KICAgICAgcmVzb2x2ZXJzIChCLCBDLCBldGMpIGFyZSBlcXVp dmFsZW50IHRvIHRoZSBEbzUzIHJlc29sdmVyIChBKSBpdA0KICAgICAgaGFzIG9mZmVyZWQuICBU aGlzIGlzIGtub3duIGFzIG5ldHdvcmstaWRlbnRpZmllZC4NCg0KICAgKiAgRHVyaW5nIGNvbW11 bmljYXRpb24gd2l0aCB0aGUgKG9mdGVuIHVuZW5jcnlwdGVkKSByZXNvbHZlciAoQSksDQogICAg ICB0aGlzIHJlc29sdmVyIGNhbiBjbGFpbSB0aGF0IG9uZSBvciBtb3JlIGVuY3J5cHRlZCBETlMg cmVzb2x2ZXJzDQogICAgICAoQiwgQywgZXRjKSBhcmUgZXF1aXZhbGVudC4gIFRoaXMgaXMga25v d24gYXMgcmVzb2x2ZXItaWRlbnRpZmllZC4NCg0KVGhlc2Ugc2VlbSBsaWtlIHR3byBvcHRpb25z LCBidXQgdGhleSdyZSBub3QgdGhlIG9ubHkgb25lLiBGb3IgaW5zdGFuY2UsDQpuZWl0aGVyIG9m IHRoZXNlIGNvdmVycyB0aGUgcHJlY29uZmlndXJlZCBTUEFVIGxpc3RzIHRoYXQgQ2hyb21lIGFu ZA0KRWRnZSB1c2UuDQoNClllcywgcHJlY29uZmlndXJlZCBsaXN0cyBjb3VsZCBiZSBhbm90aGVy IHdheSB0byBjbGFpbSBlcXVpdmFsZW5jZS4gQnV0IGFyZSB0aGV5IHVzZWZ1bCBpbiB0aGUgY29u dGV4dCBvZiBBREQgd2hpY2ggaXMgYWxsIGFib3V0IGF1dG9tYXRpYyBkaXNjb3Zlcnk/DQoNCj4g V2VsbCwgdGhleSBhcmUgYXV0b21hdGljIGZvciB0aGUgY2xpZW50LCBubz8NCg0KPiBJbWFnaW5l IGEgY2VudHJhbCBkYXRhYmFzZSB0aGF0IGxpc3RlZCB0aGUgSVBzIG9mIHJlc29sdmVycyBhbmQg dGhlaXIgY29ycmVzcG9uZGluZyBlcXVpdmFsZW50IHJlc29sdmVycyAod2l0aCB0aGUgbWVjaGFu aXNtIGZvciBwb3B1bGF0aW5nIHRoYXQgZGF0YWJhc2UgVEJELCBidXQgcG90ZW50aWFsbHkgdmlh IGFuIEFDTUUtbGlrZSB2ZXJpZmljYXRpb24gb2YgY29udHJvbCBtZWNoYW5pc20pLiBUaGlzIHNl ZW1zIGxpa2UgaXQgd291bGQgYmUgcm91Z2hseSBpc29tb3JwaGljIGluIGZ1bmN0aW9uYWxpdHkg dG8gdGhlIHByb3Bvc2FscyB5b3UgaGF2ZSBoZXJlLCBleGNlcHQgd2l0aCBhIGRpZmZlcmVudCBz aWduYWxpbmcgbWVjaGFuaXNtLiBJJ20gbm90IHNheWluZyBpdCdzIHRoZSBiZXN0IGRlc2lnbiwg YnV0IHJhdGhlciB0aGF0IGl0J3Mgbm90IGFuIGludmFsaWQgZGVzaWduLiBUaGlzIGRvY3VtZW50 IHNob3VsZCBub3QgY29uc3RyYWluIHRoZSBkZXNpZ24gc3BhY2UuDQoNCg0KQmFzZWQgb24gdGhl IHJlY2VudCBicmllZmluZyBieSBvbmUgb2YgdGhlIHJlZ3VsYXRvcnMsIHN1Y2ggYW4gYXBwcm9h Y2ggY291bGQgd2VsbCBzZWUgYW55IGNsaWVudHMgYmVpbmcgY2xhc3NpZmllZCBhcyBkYXRhIGNv bnRyb2xsZXJzIHVuZGVyIEdEUFIuICBUaGlzIGRvZXNu4oCZdCBtYWtlIGl0IGEgYmFkIHNvbHV0 aW9uIGJ1dCBpdCBtYXkgbWFrZSBpdCBsZXNzIGF0dHJhY3RpdmUgdG8gc29tZS4NCg0KQW5kcmV3 DQo= --_000_LO2P265MB0573EF75A726577EC06B7E2DC2E40LO2P265MB0573GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTow Y207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8N CkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjIwMzA1NzAwMDsNCgltc28tbGlzdC10eXBlOmh5YnJp ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEyMzM5ODg2NjIgLTE2MTM0MzI3NTIgMTM0ODA3 NTU1IDEzNDgwNzU1NyAxMzQ4MDc1NTMgMTM0ODA3NTU1IDEzNDgwNzU1NyAxMzQ4MDc1NTMgMTM0 ODA3NTU1IDEzNDgwNzU1Nzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0 OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+D mDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJ bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseTpD YWxpYnJpO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6 bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6NzgzNzY2NTAwOw0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMzk1NDExMzY2IDIxMTAxNTcxMDIgMTM0ODA3NTU1 IDEzNDgwNzU1NyAxMzQ4MDc1NTMgMTM0ODA3NTU1IDEzNDgwNzU1NyAxMzQ4MDc1NTMgMTM0ODA3 NTU1IDEzNDgwNzU1Nzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7 DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJp Ow0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2 ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxNjY0OTcy ODUzOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMDEy NDAzMTAgMTUxMjM1NDczNiAxMzQ4MDc1NTUgMTM0ODA3NTU3IDEzNDgwNzU1MyAxMzQ4MDc1NTUg MTM0ODA3NTU3IDEzNDgwNzU1MyAxMzQ4MDc1NTUgMTM0ODA3NTU3O30NCkBsaXN0IGwyOmxldmVs MQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo1NC4wcHQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1i aWRpLWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVm dDo5MC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxMjYuMHB0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgltYXJnaW4tbGVmdDoxNjIuMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTk4LjBw dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIzNC4wcHQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CW1hcmdpbi1sZWZ0OjI3MC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozMDYuMHB0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MzQyLjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoxOTY5 NzA1MzgxOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczox ODc1NzY3NzAgNTEzNTg5NjM0IDEzNDgwNzU1NSAxMzQ4MDc1NTcgMTM0ODA3NTUzIDEzNDgwNzU1 NSAxMzQ4MDc1NTcgMTM0ODA3NTUzIDEzNDgwNzU1NSAxMzQ4MDc1NTc7fQ0KQGxpc3QgbDM6bGV2 ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE4LjBwdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFz dC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0K QGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo1NC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwzOmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN CgltYXJnaW4tbGVmdDo5MC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEyNi4wcHQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6 bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgltYXJnaW4tbGVmdDoxNjIuMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMzpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2lu LWxlZnQ6MTk4LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjM0LjBwdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDgN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCW1hcmdpbi1sZWZ0OjI3MC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoz MDYuMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N Cm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBz dHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIE5vdiAxNSwgMjAyMCBhdCAxOTo0 NSA8c3BhbiBsYW5nPSJFTi1VUyI+RXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVr ckBydGZtLmNvbSI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsNCjwvc3Bhbj53cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDowY20iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jmd0OyBPbiBTdW4sIE5vdiAxNSwgMjAyMCBhdCAxMTowNCBBTSBDaHJpcyBCb3ggJmx0Ozxh IGhyZWY9Im1haWx0bzpjaHJpcy5ib3guaWV0ZkBnbWFpbC5jb20iPmNocmlzLmJveC5pZXRmQGdt YWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjExLjU1 cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNhdCwgMTQgTm92IDIwMjAgYXQgMjM6NTAsIEVyaWMgUmVz Y29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5l a3JAcnRmbS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMS41NXB0Ij48YnI+DQombmJzcDsmbmJzcDsgKiAm bmJzcDtUaGUgbG9jYWwgbmV0d29yayBjYW4gY2xhaW0gdGhhdCBvbmUgb3IgbW9yZSBlbmNyeXB0 ZWQgRE5TPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVzb2x2ZXJzIChCLCBDLCBldGMpIGFy ZSBlcXVpdmFsZW50IHRvIHRoZSBEbzUzIHJlc29sdmVyIChBKSBpdDxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7IGhhcyBvZmZlcmVkLiZuYnNwOyBUaGlzIGlzIGtub3duIGFzIG5ldHdvcmstaWRl bnRpZmllZC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7KiAmbmJzcDtEdXJpbmcgY29tbXVuaWNh dGlvbiB3aXRoIHRoZSAob2Z0ZW4gdW5lbmNyeXB0ZWQpIHJlc29sdmVyIChBKSw8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyB0aGlzIHJlc29sdmVyIGNhbiBjbGFpbSB0aGF0IG9uZSBvciBtb3Jl IGVuY3J5cHRlZCBETlMgcmVzb2x2ZXJzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgKEIsIEMs IGV0YykgYXJlIGVxdWl2YWxlbnQuJm5ic3A7IFRoaXMgaXMga25vd24gYXMgcmVzb2x2ZXItaWRl bnRpZmllZC48YnI+DQo8YnI+DQpUaGVzZSBzZWVtIGxpa2UgdHdvIG9wdGlvbnMsIGJ1dCB0aGV5 J3JlIG5vdCB0aGUgb25seSBvbmUuIEZvciBpbnN0YW5jZSw8YnI+DQpuZWl0aGVyIG9mIHRoZXNl IGNvdmVycyB0aGUgcHJlY29uZmlndXJlZCBTUEFVIGxpc3RzIHRoYXQgQ2hyb21lIGFuZDxicj4N CkVkZ2UgdXNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjExLjU1cHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjExLjU1cHQiPlllcywgcHJlY29uZmlndXJlZCBsaXN0cyBjb3VsZCBiZSBh bm90aGVyIHdheSB0byBjbGFpbSBlcXVpdmFsZW5jZS4gQnV0IGFyZSB0aGV5IHVzZWZ1bCBpbiB0 aGUgY29udGV4dCBvZiBBREQgd2hpY2ggaXMgYWxsIGFib3V0IGF1dG9tYXRpYyBkaXNjb3Zlcnk/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTEu NTVwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mZ3Q7IFdlbGwsIHRoZXkgYXJlIGF1dG9tYXRpYyBmb3IgdGhlIGNsaWVudCwgbm8/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MTEuNTVwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEltYWdpbmUgYSBjZW50cmFsIGRhdGFiYXNl IHRoYXQgbGlzdGVkIHRoZSBJUHMgb2YgcmVzb2x2ZXJzIGFuZCB0aGVpciBjb3JyZXNwb25kaW5n IGVxdWl2YWxlbnQgcmVzb2x2ZXJzICh3aXRoIHRoZSBtZWNoYW5pc20gZm9yIHBvcHVsYXRpbmcg dGhhdCBkYXRhYmFzZSBUQkQsIGJ1dCBwb3RlbnRpYWxseSB2aWEgYW4gQUNNRS1saWtlIHZlcmlm aWNhdGlvbiBvZiBjb250cm9sIG1lY2hhbmlzbSkuIFRoaXMgc2VlbXMNCiBsaWtlIGl0IHdvdWxk IGJlIHJvdWdobHkgaXNvbW9ycGhpYyBpbiBmdW5jdGlvbmFsaXR5IHRvIHRoZSBwcm9wb3NhbHMg eW91IGhhdmUgaGVyZSwgZXhjZXB0IHdpdGggYSBkaWZmZXJlbnQgc2lnbmFsaW5nIG1lY2hhbmlz bS4gSSdtIG5vdCBzYXlpbmcgaXQncyB0aGUgYmVzdCBkZXNpZ24sIGJ1dCByYXRoZXIgdGhhdCBp dCdzIG5vdCBhbiBpbnZhbGlkIGRlc2lnbi4gVGhpcyBkb2N1bWVudCBzaG91bGQgbm90IGNvbnN0 cmFpbiB0aGUgZGVzaWduDQogc3BhY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPkJhc2VkIG9uIHRoZSByZWNlbnQgYnJpZWZpbmcgYnkgb25lIG9mIHRoZSBy ZWd1bGF0b3JzLCBzdWNoIGFuIGFwcHJvYWNoIGNvdWxkIHdlbGwgc2VlIGFueSBjbGllbnRzIGJl aW5nIGNsYXNzaWZpZWQgYXMgZGF0YSBjb250cm9sbGVycyB1bmRlciBHRFBSLiZuYnNwOyBUaGlz IGRvZXNu4oCZdCBtYWtlIGl0IGEgYmFkIHNvbHV0aW9uIGJ1dCBpdCBtYXkgbWFrZSBpdCBsZXNz DQogYXR0cmFjdGl2ZSB0byBzb21lLiZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPkFuZHJldyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_LO2P265MB0573EF75A726577EC06B7E2DC2E40LO2P265MB0573GBRP_-- From nobody Sun Nov 15 13:27:20 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615DD3A0DDD for ; Sun, 15 Nov 2020 13:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 GUmiffkCzyWO for ; Sun, 15 Nov 2020 13:27:17 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::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 DC3D63A0E41 for ; Sun, 15 Nov 2020 13:27:09 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id y16so17863657ljh.0 for ; Sun, 15 Nov 2020 13:27:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=doTB52t7VYox61EK8mc+qdnIC6rPXgYK8CCxiv0AvZ8=; b=XyE5Og7Wmf/u6u7ETuDKUTCmZiqYxi6Kv8ZLTd+AMGahmA2WPjz3AknJrQAbD+fOsc ppFpFEuFwTdUgJAIoAaDtU8Wx00UG9m/5bF6mhj9MfQQg51CHhrfmtSi72ZujkjK3SrC JxYJ+Jau/HOSWgSTVms3/bOgRzOkhHxcjrLGj8sHxZtNroCnMfprZtnESlSCdrEUquOk L2LVRGL6jKvS/g3qKhbhtMQ/GVDWNwiNa2aMXlLbjnIGBPI65tWj70iLEf0zJDkb/q/A pj9yHfX+bvhVU2tLbk/JZpDfGs04nl4ybubzqCYyElahVCoMNJKd+viKXs/6L27EG1ES Acrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=doTB52t7VYox61EK8mc+qdnIC6rPXgYK8CCxiv0AvZ8=; b=AwFX31qiBLAepyTQHuSA5iZ9ISbsm7UU1BmQlj82xOfT19J4VTlD/L9KDeXlgzA36p qoRqwbxde2QrwbdNUQdZkPjnaR7sySqpZELeJ/rxDnUfQJqaG7GrYoR9kgIvX5XzmLA5 4weUcB0b8aRQxW2WtnmNUppkys7T0VRt4aeYU6BJze+iUrCLtBhWG7Mm7t/7Wy9ai3cD KzFubQaHjYJ9wpvzcY0V6ks2OhNASVMMGrfedyJBxnsRGvzj7m3d8ohO0PjBiZTsYMd0 OhY5GguVUmKXwZVdBfNAn44AyiPcJt+EdyMY+FA1D+cpg1bkkRdoR51RjpI6lXPkb96X bSAg== X-Gm-Message-State: AOAM5309QLGYIMwbrQCCcHBnUiuyNuNC5n6ZdmRu2yxWFOCENVbfvUNU DcSVsnZqkYSX4rY/VKWzNH/mO3u9RF7lHlBFOTAlpQ== X-Google-Smtp-Source: ABdhPJy1wHkH0kyS6PBQdAPMIRYhwwTEFWH8jFAJCf65OOo/H2BZrTkGW+B/E9F1JgEnLg79PEzhk5dcpoUaiFE5RXc= X-Received: by 2002:a05:651c:1105:: with SMTP id d5mr5492026ljo.265.1605475627969; Sun, 15 Nov 2020 13:27:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Sun, 15 Nov 2020 13:26:31 -0800 Message-ID: To: Andrew Campling Cc: Chris Box , ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000080436505b42becfa" Archived-At: Subject: Re: [Add] Review of draft-box-add-requirements-01.txt X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 21:27:19 -0000 --00000000000080436505b42becfa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Nov 15, 2020 at 1:17 PM Andrew Campling wrote: > On Sun, Nov 15, 2020 at 19:45 Eric Rescorla wrote: > > > > > On Sun, Nov 15, 2020 at 11:04 AM Chris Box > wrote: > > > > On Sat, 14 Nov 2020 at 23:50, Eric Rescorla wrote: > > > * The local network can claim that one or more encrypted DNS > resolvers (B, C, etc) are equivalent to the Do53 resolver (A) it > has offered. This is known as network-identified. > > * During communication with the (often unencrypted) resolver (A), > this resolver can claim that one or more encrypted DNS resolvers > (B, C, etc) are equivalent. This is known as resolver-identified. > > These seem like two options, but they're not the only one. For instance, > neither of these covers the preconfigured SPAU lists that Chrome and > Edge use. > > > > Yes, preconfigured lists could be another way to claim equivalence. But > are they useful in the context of ADD which is all about automatic > discovery? > > > > > Well, they are automatic for the client, no? > > > > > Imagine a central database that listed the IPs of resolvers and their > corresponding equivalent resolvers (with the mechanism for populating tha= t > database TBD, but potentially via an ACME-like verification of control > mechanism). This seems like it would be roughly isomorphic in functionali= ty > to the proposals you have here, except with a different signaling > mechanism. I'm not saying it's the best design, but rather that it's not = an > invalid design. This document should not constrain the design space. > > > > > > Based on the recent briefing by one of the regulators, such an approach > could well see any clients being classified as data controllers under > GDPR. This doesn=E2=80=99t make it a bad solution but it may make it les= s > attractive to some. > I'm not really following your argument here: I'm not talking about a system that is operated by the clients but rather a system that is isomorphic to the approaches listed here but in which the communication is via a central (potentially open) database rather than via DNS or DHCP. If it makes it clearer, consider a version where the database just consists of HTTPSVC records as in DEER that are keyed under the resolver IP. In any case, I'm not arguing for this system; I'm arguing that the requirements document shouldn't limit the technical options. -Ekr --00000000000080436505b42becfa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Nov 15, 2020 at 1:17 PM Andre= w Campling <andrew.campling@419.consulting> wrote:

On Sun, Nov 15, 2020 at 19:45 E= ric Rescorla <ekr@rtfm= .com> wrote:

=C2=A0

> On Sun, Nov 15, 2020 at 11:04 AM Chris Box <= chris.box.iet= f@gmail.com> wrote:

=C2=A0

On Sat, 14 Nov 2020 at 23:50, Eric Rescorla <ekr@rtfm.com> wrote:


=C2=A0=C2=A0 * =C2=A0The local network can claim that one or more encrypted= DNS
=C2=A0 =C2=A0 =C2=A0 resolvers (B, C, etc) are equivalent to the Do53 resol= ver (A) it
=C2=A0 =C2=A0 =C2=A0 has offered.=C2=A0 This is known as network-identified= .

=C2=A0 =C2=A0* =C2=A0During communication with the (often unencrypted) reso= lver (A),
=C2=A0 =C2=A0 =C2=A0 this resolver can claim that one or more encrypted DNS= resolvers
=C2=A0 =C2=A0 =C2=A0 (B, C, etc) are equivalent.=C2=A0 This is known as res= olver-identified.

These seem like two options, but they're not the only one. For instance= ,
neither of these covers the preconfigured SPAU lists that Chrome and
Edge use.

=C2=A0

Yes, preconfigured lis= ts could be another way to claim equivalence. But are they useful in the co= ntext of ADD which is all about automatic discovery?

=C2=A0

> Well, they are automatic for the client, no?=

=C2=A0

> Imagine a central database that listed the IPs = of resolvers and their corresponding equivalent resolvers (with the mechani= sm for populating that database TBD, but potentially via an ACME-like verif= ication of control mechanism). This seems like it would be roughly isomorphic in functionality to the proposals you = have here, except with a different signaling mechanism. I'm not saying = it's the best design, but rather that it's not an invalid design. T= his document should not constrain the design space.

=C2=A0

=C2=A0<= /span>

Based on the recent b= riefing by one of the regulators, such an approach could well see any clien= ts being classified as data controllers under GDPR.=C2=A0 This doesn=E2=80= =99t make it a bad solution but it may make it less attractive to some.=C2=A0

<= /blockquote>

I'm not really following your argument = here: I'm not talking about a system that is operated by the clients bu= t rather a system that is isomorphic to the approaches listed here but in w= hich the communication is via a central (potentially open) database rather = than via DNS or DHCP. If it makes it clearer, consider a version where the = database just consists of HTTPSVC records as in DEER that are keyed under t= he resolver IP.

In any case, I'm not arguing f= or this system; I'm arguing that the requirements document shouldn'= t limit the technical options.

-Ekr
--00000000000080436505b42becfa-- From nobody Sun Nov 15 16:51:02 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833C03A0BE2 for ; Sun, 15 Nov 2020 16:51:01 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 mGDpZbSdULWt for ; Sun, 15 Nov 2020 16:50:59 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08DCB3A0E2F for ; Sun, 15 Nov 2020 16:50:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9BA1E389D5; Sun, 15 Nov 2020 19:51:31 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jfDNdU-CnKIJ; Sun, 15 Nov 2020 19:51:30 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6C4E2389C3; Sun, 15 Nov 2020 19:51:30 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2DCBE57A; Sun, 15 Nov 2020 19:50:44 -0500 (EST) From: Michael Richardson To: Eric Rescorla , ADD Mailing list In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Add] Review of draft-pauly-add-deer-00.txt+ X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 00:51:02 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eric Rescorla wrote: > Now, if that DoT resolver provides different responses based on the c= lient's > apparent IP address, then an on-network attacker can serve their own = record: > _dns.example.net 7200 IN SVCB 1 dot.example.net ( > alpn=3Ddot port=3D8530 ipv4hint=3D203.1.113.1) > Where the ipv4hint refers to something they control. They then proxy = the > TLS connection to the true DoT server. Because the SAN only needs to > contain the Unencrypted Resolver address and *not* the Encrypted Reso= lver > address, then this will succeed, with the result that the client gets > different > data than it would if the attacker had not been present. This raises = several > questions: So the TLS connection is intact. The client is connected to the correct destination, but resolver sees the attacker's origin IP rather than the client's address. > 1. Do we think this is bad? It sounds like classic NAPT to me. > 2. If the answer to (1) is yes, how do we redefine equivalence to cov= er it? > 3. What does DEER need to do to stop it? [Off the top of my head, > perhaps have the ER's address also be in the SAN field of the cert and > check that] That would work. Another possibility is that the server should never believe the origin IP, but rather the client should tell the server of it's address inband. I believe that the is a spec for this, but I don't have the dns-fu anymore = to remember which one it is. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+xzOMACgkQgItw+93Q 3WX7zQgAi8of4nAZAHsJnjwi3KxzT1VkyDsnKVk02BboWnUrK08N3dMSY8mS6F47 JOsS2qbHQfq//b9YOrzd0xC+5xCvaJc1c/Op6E46InxURvqU8eoeF+pvFg677ydU An7oVcYIJQhjDB7ixERZYUBYYN0wJk+IpS/UUNOob7rC1Jl981hjm+a879hlM39B s6VdK1v7voqY/rKeImZ1WxqtYsOumrmNH6e/ReRtAyxAUVhf9nge5OhPMYsTwwQk YypN8oi7RLogNXed81VGIRRkPpeQNB89gOWl4E1jhVwuGh/0WOWjwg9S5okmFWW1 UZxE9s6Y+D8tPV26lYEXssfuSbzz7g== =fCJv -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 15 16:56:20 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5137C3A0C64 for ; Sun, 15 Nov 2020 16:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 OmY30YRezxpP for ; Sun, 15 Nov 2020 16:56:17 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 1989A3A0C31 for ; Sun, 15 Nov 2020 16:56:17 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id s30so22895527lfc.4 for ; Sun, 15 Nov 2020 16:56:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bNqHSSdorDZlddK+p5iI5cyVmcawLK8zA8FwMGmY7U8=; b=qT5aAKWFodgB2A/1+56UAs/RIx/ACLmxBM4dBG5N/pBQGqOGZJhWU0/aAhJEg0G4GH gdQy1OAmxEIlUbcJNyoANV1MC/5IhFiReqtM3oAHgCpF1sDWA5ajJzsv17COyh1v/fLO F4edDSDdd0AfvOFnG2wra7jgzb9ynCvYAYMO9RXj189qN/RKCP9wBatu28vUTcD4H1Wt FYnTbzIxDYVwAfeNMca2gWiBLW6EFs5LlGbRW642atZcRiVTU0JBvlbBhk//txiR29tj K59TouktQmv3h/YUY9Rt229lTE11DC2Le46FbMOogWCLdtqj2PQyH3mv7wTszRfhdjvS z2zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bNqHSSdorDZlddK+p5iI5cyVmcawLK8zA8FwMGmY7U8=; b=oV/hhE+x9MD5stC3w9/VvHMHoDxX4khNcy9xQXEmVntg+n/wx0+P7W9rJShVNvhQzz hn7tdZ2e6yk8VmMKKHbWmvhP3nlK8TrHqnDCxhIfSvGruxmGVyZVGkUPDVTEBf2PKeQz t+tGVpjUCIPI23Y+PxmyA/fLLeWRqCJV95tUY7MRQcMJ5DYZVvWNVltByxdWOEEvDvOs AlhKmJCCHlhxOti6Otd1tEhHnTUYdVz/bKoRv989V+j1jX7tXUsEDwpj5qVlPqBFCMpb DgnmYnpmJ8jE5QyVwlh3qoHSRnWkYSe9jJJZtiLPXAH20h/Apb4uj2rPCKlQjiHMuJZG X+Sw== X-Gm-Message-State: AOAM533D6wXqAfAPUlJSu0GD3qqB/7+/khlD6+CUdE6iIFKQYbRaujDd Ss48tXdcCeuqMFd98P/bbSxRGkLTL+YuNJUa9HmLDw== X-Google-Smtp-Source: ABdhPJyfPmz9Oub4He2a/i2vrgE010s9Io0eRYWDLPSmjoI5Ua2m3HksJlsIsHxRuEqltU50iCPnRo/pIhgNQRilrEY= X-Received: by 2002:a19:c3cd:: with SMTP id t196mr4472895lff.26.1605488175036; Sun, 15 Nov 2020 16:56:15 -0800 (PST) MIME-Version: 1.0 References: <12463.1605487844@localhost> In-Reply-To: <12463.1605487844@localhost> From: Eric Rescorla Date: Sun, 15 Nov 2020 16:55:38 -0800 Message-ID: To: Michael Richardson Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000005d4ee905b42ed896" Archived-At: Subject: Re: [Add] Review of draft-pauly-add-deer-00.txt+ X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 00:56:19 -0000 --0000000000005d4ee905b42ed896 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Nov 15, 2020 at 4:50 PM Michael Richardson wrote: > > Eric Rescorla wrote: > > Now, if that DoT resolver provides different responses based on the > client's > > apparent IP address, then an on-network attacker can serve their ow= n > record: > > > _dns.example.net 7200 IN SVCB 1 dot.example.net ( > > alpn=3Ddot port=3D8530 ipv4hint=3D203.1.113.1) > > > Where the ipv4hint refers to something they control. They then prox= y > the > > TLS connection to the true DoT server. Because the SAN only needs t= o > > contain the Unencrypted Resolver address and *not* the Encrypted > Resolver > > address, then this will succeed, with the result that the client ge= ts > > different > > data than it would if the attacker had not been present. This raise= s > several > > questions: > > So the TLS connection is intact. > The client is connected to the correct destination, but resolver sees the > attacker's origin IP rather than the client's address. > Correct. > > 1. Do we think this is bad? > > It sounds like classic NAPT to me. > Well, sort of. In non-adversarial NAPT, the client's apparent address reflects its position in the network but that's not true here. > 2. If the answer to (1) is yes, how do we redefine equivalence to > cover it? > > 3. What does DEER need to do to stop it? [Off the top of my head, > > perhaps have the ER's address also be in the SAN field of the cert > and > > check that] > > That would work. > > Another possibility is that the server should never believe the origin IP= , > but rather the client should tell the server of it's address inband. > > I believe that the is a spec for this, but I don't have the dns-fu anymor= e > to > remember which one it is. > Hmm... Absent something like STUN, clients don't necessarily know their apparent (server reflexive) address but only their local (host) address. And even if you use STUN, there's no guarantee that the NAT will have consistent address bindings. It might have an address-dependent mapping. -Ekr > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > --0000000000005d4ee905b42ed896 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Nov 15, 2020 at 4:50 PM Micha= el Richardson <mcr+ietf@sande= lman.ca> wrote:

Eric Rescorla <ekr@rtf= m.com> wrote:
=C2=A0 =C2=A0 > Now, if that DoT resolver provides different responses b= ased on the client's
=C2=A0 =C2=A0 > apparent IP address, then an on-network attacker can ser= ve their own record:

=C2=A0 =C2=A0 > _dns.example.net=C2=A0 7200=C2=A0 IN SVCB 1 dot.example.ne= t (
=C2=A0 =C2=A0 > alpn=3Ddot port=3D8530 ipv4hint=3D203.1.113.1)

=C2=A0 =C2=A0 > Where the ipv4hint refers to something they control. The= y then proxy the
=C2=A0 =C2=A0 > TLS connection to the true DoT server. Because the SAN o= nly needs to
=C2=A0 =C2=A0 > contain the Unencrypted Resolver address and *not* the E= ncrypted Resolver
=C2=A0 =C2=A0 > address, then this will succeed, with the result that th= e client gets
=C2=A0 =C2=A0 > different
=C2=A0 =C2=A0 > data than it would if the attacker had not been present.= This raises several
=C2=A0 =C2=A0 > questions:

So the TLS connection is intact.
The client is connected to the correct destination, but resolver sees the attacker's origin IP rather than the client's address.

Correct.

=C2=A0
=C2=A0 =C2=A0 > 1. Do we think this is bad?

It sounds like classic NAPT to me.

Well= , sort of. In non-adversarial NAPT, the client's apparent address refle= cts its position in the network but that's not true here.

=C2=A0 =C2=A0 > 2. If the answer to (1) is yes, how do we redefine equiv= alence to cover it?
=C2=A0 =C2=A0 > 3. What does DEER need to do to stop it? [Off the top of= my head,
=C2=A0 =C2=A0 > perhaps have the ER's address also be in the SAN fie= ld of the cert and
=C2=A0 =C2=A0 > check that]

That would work.

Another possibility is that the server should never believe the origin IP,<= br> but rather the client should tell the server of it's address inband.
I believe that the is a spec for this, but I don't have the dns-fu anym= ore to
remember which one it is.

Hmm... Absent= something like STUN, clients don't necessarily know their apparent (se= rver reflexive) address but only their local (host) address. And even if yo= u use STUN, there's no guarantee that the NAT will have consistent addr= ess bindings. It might have an address-dependent mapping.
-Ekr


--
Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O ( IPv6 I=C3=B8T co= nsulting )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sandelman Software Works Inc, Otta= wa and Worldwide
--0000000000005d4ee905b42ed896-- From nobody Sun Nov 15 23:33:41 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53193A14D3 for ; Sun, 15 Nov 2020 23:33:38 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 EgO3OanXazcO for ; Sun, 15 Nov 2020 23:33:35 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63DB33A15D9 for ; Sun, 15 Nov 2020 23:33:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id B3FA5389EC; Mon, 16 Nov 2020 02:33:47 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uI8vNlOi18Iw; Mon, 16 Nov 2020 02:33:47 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 26096389EB; Mon, 16 Nov 2020 02:33:47 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C0E5757A; Mon, 16 Nov 2020 02:32:59 -0500 (EST) From: Michael Richardson To: Eric Rescorla , ADD Mailing list In-Reply-To: References: <12463.1605487844@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Add] Review of draft-pauly-add-deer-00.txt+ X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 07:33:39 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eric Rescorla wrote: >> > 1. Do we think this is bad? >> >> It sounds like classic NAPT to me. >> > Well, sort of. In non-adversarial NAPT, the client's apparent address > reflects its position in the network but that's not true here. That's an interesting term, "non-adversarial NAPT". >> 2. If the answer to (1) is yes, how do we redefine equivalence to >> cover it? >> > 3. What does DEER need to do to stop it? [Off the top of my head, >> > perhaps have the ER's address also be in the SAN field of the cert >> and >> > check that] >> >> That would work. >> >> Another possibility is that the server should never believe the orig= in IP, >> but rather the client should tell the server of it's address inband. >> >> I believe that the is a spec for this, but I don't have the dns-fu a= nymore >> to >> remember which one it is. >> > Hmm... Absent something like STUN, clients don't necessarily know the= ir > apparent (server reflexive) address but only their local (host) addre= ss. > And even if you use STUN, there's no guarantee that the NAT will have > consistent address bindings. It might have an address-dependent mappi= ng. Noting that this is all IPv4-specific, and such a case, the non-adversarial NAPT and/or ISP provided CGN could be moving the apparent client IP all over the place. So I don't really think it is an issue in IPv4: it's all fiction anyway. The same is not true in IPv6: we could reasonably detect such adversarial N= APT. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+yKysACgkQgItw+93Q 3WUvqgf/f6PSTAxrSJHFbeKcWhHC1bmYDeQFYlptoVzM/ciOnoj2Ta4OTxFVOVtk 8OZdZhtxmB7L37gKDSECvDZkHjqqpRZDdhngzYFblr/Y40ZowkU049R98GkEQO4/ Yi1nMlY1g8wPtvPukVYLTZdzVOJamEh/mJ10N05ZaTJsPyh8iz+yBaNHAbCLj9S+ OsQeymnDWN+6hVutvWjgKkKUg4wR5UY59NctyjXhntyBBzpI9yq8EMQzEkHaG76W A9MvzICuCXTY3jGy+a7blEH0MK8+IUi826iheM52vKEGOjXNmndwnyi/2bIjFnb5 TM8h3LfqAkIzO2pfc5usQ8Y/j54gMg== =k1NF -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 16 00:17:58 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9413A158D for ; Mon, 16 Nov 2020 00:17:56 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=portfast.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 nc8frb-xEzuz for ; Mon, 16 Nov 2020 00:17:54 -0800 (PST) Received: from mail.portfast.net (mail.portfast.net [IPv6:2a03:9800:20:1::2]) (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 43AC43A1582 for ; Mon, 16 Nov 2020 00:17:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=portfast.net; s=dkim; h=Content-Transfer-Encoding:Content-Type:MIME-Version :Date:Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=0rzKAHAoCuWIgxpIFMSxx6gI0Ucr8/7cKCOiyvzDE+8=; b=jgVqy9WegphPDxJOv7VXaT/2mZ 9c/g/usX6CARpHNSRctIXbX4IXa1BnC1jICAIdUUOz2Yk5y/z5yCOBYnTAgVo5S+3bFyglRM+QY8T 7s5/qbWauv5TvMd8xGNvecJDr/zk6WDhPpLqQV9mt9jNl9d7kat/hq1w/5ujm0FQJf0E=; Received: from 216-213-177-102.customer.gigaclear.net ([216.213.177.102]:65328 helo=Rays-MacBook-Pro.local) by mail.portfast.net ([188.246.200.9]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1keZhv-0005LH-Ry (Exim 4.89) for add@ietf.org (return-path ); Mon, 16 Nov 2020 08:17:51 +0000 To: "add@ietf.org" From: Ray Bellis Message-ID: <8c3c0645-91d5-9631-3277-923c58846a91@bellis.me.uk> Date: Mon, 16 Nov 2020 08:17:51 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: [Add] DEER and CPE resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 08:17:56 -0000 You may find some useful background here. I did a lot of research into the behaviour of CPE "resolvers" back in 2008 or so, which led to RFC 5625 and SSAC035. Many of the CPE resolvers are just dumb forwarders little better than an AGL. Most don't even support DNS over TCP, and they often have significant other flaws in their DNS compatibility (e.g. no support for EDNS). I did also write a draft which is somewhat similar to DEER, albeit it was constrained to only return IPv4 or IPv6 addresses for a resolver. It was intended to support the case (as Martin just alluded to in the WG session) where the "dumb DNS proxy" just forwards the query for a special-use domain to the network-provided upstream resolver. draft-bellis-dns-recursive-discovery-00 Ray From nobody Mon Nov 16 00:42:30 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24AFA3A160D for ; Mon, 16 Nov 2020 00:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQzWW3oKkjrs for ; Mon, 16 Nov 2020 00:42:20 -0800 (PST) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F8993A16C7 for ; Mon, 16 Nov 2020 00:41:42 -0800 (PST) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 6DAA02421544 for ; Mon, 16 Nov 2020 08:41:40 +0000 (UTC) From: Jim Reid Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) Message-Id: <394A540C-81A8-4F86-8E62-FADC4A820D81@rfc1035.com> Date: Mon, 16 Nov 2020 08:41:39 +0000 To: ADD Mailing list X-Mailer: Apple Mail (2.3445.9.7) Archived-At: Subject: [Add] equivalence definition X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 08:42:28 -0000 The point I didn=E2=80=99t get to make at the mike is using =E2=80=9Ctwo = or more resolvers operated by the same entity=E2=80=9D as the definition = of equivalence probably doesn=E2=80=99t work: the captive portal at = $coffeeshop, enterprise nets that let some but not all users resolve = names on the public Internet, local forwarders/proxies that send Do53 = and DoH queries to different upstream servers, etc. Although this definition might be a good enough starting point, I think = there will be too many corner cases to make this apply in the general = case. From nobody Mon Nov 16 01:06:35 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575A83A16A8 for ; Mon, 16 Nov 2020 01:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.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 NgoO1BuoPrGr for ; Mon, 16 Nov 2020 01:06:27 -0800 (PST) Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 DA7BE3A1652 for ; Mon, 16 Nov 2020 01:06:21 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id 3643C6A310; Mon, 16 Nov 2020 10:06:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1605517577; bh=oe/p0qHuThuNBZiy+p5uqFmEz0UEj6BPmwfp1WYzAkE=; h=Date:From:To:In-Reply-To:References:Subject:From; b=l1siDh71nYeCvuo6CPfx7jrxzvrBX6TVWbiygAjvhCz7FEUsTkrA2EqQNz05lsKW0 DwOE3HmCFVO6h57rZMJEktjqkrDlfp/RcxFZbS7OtFk4Kza8RMfHg+yBTCzenriRqt rK/KmQeHCPY8sHOq+1WEcMgXvxpHnHxoOKzfPCTs1YsOnxOPycYBqsd/I16BWpEjbU XIYRzsSXmuSmhRl+D0ZQNNuHjAZQzDJY0RFmsm6Dvpsjj4waMpDL8VwXBpsoK5rnp1 i7wwc/oNd6MAIuAkLqAV25Qrlrqsva7sl3lqYH1u7hcfutf7iOPqBQ7Y54p7BmbZqI SERvuc/i+kdGw== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 270BD3C0386; Mon, 16 Nov 2020 10:06:17 +0100 (CET) Date: Mon, 16 Nov 2020 10:06:16 +0100 (CET) From: Vittorio Bertola To: Jim Reid , ADD Mailing list Message-ID: <163676509.38755.1605517577055@appsuite-gw2.open-xchange.com> In-Reply-To: <394A540C-81A8-4F86-8E62-FADC4A820D81@rfc1035.com> References: <394A540C-81A8-4F86-8E62-FADC4A820D81@rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.4-Rev10 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: Subject: Re: [Add] equivalence definition X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 09:06:34 -0000 > Il 16/11/2020 09:41 Jim Reid ha scritto: >=20 > =20 > The point I didn=E2=80=99t get to make at the mike is using =E2=80=9Ctwo = or more resolvers operated by the same entity=E2=80=9D as the definition of= equivalence probably doesn=E2=80=99t work: the captive portal at $coffeesh= op, enterprise nets that let some but not all users resolve names on the pu= blic Internet, local forwarders/proxies that send Do53 and DoH queries to d= ifferent upstream servers, etc. >=20 > Although this definition might be a good enough starting point, I think t= here will be too many corner cases to make this apply in the general case. IMHO the fundamental problem is that "equivalent resolvers" is a policy con= cept, so it is very hard to define it precisely in technical terms.=20 For example, building on ekr's comment on the DEER draft: > Il 15/11/2020 01:12 Eric Rescorla ha scritto: >=20 > S 2. > Equivalent Encrypted Resolver: An Encrypted Resolver which is > considered to provide answers equivalent to a given resolver. > This equivalency can be authenticated with TLS certificates. >=20 > This has the same problem as with draft-box. If the attacker > stands up a resolver that proxies to the given resolver, it would > meet this definition, but would not provide confidentiality, > which is one of the prime motivators for this work. >=20 > I know this kind of thing is difficult to formalize, but I think > we actually need to. There are two properties we need to capture > (1) that your data is only going to the EER (2) that the answers > are somehow similar. Perhaps. In policy terms, the two conditions above (which are correct) become quite = straightforward: 1) moving the DNS resolution service from the resolver to its EER does not = introduce or remove any data controllers or processors, and 2) the EER applies the same query resolution policies as the original resol= ver. I concede that you might need a bit of clarification on the fact that #2 is= n't broken by differences in technical practices such as caching, prefetchi= ng etc. However, the magic of policy language is that being vague is ok and= actually useful, differently from technical specifications. So you could a= dopt a definition like the above and then limit further discussions to corn= er cases where it is not fully clear whether something that the resolver do= es is a "query resolution policy" or not, while being able to proceed in al= l other cases. Also, things could perhaps be easier if we limited ourselves to sub-cases o= f equivalence - for example, to "ISP-equivalent encrypted resolver", i.e. t= he encrypted resolver that is part of the resolver platform to which your D= NS-forwarding home router forwards the queries it receives. This condition = could be technically proven by relying on a SUDN query forwarded through th= e router, though it is unclear whether that could be done securely enough t= o make this definition useful. --=20 Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com=20 Office @ Via Treviso 12, 10144 Torino, Italy From nobody Mon Nov 16 01:15:37 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A573A1629 for ; Mon, 16 Nov 2020 01:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 6cFFxx1qGfJ5 for ; Mon, 16 Nov 2020 01:15:32 -0800 (PST) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 84C323A162D for ; Mon, 16 Nov 2020 01:15:32 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id c17so17793895wrc.11 for ; Mon, 16 Nov 2020 01:15:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ltK/tgOlaRV4fpqr4SvfeVBvTgmEieFAcrFr7K2tYxo=; b=r7M7SqwWyUpiDTHdoBJHR6E5GxO9zaz39+Nemh67VJePMWhQGquLcVofGJewMDySDv sO4peqmrFnRF90kNdhnIs2OrmoDVCtr+Wio6b5RommoqoAhH3UnPnLumRMH19gVUimDT yN5Kwnc487o175KKf/XJXXEtnbQGbdDaSeFTgINKspiVz6vdNlVFkREn1TLD+jbhUiqY zotrQKRszsbOYlnIvXymubzyWOhrqSzTzK1oXjl+8lXjRCfEzpeSqg/+bGWb9s4Tm0OU NEwJYTlefq9xCDVHMNa0EktHhLdxfL6izhZ+EZV7O9FiqFVrHt3JzNR70hpafh1OtzM8 Ly1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ltK/tgOlaRV4fpqr4SvfeVBvTgmEieFAcrFr7K2tYxo=; b=H6EQgZcjkCl8zDT5bfTQyw6EHLxopCcZyclGpNH8uKOzv6ulenxOiRandfvrEHpKAi 2EIsjqXEqIiQKlSQJHl7fcEipJ9uAm4FwYYhRKIiJTImv1ft+a7CRVzNaSRfxQqSASXW 2Fe4szVKAv75DGI5mATGmrg+7+tToH6gmFQ2kY9frGsubKFWxNGoqBVIgWP6/KmEd7Y0 BoIrOW/Obxi6yCz6b+UMXRPMJ6ND7hE+F1KRwt4UlK/R05s+hRugqMIy/UrZAQ5EgnKo As6011XO98Bg+Yke1in3caMIoG0V348J3Z4m6Os15CEPh0xHfjihkOuaSdNx6zZhsP5x u5Mw== X-Gm-Message-State: AOAM533foBnmhOJd3uj84DyXTN4Sr92J8hc8iikcCdeLW+SZMGgsTxVb 3F7X/7lXep4TraoOUF/QnWaA08JhGjeFgEO0KmScCQ== X-Google-Smtp-Source: ABdhPJziz0mWqOrPkbNs5X0L6MSisYY/tsaR/y4Huaz/vpq/o5aOXXSZFM6oO8RS3UIZN45LS7P5nkyoynEPej2/VFE= X-Received: by 2002:adf:eb4f:: with SMTP id u15mr18048080wrn.165.1605518130492; Mon, 16 Nov 2020 01:15:30 -0800 (PST) MIME-Version: 1.0 References: <394A540C-81A8-4F86-8E62-FADC4A820D81@rfc1035.com> In-Reply-To: <394A540C-81A8-4F86-8E62-FADC4A820D81@rfc1035.com> From: Eric Orth Date: Mon, 16 Nov 2020 04:15:19 -0500 Message-ID: To: Jim Reid Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000d9af3905b435d1e7" Archived-At: Subject: Re: [Add] equivalence definition X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 09:15:36 -0000 --000000000000d9af3905b435d1e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable And the points that I didn't get to make before that exciting conclusion: I think the best answer is the combination of all these "you're missing this side of it" points everybody is making. Considering what's best for the end user, overall, I think there are two big areas to consider to really answer the question of whether or not an upgrade will be a good idea for that user. 1. Will the encrypted resolver keep working for the user as well as the unencrypted resolver. This generally doesn't mean exact equivalence (th= e user doesn't care if resolvers have slight differences due to cached results) but just generally that if things were working well for the use= r before, they need to keep working and not feel broken to the user. This includes stuff like reasonable performance after upgrade, any private na= mes the user was relying on still being resolvable, any user-desired filteri= ng still being in place, etc. 2. Will the encrypted resolver meet the user's trust/privacy expectations. If the user had any hand in choosing the unencrypted resolver (and clients often have no way of knowing whether or not that w= as the case), they would have every right to be upset if they get switched = to a different resolver that isn't trustworthy for the user. Need to ensur= e the same assignment of trust is maintained, or at least that a different switched-to resolver has high privacy standards. How do we technically determine a resolver meets these needs? I don't know. It's hard. For Chrome, we've found that "same provider" (same legal entity controlling both resolvers) is a decent (but definitely not perfect) technical signal. It's the same entity a user has potentially chosen to trust, and while not guaranteed, the provider generally wants to provide the same working experience to their users, at least if they're suggesting an upgrade should be made. On Mon, Nov 16, 2020 at 3:43 AM Jim Reid wrote: > The point I didn=E2=80=99t get to make at the mike is using =E2=80=9Ctwo = or more resolvers > operated by the same entity=E2=80=9D as the definition of equivalence pro= bably > doesn=E2=80=99t work: the captive portal at $coffeeshop, enterprise nets = that let > some but not all users resolve names on the public Internet, local > forwarders/proxies that send Do53 and DoH queries to different upstream > servers, etc. > > Although this definition might be a good enough starting point, I think > there will be too many corner cases to make this apply in the general cas= e. > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000d9af3905b435d1e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And the points that I didn't get to make before that e= xciting conclusion:

I think the best answer is the combi= nation of all these "you're missing this side of it" points e= verybody is making.=C2=A0 Considering what's best for the end user, ove= rall, I think there are two big areas to consider to really answer the ques= tion of whether or not an upgrade will be a good idea for that user.
<= div>
  1. Will the encrypted resolver keep working for the user as well a= s the unencrypted resolver.=C2=A0 This generally doesn't mean exact equ= ivalence (the user doesn't care if resolvers have slight differences du= e to cached results) but just generally that if things were working well fo= r the user before, they need to keep working and not feel broken to the use= r.=C2=A0 This includes stuff like reasonable performance after upgrade, any= private names the user was relying on still being resolvable, any user-des= ired filtering still being in place, etc.
  2. Will the encrypted resolv= er meet the user's trust/privacy expectations.=C2=A0 If the user had an= y hand in choosing the unencrypted resolver (and clients often have no way = of knowing whether or not that was the case), they would have every right t= o be upset if they get switched to a different resolver that isn't trus= tworthy for the user.=C2=A0 Need to ensure the same assignment of trust is = maintained, or at least that a different switched-to resolver has high priv= acy standards.
How do we technically determine a resolver mee= ts these needs? I don't know.=C2=A0 It's hard.=C2=A0 For Chrome, we= 've found that "same provider" (same legal entity controlling= both resolvers) is a decent (but definitely not perfect) technical signal.= =C2=A0 It's the same entity a user has potentially chosen to trust, and= while not guaranteed, the=C2=A0provider generally wants to provide the sam= e working experience to their users, at least if they're suggesting an = upgrade should be made.

On Mon, Nov 16, 2020 at 3:43 AM Jim Reid= <jim@rfc1035.com> wrote:
<= /div>
The point I didn=E2= =80=99t get to make at the mike is using =E2=80=9Ctwo or more resolvers ope= rated by the same entity=E2=80=9D as the definition of equivalence probably= doesn=E2=80=99t work: the captive portal at $coffeeshop, enterprise nets t= hat let some but not all users resolve names on the public Internet, local = forwarders/proxies that send Do53 and DoH queries to different upstream ser= vers, etc.

Although this definition might be a good enough starting point, I think the= re will be too many corner cases to make this apply in the general case.
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000d9af3905b435d1e7-- From nobody Mon Nov 16 01:27:17 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B743A1666 for ; Mon, 16 Nov 2020 01:27:08 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 a1UrpfBfihNY for ; Mon, 16 Nov 2020 01:27:04 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640105.outbound.protection.outlook.com [40.107.64.105]) (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 BF8DA3A168E for ; Mon, 16 Nov 2020 01:27:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MXZd6eiDeVfX8NY8PqJcOwEjy1PekgxcP8a6QuKWJ7KNaIIUrSsupUslQAT1r37Muz07JsQ/YeMcJEmzBhvHlQR+i54wZ+Tqf/OtfSXLvYnKSmUGfzwMUvpepGX2tSyfP9GBIOV+ri99PIo8KQgRiubp3vt6FqPJ+i6TNIzput4Hh/UF86eeqODQXq/YbQNEibW8fB4YDcNZn4HlxVyL8o4pvimNTsckvlb36835OrZ6sJfIMpMyyOnegO0PU4jo2LFNhLZO5ZNOy3zxN0bE9EJCXVXNjhpp981X2oET1afK4UxCp7vM05U4uL+FBNS/aBsMOTiRK7DwQVnErmhNPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZzGCWjbPk4FUJCLz4LaIE75WukBY1JCYXnYal1uY0K0=; b=ZiLpQlTIqGc1Zgcwp91I3jgpU9nWLXYBV+uH/RpF0mUXhrnlE9saqXjbPjjKLd3XXC+fWJAFckYp/9CLWQs77V5SECsk5xfvj6Kf1EJRXoGEguczLVgFngIFvawy/3uXBw6851bzJA41ZjslmdLGQmQXEdeFptS4ikXE29utw57YOJNSFvosxnD3Dgf4ZNn/H1lkFb4S4gqaB9BpTCLH8cTGwpFyJepzBuHSm3aUi0mh6bNDLK0HQGqyAFgF81j+UqI0iH1lDCKuhzbNTP7B4XCQU3919ogxGQPAGnzjvu+aKeYBAblTgyNx6ERO+4UUQwFJHxpVg0tDKopyWBut7w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZzGCWjbPk4FUJCLz4LaIE75WukBY1JCYXnYal1uY0K0=; b=G/zSMhOBv8OD1s8hiZWjMTRJ3pFVD+bzcP5tYZbanjiFiTDnmpxdW0Kdkj/2IuPoDoDisFIJCXQVTWDOaNP+yxKYNH5lfkmLaWkzWSUInj2nYyktc/eGQ+zheTP3skNUKUhQxvz11KXwgpAwFOwdJaZlhBG2UlHHN6gAIsUyl7s= Received: from (2603:10b6:610:ac::24) by CH2PR00MB0778.namprd00.prod.outlook.com (2603:10b6:610:6c::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3618.0; Mon, 16 Nov 2020 09:26:55 +0000 Received: from CH2PR00MB0664.namprd00.prod.outlook.com ([fe80::845b:5539:5614:dc14]) by CH2PR00MB0664.namprd00.prod.outlook.com ([fe80::845b:5539:5614:dc14%3]) with mapi id 15.20.3621.000; Mon, 16 Nov 2020 09:26:55 +0000 From: Tommy Jensen To: "ericorth=40google.com@dmarc.ietf.org" , "jim@rfc1035.com" CC: "add@ietf.org" Thread-Topic: [EXTERNAL] Re: [Add] equivalence definition Thread-Index: AQHWu/kUmSA4IvBN+0uqZfDMqPdfl6nKezyk Date: Mon, 16 Nov 2020 09:26:55 +0000 Message-ID: References: <394A540C-81A8-4F86-8E62-FADC4A820D81@rfc1035.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-11-16T09:26:54.849Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.35.73.96] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 74e65db6-090b-4c4d-404e-08d88a11c27d x-ms-traffictypediagnostic: CH2PR00MB0778: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0J3h5Rf1m7mqS0eSStbVB0s27JIitDcHQd8io41jFaZQ2n2OACuyzhWEO6M9LD3ew2NQh/gg3/dsKI60P53za9C1K1AOBjtvaKSIXD3DcKWiyb9Q4DOV5eL4eK1KWKA7y9pIT3B6t3TEHPASo4HaGB3ij59okCZt8koD8tqcPdvwtaQp3AxZo0erEiW+6sACmuET3vFL7j1C7eu8ZjFRYNtawnODkA8fpOxUKF6kKnTjG16aYfXYsSl6/Bffo02Yw//URzTxZNN7GxLtZsQGKjzzbbNQnRbYqQ3yG3ge6ZhPSU1zZQlWJKkr5aHEwGCXfXnyPLsmzeHycxTlNnIwkYsP60NKRKK6gQfJ8CPs2biIzFCW0MfbZc8za5HlO/CsCKKHCyr80HZt2hB8hi0bOg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0664.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(346002)(396003)(376002)(136003)(66446008)(64756008)(66556008)(66476007)(2906002)(91956017)(66946007)(66574015)(76116006)(83380400001)(166002)(7696005)(186003)(52536014)(53546011)(5660300002)(33656002)(26005)(110136005)(6506007)(82960400001)(316002)(82950400001)(55016002)(8676002)(8936002)(19627405001)(71200400001)(9686003)(86362001)(10290500003)(478600001)(8990500004)(966005)(4326008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?pY4+RWtm7V9RSTsj1gqLQhz/O14lwBC0XQAczJ1ghL9gMmIrqYs0qYel?= =?Windows-1252?Q?vcEoqJdbCMfUu755bZA3HSzcVSg8FgYTR4wjjrRRglCKN4+qc+BLnrDJ?= =?Windows-1252?Q?FwTdfj8A5JG6q+j6dlK3d7G9b4kcZ4znlGuKyTQExukRDqEqSv5gr4Ty?= =?Windows-1252?Q?JqSurCp0BpmusHJpGR5tEHRJ5Tqnd5hvFRJI/M8+DUkAWSWQFFQ0TEbH?= =?Windows-1252?Q?hNHbU6qM+4WLWrjtW2YFPmt7Lgy/MbqiBIrazW4JO8XmE1fPDOgAZABy?= =?Windows-1252?Q?gq5qBMKz9ir5jT6bootoZ+IBhJYPv4jfpAp4Bs8kjlWz+kWMhtsQ0GPH?= =?Windows-1252?Q?D71oKFe3sq/lUsTNyZ3q57p577u3ScZ7KIR7ToDUMDgxKJm97vib9UQq?= =?Windows-1252?Q?iAVXdzbAR4TUDoS0sjKQcTzI1L++aIXHUCbnckrUrslesJyNdtpc7G2J?= =?Windows-1252?Q?eEkxxgpRRiSGEf7M/jzRS+90RYR+VMCRltlD7AD5VreilFMFrZQEqjfS?= =?Windows-1252?Q?zPJvHUgFk9uyJB1V+/RF093Bbin3y/7Z8xhFf7G64xbeVjOrQQWRJtOT?= =?Windows-1252?Q?233qhm9I1Xtsl0KzhdSunp1+bYGG10Q87lps4t50SYievkGfvUcbbsnp?= =?Windows-1252?Q?Msl+NM03afezUemCavd5TB/CwyVsjEY65Eh5l79VmFQdZVJ+jzIaH84Q?= =?Windows-1252?Q?YhVS6PMh4nzVmW1AfBmmapOqz09aE0sayJ3Y8vg06RgtXXXGnZ6CMGay?= =?Windows-1252?Q?+Ie3BiBesoFyo5Gvy0f0uKXKRU575i0ZvxlOPxKCriGeJtRNo8DuI13c?= =?Windows-1252?Q?wy58I+VzwuM92q/1qQbEK4he0zsPkVuFsuGUO5zz6j1bxWfUhVliIeOO?= =?Windows-1252?Q?jABkQLjsj+lWMRi4Xopwstx/FaQeuWzqUBM8lsotKLg1QAADLSPrMVSE?= =?Windows-1252?Q?LwKacKmoW/PbJX8+tcitCQ6blgxlCQcRC5yOmRv15MGBCWqIc4TxP+qT?= =?Windows-1252?Q?URcmfUjIOkis1aMga57eCuAyvMXyTncHvoQpU+DRdc4UqnfUDk8=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR00MB066484A456C204A50556B25FFAE31CH2PR00MB0664namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0664.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 74e65db6-090b-4c4d-404e-08d88a11c27d X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2020 09:26:55.3776 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: et5GWbtzLjs2uZycvRtisfQGX/xAanoCEfZRl5qyakAVMSBDJUR7ugdv5DoQm7Oorak6icZIsr0VjnPVYxkwXg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0778 Archived-At: Subject: Re: [Add] [EXTERNAL] Re: equivalence definition X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 09:27:15 -0000 --_000_CH2PR00MB066484A456C204A50556B25FFAE31CH2PR00MB0664namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > It's the same entity a user has potentially chosen to trust, and while no= t guaranteed, the provider generally wants to provide the same working expe= rience to their users, at least if they're suggesting an upgrade should be = made. This I think is key nuance to highlight. If the upgrade mechanism is verifi= able as the same controlling entity, then similar functionality should be a= given. I do think it's fair per the discussion to define EER as "same func= tionality" but I think adding "same entity" as an AND clause prevents this = from becoming a policy discussion. Example: DNS Provider Foo offers "no edits" DNS as well as "ad blocking" an= d "kid friendly" functionalities. If a client asks for the EER from an ad-b= locking Do53 Foo server, then they should end up with the configuration for= an ad-blocking EER also from Foo. To enable going from ad-blocking Do53 Foo to ad-blocking EER Bar (if we don= 't add "same entity" clause to EER definition) would require Foo and Bar ca= n adhere to some shared definition of what ad-blocking is, opening the poli= cy can of worms (how do we verify behavior?). Same entity means we side ste= p that issue. Thanks, Tommy ________________________________ From: Add on behalf of Eric Orth Sent: Monday, November 16, 2020 1:15 AM To: Jim Reid Cc: ADD Mailing list Subject: [EXTERNAL] Re: [Add] equivalence definition And the points that I didn't get to make before that exciting conclusion: I think the best answer is the combination of all these "you're missing thi= s side of it" points everybody is making. Considering what's best for the = end user, overall, I think there are two big areas to consider to really an= swer the question of whether or not an upgrade will be a good idea for that= user. 1. Will the encrypted resolver keep working for the user as well as the = unencrypted resolver. This generally doesn't mean exact equivalence (the u= ser doesn't care if resolvers have slight differences due to cached results= ) but just generally that if things were working well for the user before, = they need to keep working and not feel broken to the user. This includes s= tuff like reasonable performance after upgrade, any private names the user = was relying on still being resolvable, any user-desired filtering still bei= ng in place, etc. 2. Will the encrypted resolver meet the user's trust/privacy expectation= s. If the user had any hand in choosing the unencrypted resolver (and clie= nts often have no way of knowing whether or not that was the case), they wo= uld have every right to be upset if they get switched to a different resolv= er that isn't trustworthy for the user. Need to ensure the same assignment= of trust is maintained, or at least that a different switched-to resolver = has high privacy standards. How do we technically determine a resolver meets these needs? I don't know.= It's hard. For Chrome, we've found that "same provider" (same legal enti= ty controlling both resolvers) is a decent (but definitely not perfect) tec= hnical signal. It's the same entity a user has potentially chosen to trust= , and while not guaranteed, the provider generally wants to provide the sam= e working experience to their users, at least if they're suggesting an upgr= ade should be made. On Mon, Nov 16, 2020 at 3:43 AM Jim Reid > wrote: The point I didn=92t get to make at the mike is using =93two or more resolv= ers operated by the same entity=94 as the definition of equivalence probabl= y doesn=92t work: the captive portal at $coffeeshop, enterprise nets that l= et some but not all users resolve names on the public Internet, local forwa= rders/proxies that send Do53 and DoH queries to different upstream servers,= etc. Although this definition might be a good enough starting point, I think the= re will be too many corner cases to make this apply in the general case. -- Add mailing list Add@ietf.org https://www.ietf.org/mailman/listinfo/add --_000_CH2PR00MB066484A456C204A50556B25FFAE31CH2PR00MB0664namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
> It's the same entity a user has potentially chosen to trust, and while not guar= anteed, the provider generally wants to provide the same working exper= ience to their users, at least if they're suggesting an upgrade should be m= ade.

To enable = going from ad-blocking Do53 Foo to ad-blocking EER Bar (if we don't add &qu= ot;same entity" clause to EER definition) would require Foo and Bar can adher= e to some shared definition of what ad-blocking is, opening the policy can = of worms (how do we verify behavior?). Same entity means we side step that = issue.
From: Add <add-bounces@i= etf.org> on behalf of Eric Orth <ericorth=3D40google.com@dmarc.ietf.o= rg>
Sent: Monday, November 16, 2020 1:15 AM
To: Jim Reid <jim@rfc1035.com>
Cc: ADD Mailing list <add@ietf.org>
Subject: [EXTERNAL] Re: [Add] equivalence definition
 
And the points that I didn't get to make before that excit= ing conclusion:

I think the best answer is the combination of all these "you're m= issing this side of it" points everybody is making.  Considering = what's best for the end user, overall, I think there are two big areas to c= onsider to really answer the question of whether or not an upgrade will be a good idea for that user.
  1. Will the encrypted resolver keep working for the user as well as the un= encrypted resolver.  This generally doesn't mean exact equivalence (th= e user doesn't care if resolvers have slight differences due to cached resu= lts) but just generally that if things were working well for the user before, they need to keep working and not f= eel broken to the user.  This includes stuff like reasonable performan= ce after upgrade, any private names the user was relying on still being res= olvable, any user-desired filtering still being in place, etc.
  2. Will the encrypted resolver meet the user's t= rust/privacy expectations.  If the user had any hand in choosing the u= nencrypted resolver (and clients often have no way of knowing whether or no= t that was the case), they would have every right to be upset if they get switched to a different resolver that isn't trustworthy for the u= ser.  Need to ensure the same assignment of trust is maintained, or at= least that a different switched-to resolver has high privacy standards.
How do we technically determine a resolver meets these needs? I don't = know.  It's hard.  For Chrome, we've found that "same provid= er" (same legal entity controlling both resolvers) is a decent (but de= finitely not perfect) technical signal.  It's the same entity a user has potentially chosen to trust, and while not guaranteed, t= he provider generally wants to provide the same working experience to = their users, at least if they're suggesting an upgrade should be made.

On Mon, Nov 16, 2020 at 3:43 AM Jim= Reid <jim@rfc1035.com> wrote:=
The point I didn=92t get to make at the mike is using =93two or more resolv= ers operated by the same entity=94 as the definition of equivalence probabl= y doesn=92t work: the captive portal at $coffeeshop, enterprise nets that l= et some but not all users resolve names on the public Internet, local forwarders/proxies that send Do53 and DoH qu= eries to different upstream servers, etc.

Although this definition might be a good enough starting point, I think the= re will be too many corner cases to make this apply in the general case.
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mai= lman/listinfo/add
--_000_CH2PR00MB066484A456C204A50556B25FFAE31CH2PR00MB0664namp_-- From nobody Mon Nov 16 01:32:09 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7280A3A166B for ; Mon, 16 Nov 2020 01:32:07 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 x6-9GuAOUadP for ; Mon, 16 Nov 2020 01:32:05 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 3B6C43A166A for ; Mon, 16 Nov 2020 01:32:04 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id C5FB92815D2; Mon, 16 Nov 2020 10:32:01 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id BFA562815DA; Mon, 16 Nov 2020 10:32:01 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id B80BB2815D2; Mon, 16 Nov 2020 10:32:01 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id B408760793AA; Mon, 16 Nov 2020 10:32:01 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id A33BC3FFCE; Mon, 16 Nov 2020 10:31:36 +0100 (CET) Date: Mon, 16 Nov 2020 10:31:36 +0100 From: Stephane Bortzmeyer To: Jim Reid Cc: ADD Mailing list Message-ID: <20201116093136.GA21460@nic.fr> References: <394A540C-81A8-4F86-8E62-FADC4A820D81@rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <394A540C-81A8-4F86-8E62-FADC4A820D81@rfc1035.com> X-Operating-System: Debian GNU/Linux 10.6 X-Kernel: Linux 4.19.0-12-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: No, tests=bogofilter, spamicity=0.356631, version=1.2.2 X-PMX-Version: 6.4.9.2830568, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.11.16.92117, AntiVirus-Engine: 5.75.0, AntiVirus-Data: 2020.8.24.5750002 Archived-At: Subject: Re: [Add] equivalence definition X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 09:32:07 -0000 On Mon, Nov 16, 2020 at 08:41:39AM +0000, Jim Reid wrote a message of 11 lines which said: > The point I didn’t get to make at the mike is using “two or more > resolvers operated by the same entity” as the definition of > equivalence probably doesn’t work: Another case where it doesn't work is when the same entity offers different services (one lying and one not, for instance), which is common among public resolvers , etc I suggest to not just say "equivalent" but be more specific: "with equivalent answers". Equivalent answers being defined by the user's use cases. If resolver A censors SciHub and resolver B does not, they do not yield equivalent answers. If resolver A sees gmail.com at 2a00:1450:400e:809::2005 and resolver B sees it at 2a00:1450:4007:816::2005, they probably give equivalent answers, as far as the ordinary user is concerned. "Equivalent" is too loaded to be used alone. From nobody Mon Nov 16 01:39:36 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC533A1686 for ; Mon, 16 Nov 2020 01:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=Ea6jnwG/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HCiEuPhV 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 ouw7yezuJIDs for ; Mon, 16 Nov 2020 01:39:33 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF0913A1683 for ; Mon, 16 Nov 2020 01:39:21 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 442515C01A3 for ; Mon, 16 Nov 2020 04:39:21 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Mon, 16 Nov 2020 04:39:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm3; bh=2Hq6H ySCC4fXD6MB9k5Y8h0k6nmW1TNrgxs5Vng4Nc0=; b=Ea6jnwG/aYHfj4BQ08ibt KoLhgwX3X4UQ9hJgSj5u1LhnjW4vxS7LtUyV46Ooi162czaK/cliNBsh1sbQHbff StBGLxYaU5bEnAaz6EeATg0hvKuJzW8LsH74knN9yDbZ5KAoPWqIbEV2zwGrCJcy rtKVDLEZb1zju44s3QWvjTrrYK7wVltyaFFa1SpX8zaQ7/41PA8S/TlxcDx1pqHI a33DV7/S22G4ILXfjjgF6n8C+KgPlcTfQPT16oGifkR9nqfQbXw4UsVZAH92NiMz v4KhNRrFuOfyET14pyIziHtxAibm7J6wTVvTD18y/cgHGGxw6wu2t0HqaZgp/qLg A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=2Hq6HySCC4fXD6MB9k5Y8h0k6nmW1TNrgxs5Vng4N c0=; b=HCiEuPhVQG9mbYs5effbumPFhwI2EB/Ibu33ACkkQIhK68CaSxRqsJeUn QuXo0tZ5Q0ATl9LX3Uk46MoPSCLTNbb3kRQ8ZGafsYkNJzN6I0xVLFya3FqOypQS /n7zoAjl1bYGGVblZXx9FETZUnVMsX7ghY6bC6ZBdPFu/GWcMMLmzpA0nDZN5h5M qbS0xM7FNHA6zvprn3rc/YEDsJiFe1XKOGptxob9HhHmLyzcZJEoVwR7q+omzDVR AJO1h2gU31bEnf0XjgDFOkoqgr4QMuZtqjkF4bt2oU05JzTBnO/Do7lGvSEZQdTT jSadwqUqtaGnnWo2WvOccSZNQ4+Ow== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefuddgtdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgoufhushhpvggtthffohhmrghinhculdegledmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfofgr rhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenuc ggtffrrghtthgvrhhnpeeufeevleffudefudffgffgtdegteeguddtheetfeeuuddtffei udeiiedtkeeuheenucffohhmrghinhepqhhurgguledrnhgvthdphigrnhguvgigrdgtoh hmpdgtlhhouhgufhhlrghrvgdrtghomhdpihgvthhfrdhorhhgnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphi drnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E771F200BD; Mon, 16 Nov 2020 04:39:20 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-570-gba0a262-fm-20201106.001-gba0a2623 Mime-Version: 1.0 Message-Id: <680ed8e1-bdb9-4ed9-aa12-7c0efe2bb1da@www.fastmail.com> In-Reply-To: <20201116093136.GA21460@nic.fr> References: <394A540C-81A8-4F86-8E62-FADC4A820D81@rfc1035.com> <20201116093136.GA21460@nic.fr> Date: Mon, 16 Nov 2020 20:38:58 +1100 From: "Martin Thomson" To: add@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Add] equivalence definition X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 09:39:35 -0000 My definition was slightly different: If we assume that either Do53 discovery was perfectly secure, OR that pl= us the Do53 resolver itself were perfectly secure, then - in the presenc= e of a Dolev-Yao attacker and any information obtained from those perfec= tly secure sources, can we provide something that uses TLS and is reason= ably secure? I think that we can, but not in the presence of old DNS forwarders that = can't be updated. What I heard from David Schinazi (though these were I think Eric Orth's = figures) was that the environment was such that none of our existing sol= utions would work and we would need a looser definition if we were to be= able to offer DoH/DoT to most users. If we don't accept something a li= ttle more opportunistic, we only get ~15% of people (assuming that datas= et is representative, which I believe it should be). On Mon, Nov 16, 2020, at 20:31, Stephane Bortzmeyer wrote: > On Mon, Nov 16, 2020 at 08:41:39AM +0000, > Jim Reid wrote=20 > a message of 11 lines which said: >=20 > > The point I didn=E2=80=99t get to make at the mike is using =E2=80=9C= two or more > > resolvers operated by the same entity=E2=80=9D as the definition of > > equivalence probably doesn=E2=80=99t work: >=20 > Another case where it doesn't work is when the same entity offers > different services (one lying and one not, for instance), which is > common among public resolvers > > , etc >=20 > I suggest to not just say "equivalent" but be more specific: "with > equivalent answers". Equivalent answers being defined by the user's > use cases. If resolver A censors SciHub and resolver B does not, they > do not yield equivalent answers. If resolver A sees gmail.com at > 2a00:1450:400e:809::2005 and resolver B sees it at > 2a00:1450:4007:816::2005, they probably give equivalent answers, as > far as the ordinary user is concerned. >=20 > "Equivalent" is too loaded to be used alone. >=20 >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > From nobody Mon Nov 16 01:48:11 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C933A16AC for ; Mon, 16 Nov 2020 01:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=microsoft.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 3-DJ0RDqcLjp for ; Mon, 16 Nov 2020 01:48:08 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650096.outbound.protection.outlook.com [40.107.65.96]) (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 B725F3A16AA for ; Mon, 16 Nov 2020 01:48:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gwBuS5tPZ+rK/ShD1TS29WAfNc7HOZakA9Pnaj0zqol6ive3hzo0rDnBIMtDuZw6kXWtNfwLDGo2PRfHeqjtkQN3Wcmm8vzN/UtZkGYKn4ui+m2AXwUsAIMejerem5SZxHrZRxX+wQ9lHUtNup1idC1EdYyQBdHf2AsHBVi1yHBKiVhjbW9q5sVNcdAm/h4BMfs+WTTEQmo3DyIONvFMEpSvYpOG0oJVzDxDzqGhsrIDl6zpXimgXQoFwfZc18v8Ka2CyOsN6LE5WGQv3JtdmmkvQEYoMCheL34R4D8ygVF6WEKWgCx7zESeqTnrHPVPbID34gNAJs48uuqFgwx7YQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o0zieB6YWh/ov6RJFWKmsAUVanIjJDCGm0Hdqhi1NqA=; b=KZVqdeckoaocMbyn6slO7NG/YOQggshvTPcp1lWyai+p4cvIoSGqCxEvQpwzss0K5rG5Lbwfa6uXbkarzbLYPo1yzjTaWFA2Hkla8kYjJoNgetUCEM3I06Q+DCZbQOqACNUl8NGBj6wo+PR57plbkGmeWWnhjj0sGEcns6vuj0RJraSMI4UzLbTzDzq4hSPh6gOOstMtjX7Yx+T8yAO6aQIhIGLhmPXwx5/ZBzK31WZUIIzmVgZmtoWCMFnoJIs6JPACQmLmTikoRuWy7gY7pCXKUFMtokdc5HTIdr2MzuA4sL7FWJ/qf+Rxp8cKptHuXMSKGQr9HLfmzMQCFFupXg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o0zieB6YWh/ov6RJFWKmsAUVanIjJDCGm0Hdqhi1NqA=; b=O+/i/PpV4bKTqiTZX8qP95rvFzGM7p+NGxq/qG2PZllwbguGRQBXBlE1BVnTNIpbdyiXEOUmB+EhIEQ1uHlS03TSIsH0lDUkmsA0QX8Rr3q6Wc6KQqzwPOlumJAAL0xrQs943FwJzh7pHvS8584f8DRUuGpFvND4c+254pNNMMA= Received: from (2603:10b6:610:ac::24) by CH2PR00MB0779.namprd00.prod.outlook.com (2603:10b6:610:66::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3619.0; Mon, 16 Nov 2020 09:48:03 +0000 Received: from CH2PR00MB0664.namprd00.prod.outlook.com ([fe80::845b:5539:5614:dc14]) by CH2PR00MB0664.namprd00.prod.outlook.com ([fe80::845b:5539:5614:dc14%3]) with mapi id 15.20.3621.000; Mon, 16 Nov 2020 09:48:03 +0000 From: Tommy Jensen To: "add@ietf.org" Thread-Topic: EER bootstrapping draft scopes Thread-Index: AQHWu/vzvw8uxJV/2E6LcWkTv+2Aiw== Date: Mon, 16 Nov 2020 09:48:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-11-16T09:48:03.047Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.35.73.96] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 627e5c88-8ad4-4749-f8e4-08d88a14b627 x-ms-traffictypediagnostic: CH2PR00MB0779: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: W6LkSWhqmDUcvwDHObzBpYkp3khTP/NH+6s1lQtxi9TQdAGZ7CsOoMQXAn2DjZC0hVa51TcfsyWcxMTfviyXfeIKB76+NEfMP79RHLPUkGNdWzN/DVuPzfVWYj9jXMb2jGzQvB2inDO5PBjP6HMLxtWbh3JTrXMRYEFgrnerbr8nKgcbY3y3Qk605RUVKktFYd9JEDccMkpCWAKmxVW1CkOmbQx7efgsguQSlg3Luhj1WjEe+SGZd7qkghe0E9kBG5dYQpz7HiNU0533cSPUr0FxO6bcSBFGdS1x4kawJdvdTnywf9tkAzS2UyUphOrH x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0664.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(39860400002)(346002)(136003)(396003)(6506007)(26005)(55016002)(9686003)(7696005)(316002)(8676002)(86362001)(186003)(10290500003)(8936002)(2906002)(6916009)(8990500004)(19627405001)(478600001)(82950400001)(82960400001)(71200400001)(3480700007)(52536014)(66556008)(5660300002)(64756008)(83380400001)(66946007)(76116006)(91956017)(66476007)(66446008)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?1GET0iXrsUXA16PxpD+j3PvrtYjl5tgu71AB3kaeNhEOU4YuKx6+2BxgZe?= =?iso-8859-1?Q?NW6ARjlKJEXpRD0IhWj+6C3dXxlqBhGOIfz3VzndXywJMiiJSz0buRrUss?= =?iso-8859-1?Q?FQTjrXOJJILLz8b+vwUsYKRcx0ZMqov2Tcca/lRRbOXFWYUfviCV9FMYMT?= =?iso-8859-1?Q?tIbMvJ6LXLNYWgnyCt4QdyfA5fRJRq5kp3+CPAMbms2aujQFW5QweDTM3y?= =?iso-8859-1?Q?/iULIB6QkOT6wbFn1ClexCHQmMZpMBIB2Fk1A4E5ZNF2DgiTSWmP8ebLwT?= =?iso-8859-1?Q?gNyZ0PVephdUj/FDaUl3/NK801dTj5emugKq2I+KXag8CR/svzFRrE2oJ/?= =?iso-8859-1?Q?aal1tUhptdj7BL4ubq9LGA2dtNb+/uvoKVOM6Bg1ujl4/Ysqf5xHMYe0PZ?= =?iso-8859-1?Q?m+IBkUj4k1svk/pfOvZZW5+NWdo3UY8wuFDdBs/2QxNAWYiTQicr+yJbmU?= =?iso-8859-1?Q?0+5eV/qG248z07DSu8dN4/t23HOFFVctA44eGCU/PRUyZl1nyANQVaVgpb?= =?iso-8859-1?Q?Eya7KPM7r1Wffa7r/FypQRFacfiGL6OLD1dnR5pZpXxOuAQykOK57RPWJQ?= =?iso-8859-1?Q?URr5QHhSXgtnIqFyYWKkYhv5S04scIqoUx5xS1DjNZAiMLxiNdAXlNzaIS?= =?iso-8859-1?Q?RbaNXUDvHh4onECNAgESQFyLDj3xPkkmz8Y14dvCGJp83la3+qdjuxKKWM?= =?iso-8859-1?Q?3ZysiIvQAHkvBrpKZtX521Uc9qairnHP3mqXf2Dt0gPhnCbmquneolOTWm?= =?iso-8859-1?Q?GjCxxjdAB4QpHcp8muEQZUWTG1KWdKqjHr/rhfMhUrz/ASqMxBBL7+vlZA?= =?iso-8859-1?Q?Sa4ROiuBrMp+Xw+jteMCmfsV1butbDC94AmnpDktyoNx1Wp6cMQ/UhhQW4?= =?iso-8859-1?Q?/UQZAG54/0JYm4AJUsQNhxTnWzMG3tXsKpRdFuN8KMO+DuidVBmS+n9gDi?= =?iso-8859-1?Q?zgadhzR62UMOG2/K0LqeH+UiwiPpDFFTpb76AQEM8QH53XNpW/wcIn0wDh?= =?iso-8859-1?Q?AuIUXwp+dNt5b/56k=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0664142117CA0F477491E5A2FAE31CH2PR00MB0664namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0664.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 627e5c88-8ad4-4749-f8e4-08d88a14b627 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2020 09:48:03.2071 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: SMGaOFRN5ZqXdqiXX0IIY3HFdJ9uE0JJVLKcfoXg+uJcyFdL8IwaEfyuiNAJ04h5i355sPbQhwvxPa82BP/b8A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0779 Archived-At: Subject: [Add] EER bootstrapping draft scopes X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 09:48:10 -0000 --_000_CH2PR00MB0664142117CA0F477491E5A2FAE31CH2PR00MB0664namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (Martin, I see you just touched on the 15% comment on another thread; I fig= ure this deserves a separate thread) One of the DEER feedback points that came up during the Monday session was = that it addresses a minority of cases (someone threw out 15%). I'm surprise= d to hear folks consider that a blocker to adoption considering the advice = from the chairs following the interim to try and clearly define solution sc= opes. My takeaway from that was it would make sense to have multiple, clean= ly-scoped solutions as opposed to a monolithic solution for every scenario. We feel breaking up the different scenarios makes sense given the wide vari= ety of different requirements each solution has. DEER is presented as a way= to verify bootstrapping from a public IP address, with an opportunistic (n= ot verifiable) method for same IP address. Another major scenario is for an= RFC1918 forwarder to refer to an upstream resolver given the CPE cannot be= updated with a same-IP EER. Does it not make sense to let a single draft f= ocus on that scenario that isn't required to also authenticate public serve= r bootstrapping? If the two scenarios end up with different security guarantees (which seems= probable), I think it makes sense to have different mechanisms so adopters= can choose to do one or the other or both depending on their needs. Thanks, Tommy --_000_CH2PR00MB0664142117CA0F477491E5A2FAE31CH2PR00MB0664namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
(Martin, I see you just touched on the 15% comment on another thread; I fig= ure this deserves a separate thread)

One of the DEER feedback points that came up during the Monday session was = that it addresses a minority of cases (someone threw out 15%). I'm surprise= d to hear folks consider that a blocker to adoption considering the advice = from the chairs following the interim to try and clearly define solution scopes. My takeaway from that was it wo= uld make sense to have multiple, cleanly-scoped solutions as opposed to a m= onolithic solution for every scenario.

We feel breaking up the different scenarios makes sense given the wide vari= ety of different requirements each solution has. DEER is presented as a way= to verify bootstrapping from a public IP address, with an opportunistic (n= ot verifiable) method for same IP address. Another major scenario is for an RFC1918 forwarder to refer to an= upstream resolver given the CPE cannot be updated with a same-IP EER. = ;Does it not make sense to let a single draft focus on that scenario that isn't required to also authenti= cate public server bootstrapping? 

If the two scenarios end up with different security guarantees (w= hich seems probable), I think it makes sense to have different mechanisms s= o adopters can choose to do one or the other or both depending on their needs. 

Thanks,
Tommy
--_000_CH2PR00MB0664142117CA0F477491E5A2FAE31CH2PR00MB0664namp_-- From nobody Mon Nov 16 02:03:03 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7980C3A16B3 for ; Mon, 16 Nov 2020 02:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10N5AnBh_lnc for ; Mon, 16 Nov 2020 02:03:00 -0800 (PST) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DC9F3A16B7 for ; Mon, 16 Nov 2020 02:02:51 -0800 (PST) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 3DA6E2421544; Mon, 16 Nov 2020 10:02:49 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) From: Jim Reid In-Reply-To: Date: Mon, 16 Nov 2020 10:02:48 +0000 Cc: ADD Mailing list Content-Transfer-Encoding: quoted-printable Message-Id: <3789B9E3-C89D-4143-857B-7EC436818F57@rfc1035.com> References: To: Tommy Jensen X-Mailer: Apple Mail (2.3445.9.7) Archived-At: Subject: Re: [Add] EER bootstrapping draft scopes X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 10:03:01 -0000 > On 16 Nov 2020, at 09:48, Tommy Jensen = wrote: >=20 > My takeaway from that was it would make sense to have multiple, = cleanly-scoped solutions as opposed to a monolithic solution for every = scenario. Me too! If the WG tries to find a single over-arching monolithic solution for = every scenario, we might as well boil the ocean. That would be much = quicker and use less energy. From nobody Mon Nov 16 02:04:12 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07BB03A16BC for ; Mon, 16 Nov 2020 02:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 AF5_5kJLeWWi for ; Mon, 16 Nov 2020 02:04:09 -0800 (PST) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 057DA3A16B3 for ; Mon, 16 Nov 2020 02:04:08 -0800 (PST) Received: by mail-wm1-x331.google.com with SMTP id s13so23024793wmh.4 for ; Mon, 16 Nov 2020 02:04:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=L59A9RdD/Q+AhVtf/Si0JqQu9pNgcEuIvDbcVQb388I=; b=XZr6g+APrWKMLymXoRES7JkAc7vMELtjXvXwnFKjMIZPSOFMYb8mpIacQQgbxjhyJ4 REw+HrlBSnJjQIU5WO2jvi+INr4fE7eDgfcRQunXrsyIjXwYkCPfRG9fK5aXUsf8baxR 9bo4G4tsKO2V17Ux+2hUR3qObv2InDmbgwUQbWDmCWopmVea6IoJ+tJiq84GJJp4LSF4 2A9wre4RH4oDr3gxSc1QMBkUymhmAs4mT+3M4G974dcWmozKhKFgW5sUOzywqo9fk5zl cb66MgntcJv4YbV4clvf4NGv6hAHBxkNRrdOn2HLvmKX3jzzZUcaa9QkPwWJnT2UVgyw h8lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=L59A9RdD/Q+AhVtf/Si0JqQu9pNgcEuIvDbcVQb388I=; b=DhXOsysmzaU1kp3/wcrNjHaAYcpkhKZ07CHQY1gHHETuG4bqPpCh78xRNTQ/SE8uY1 U88XXUOG2FQbkh18HfPYUUrBJkbyyfAT0rrfNbajulXdHekQ7DjkkuGEaR4g2AsZjRKM uTvJV7Rc4wt6WLRyUvVg1Lzr8ESVzqvBKc3vd9NNhH3GUf7g69JbwqlAJBwTY6G5CNW/ eA4vbmtxkzWsI6KjUzzemTgcfynLTsZy3nGeFuVxMOM6slYBrrTwbF4FqQ57LOHLyMWE IMGzAzw6zXCOkQJLP5odDr/7W6l+NEIURj6Quu67q5QGE94XDdKPqaW41eue0/oRZs1N cXVg== X-Gm-Message-State: AOAM530V7Ycj2jALvhH7z4zPe4RJ041VX0/5Ss+paHULAUIoDnBnJy8t twDuRnqt+z6B0lhy9+BiMjiHvBmud1dix2kez0QxCBMfVEQ= X-Google-Smtp-Source: ABdhPJyT9RSacsLfPb/wBia7IJHacFFcqWzkeUk2VmQj1zmqUBXRkIY3BG5xxhoOVon2SKRcNPmuqmowbJi0VKY3A4w= X-Received: by 2002:a1c:c286:: with SMTP id s128mr14572961wmf.88.1605521047359; Mon, 16 Nov 2020 02:04:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Orth Date: Mon, 16 Nov 2020 05:03:56 -0500 Message-ID: To: Tommy Jensen Cc: "add@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b57ab605b4367f20" Archived-At: Subject: Re: [Add] EER bootstrapping draft scopes X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 10:04:11 -0000 --000000000000b57ab605b4367f20 Content-Type: text/plain; charset="UTF-8" My take: The best bang-for-buck case we could figure out a solution for is dealing with upgrading users currently configured to use a legacy home router that cannot do encryption or advertise a different IP. I think it's the biggest problem that many clients don't have any story to do. But that doesn't mean DEER's more limited case is not also a worthy problem to solve, and it seems to fit well into the spirit of simpler drafts scoped to individual cases. And since I'm the source of the 15% stat, I should clarify: Only approximately 15% of Chrome users have a non-private IP configured as the DNS server. I don't have any data on what portion of that remaining 85% can or cannot run encrypted DNS on that same private IP, or what portion could potentially have an ISP or similar reconfigure to point DHCP at a non-private IP, so DEER could potentially still be applicable for much more than just that 15%. On Mon, Nov 16, 2020 at 4:48 AM Tommy Jensen wrote: > (Martin, I see you just touched on the 15% comment on another thread; I > figure this deserves a separate thread) > > One of the DEER feedback points that came up during the Monday session was > that it addresses a minority of cases (someone threw out 15%). I'm > surprised to hear folks consider that a blocker to adoption considering the > advice from the chairs following the interim to try and clearly define > solution scopes. My takeaway from that was it would make sense to have > multiple, cleanly-scoped solutions as opposed to a monolithic solution for > every scenario. > > We feel breaking up the different scenarios makes sense given the wide > variety of different requirements each solution has. DEER is presented as a > way to verify bootstrapping from a public IP address, with an opportunistic > (not verifiable) method for same IP address. Another major scenario is for > an RFC1918 forwarder to refer to an upstream resolver given the CPE cannot > be updated with a same-IP EER. Does it not make sense to let a single > draft focus on that scenario that isn't required to also authenticate > public server bootstrapping? > > If the two scenarios end up with different security guarantees (which > seems probable), I think it makes sense to have different mechanisms so > adopters can choose to do one or the other or both depending on their > needs. > > Thanks, > Tommy > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000b57ab605b4367f20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My take: The best bang-for-buck case we could figure out a= solution for is dealing with upgrading users currently configured to use a= legacy home router that cannot do encryption or advertise a different IP.= =C2=A0 I think it's the biggest problem that=C2=A0many clients don'= t have any story to do.=C2=A0 But that doesn't mean DEER's more lim= ited case is not also a worthy problem to solve, and it seems to fit well i= nto the spirit of simpler drafts scoped to individual cases.

=
And since I'm the source of the 15% stat, I should clarify: Only a= pproximately 15% of Chrome users have a non-private IP configured as the DN= S server.=C2=A0 I don't have any data on what portion of that remaining= 85% can or cannot run encrypted DNS on that same private IP, or what porti= on could potentially have an ISP or similar reconfigure to point DHCP at a = non-private IP, so DEER could potentially still be applicable for much more= than just that 15%.

On Mon, Nov 16, 2020 at 4:48 AM Tommy Jensen <= Jensen.Thomas=3D40microso= ft.com@dmarc.ietf.org> wrote:
(Martin, I see you just touched on the 15% comment on another thread; I fig= ure this deserves a separate thread)

One of the DEER feedback points that came up during the Monday session was = that it addresses a minority of cases (someone threw out 15%). I'm surp= rised to hear folks consider that a blocker to adoption considering the adv= ice from the chairs following the interim to try and clearly define solution scopes. My takeaway from that was it wo= uld make sense to have multiple, cleanly-scoped solutions as opposed to a m= onolithic solution for every scenario.

We feel breaking up the different scenarios makes sense given the wide vari= ety of different requirements each solution has. DEER is presented as a way= to verify bootstrapping from a public IP address, with an opportunistic (n= ot verifiable) method for same IP address. Another major scenario is for an RFC1918 forwarder to refer to an= upstream resolver given the CPE cannot be updated with a same-IP EER.=C2= =A0Does it not make sense to let a single draft focus on that scenario that isn't required to also auth= enticate public server bootstrapping?=C2=A0

If the two scenarios end up with different security guarantees (which se= ems probable), I think it makes sense to have different mechanisms so adopt= ers can choose to do one or the other or both depending on their needs.=C2=A0

Thanks,
Tommy
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000b57ab605b4367f20-- From nobody Mon Nov 16 02:09:52 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC353A16CA for ; Mon, 16 Nov 2020 02:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=T4xacHnh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=aArMb/nj 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 tRMkZMOIpFKQ for ; Mon, 16 Nov 2020 02:09:49 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34D753A16C8 for ; Mon, 16 Nov 2020 02:09:49 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6E68D5C00E0 for ; Mon, 16 Nov 2020 05:09:48 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Mon, 16 Nov 2020 05:09:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=61436iAoa3cy/jSqOGfc/SKrXIc1cxc olgsHhsC0YOk=; b=T4xacHnh+6dMydCep1dBecHV6yiXV++Uv7J68jQj36C39Wz y+pnvMSJ6q3WmvvbqLmqy9+N9DscmDUc8Hh5S04gsXW26XVPQLWG+36uEidVOMHT ICi9X1H0VafcOFq2IFvtWSN+awdP6wRSiS9x4ybGaXGTdtW3vMaKvBJEkVEQijmI oC+fgnIXLG8zX3/o7q+m/SPHBlKe/ZcgEkraIow6XXmW8Ps25iUy1pVCoS/9Py1p RnrlTNIaV0hZTCX2GEcBUGfjx0x0+b4YcGZ8U+l5f+BmY6xULN5W+DwbgSWLqDyO ydLVhpaSBH+s+BD6LpGJHzsicWXST5wx2e6lq/A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=61436i Aoa3cy/jSqOGfc/SKrXIc1cxcolgsHhsC0YOk=; b=aArMb/njHyRw133RddMfsb rle4JgM8DgW8B5C/0LT3sOc9Xd8oSW8W9FrbkZ3btZ7DJOydUA+/xY+Sv9syi+od qJU/D+UEtf1zR5KWrdMR7UFOsgKZnoRmAIXvxBqLPCY8jlt6u10hUcJlmL1zZ9/W 8nRlkj9NKMUv5nY5wuTLf3XEXuPpBvWF3rlnsPEutpPLCx19WSvJw5l9lq8Md7SL TmjhbX2sw/ICyvyd0+Dj8/Gj2GCf8Yv6vUkXGxLzxC2j3+HwIJQurJL/K9b9pnaM JnCaoWchJavoWStZejAyWVkCA4YdQzXGFWihZKYd3866EPnn1bfQMM5BVr8wxIRA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefuddgudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 05631200BD; Mon, 16 Nov 2020 05:09:48 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-570-gba0a262-fm-20201106.001-gba0a2623 Mime-Version: 1.0 Message-Id: <0d736ecb-f188-4329-8ab5-f5d94e3bddcc@www.fastmail.com> In-Reply-To: References: Date: Mon, 16 Nov 2020 21:09:25 +1100 From: "Martin Thomson" To: add@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Add] EER bootstrapping draft scopes X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 10:09:51 -0000 On Mon, Nov 16, 2020, at 20:48, Tommy Jensen wrote: > One of the DEER feedback points that came up during the Monday session > was that it addresses a minority of cases (someone threw out 15%). I'm > surprised to hear folks consider that a blocker to adoption considering > the advice from the chairs following the interim to try and clearly > define solution scopes. I don't. I even think that DEER *might* help for more than the 15%, as I pointed out during the meeting. It all depends on your posture. If you start off with the assumption that you will take whatever you will get, then you might be able to use DEER for the other 85% as well. Of course, that doesn't make DKG or Ekr happy about the security properties of the situation. You don't get to learn what your resolver is doing with queries. For that you need a reference identity. But then I'm not sure that DHCP/RA are up to providing anything worth relying on their either. For that we all seem to be relying on lists right now. Mostly. DEER does seem to offer some hope if you have some reliable way of getting that reference identity. From nobody Mon Nov 16 02:12:18 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520543A16CE for ; Mon, 16 Nov 2020 02:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 C8Z8NEamoFRL for ; Mon, 16 Nov 2020 02:12:15 -0800 (PST) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 CABF63A16C8 for ; Mon, 16 Nov 2020 02:12:15 -0800 (PST) Received: by mail-io1-xd30.google.com with SMTP id u21so16742871iol.12 for ; Mon, 16 Nov 2020 02:12:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vo+jQxsc5PT9BQzgxYfWlsCiGWS9pnfik2QEAmhPdKo=; b=VxSpIZ5/nu0ffGjEWxK7OHYp6TQgT5SyhNqzpmg0s8+tsPgMfd8yQKtlcsbTwRvxFU 6FGEV0ZhmaYq9JvqgBRxZySlTmdqRBWsWKURMTGHVW2Du3D/2diG/g4tqVWAtV4dUCSu oGWKWph4Capn2YzTLXV81XPEBBRN+0GeiS34WIBAcjFyruEL+L+CeSXExjyaQ+h1ruCF uVccHmXTkl3hE45hwD5tDjLRP79TsceuZwYgZwHcjVsbqNjm0InM0ssY6fjQxxaQ8XHA ZHPjk1VHrp4Nc6VgbICU+oh5KeH3Z7jVCKhv5iBB3nrB/J2QJ1FcOsQtXVuyIaoM+Tq/ irng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Vo+jQxsc5PT9BQzgxYfWlsCiGWS9pnfik2QEAmhPdKo=; b=kewO1F57DJC6r2FdUb8IrnMh6Pl06V6kvePx2YQseqwE9J9/tVWOsqfePu8PF8BqVU LG1ES8i7eb6c8Xo0VEZ0GBqBCqYSANkUoS3UCor+CkYsTyqv7mxweyJz9v6KK9ISf5fX 2+jYiP5hvRk7W60POw+boSNfYflpZArDXR+dcn83hoU1fFCxnKQGdsSCgDJCIYNV2Si1 ecfcQkP1UtneaNVCpbMmUafRQiS/VuV5JynhGWxC7/8eMoGZ17EWQPqnAvt9jVV1CXGg M9SReKO42n+wdJFJ1u0Ipildda2WffQY3GDIsVNGGV1flbziJwM8yXbk2cBko5ZJm5Bd P5pg== X-Gm-Message-State: AOAM531zQIgUmTR7WvLLmYXTC26BvhNK/gWowDU8VqwiBld7MVaqLhNo 39vkw4o7QxTuoz9UvSEOw/Zkze3GleQ18h9ukeA= X-Google-Smtp-Source: ABdhPJyDbp4FW/kDFcfBngCRoydYvGhHAZ2fh6HMdRQVVhyERCDtPyHCWL8DEe7/5A2vyN+d3Jo1Rbov/HIXFB/BkqE= X-Received: by 2002:a5d:858b:: with SMTP id f11mr7473545ioj.0.1605521535013; Mon, 16 Nov 2020 02:12:15 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: tirumal reddy Date: Mon, 16 Nov 2020 17:12:03 +0700 Message-ID: To: Tommy Jensen Cc: "add@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c6182805b4369c39" Archived-At: Subject: Re: [Add] EER bootstrapping draft scopes X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 10:12:17 -0000 --000000000000c6182805b4369c39 Content-Type: text/plain; charset="UTF-8" I consider DEER to complement encrypted resolvers that cannot be discovered via DHCP/RA (see https://tools.ietf.org/html/draft-btw-add-home-10). Upgradable CPE can host a DoH/DoT forwarder and DHCP/RA can be used to discover the network-provided encrypted resolver. IP address matching is not required to prove equivalence for network-identified encrypted resolvers. In case of Legacy CPE, DEER can be used to discover the encrypted DNS server hosted by the ISP. -Tiru On Mon, 16 Nov 2020 at 16:48, Tommy Jensen wrote: > (Martin, I see you just touched on the 15% comment on another thread; I > figure this deserves a separate thread) > > One of the DEER feedback points that came up during the Monday session was > that it addresses a minority of cases (someone threw out 15%). I'm > surprised to hear folks consider that a blocker to adoption considering the > advice from the chairs following the interim to try and clearly define > solution scopes. My takeaway from that was it would make sense to have > multiple, cleanly-scoped solutions as opposed to a monolithic solution for > every scenario. > > We feel breaking up the different scenarios makes sense given the wide > variety of different requirements each solution has. DEER is presented as a > way to verify bootstrapping from a public IP address, with an opportunistic > (not verifiable) method for same IP address. Another major scenario is for > an RFC1918 forwarder to refer to an upstream resolver given the CPE cannot > be updated with a same-IP EER. Does it not make sense to let a single > draft focus on that scenario that isn't required to also authenticate > public server bootstrapping? > > If the two scenarios end up with different security guarantees (which > seems probable), I think it makes sense to have different mechanisms so > adopters can choose to do one or the other or both depending on their > needs. > > Thanks, > Tommy > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000c6182805b4369c39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I consider DEER to complement encrypted resolvers tha= t cannot be discovered via DHCP/RA (see https://tools.ietf.org/html/dr= aft-btw-add-home-10). Upgradable CPE can host a DoH/DoT forwarder and D= HCP/RA can be used to discover the network-provided encrypted resolver. IP = address matching is not required to prove equivalence for network-identifie= d encrypted resolvers.=C2=A0

In case of Legacy CPE, DEER can be used to discov= er the encrypted DNS=C2=A0server hosted by the ISP.

-Tiru

On Mon, = 16 Nov 2020 at 16:48, Tommy Jensen <Jensen.Thomas=3D40microsoft.com@dmarc.ietf.= org> wrote:
(Martin, I see you just touched on the 15% comment on another thread; I fig= ure this deserves a separate thread)

One of the DEER feedback points that came up during the Monday session was = that it addresses a minority of cases (someone threw out 15%). I'm surp= rised to hear folks consider that a blocker to adoption considering the adv= ice from the chairs following the interim to try and clearly define solution scopes. My takeaway from that was it wo= uld make sense to have multiple, cleanly-scoped solutions as opposed to a m= onolithic solution for every scenario.

We feel breaking up the different scenarios makes sense given the wide vari= ety of different requirements each solution has. DEER is presented as a way= to verify bootstrapping from a public IP address, with an opportunistic (n= ot verifiable) method for same IP address. Another major scenario is for an RFC1918 forwarder to refer to an= upstream resolver given the CPE cannot be updated with a same-IP EER.=C2= =A0Does it not make sense to let a single draft focus on that scenario that isn't required to also auth= enticate public server bootstrapping?=C2=A0

If the two scenarios end up with different security guarantees (which se= ems probable), I think it makes sense to have different mechanisms so adopt= ers can choose to do one or the other or both depending on their needs.=C2=A0

Thanks,
Tommy
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000c6182805b4369c39-- From nobody Mon Nov 16 02:55:39 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A973A091C for ; Mon, 16 Nov 2020 02:55:37 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=portfast.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 9UvqSlcphZXP for ; Mon, 16 Nov 2020 02:55:35 -0800 (PST) Received: from mail.portfast.net (mail.portfast.net [IPv6:2a03:9800:20:1::2]) (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 60DD83A08FA for ; Mon, 16 Nov 2020 02:55:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=portfast.net; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=tkCb8u+uCcucQPOA5Pkit5Wcg1WoEvsM3+MpeLgvvZc=; b=Rseab9YKxiq9L4epqafnElFjU0 Rh9WRdjG2hEI6mGFpJssfWBYvgNqi8VSsTSr35K7mpAHSU40xhno6YYMvNO8GhHlZbsqiwDw7tQQR HGgbHbWe/8BT/q26Fm1qNgJfrSfQuKa6MrDtHJDqGxx9kmuW65j5ZATbWr+XBxT90doY=; Received: from 216-213-177-102.customer.gigaclear.net ([216.213.177.102]:61671 helo=Rays-MacBook-Pro.local) by mail.portfast.net ([188.246.200.9]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1kecAX-00026i-3u (Exim 4.89) for add@ietf.org (return-path ); Mon, 16 Nov 2020 10:55:33 +0000 To: add@ietf.org References: From: Ray Bellis Message-ID: Date: Mon, 16 Nov 2020 10:55:32 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] EER bootstrapping draft scopes X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 10:55:38 -0000 On 16/11/2020 10:03, Eric Orth wrote: > And since I'm the source of the 15% stat, I should clarify: Only > approximately 15% of Chrome users have a non-private IP configured as > the DNS server.  I don't have any data on what portion of that remaining > 85% can or cannot run encrypted DNS on that same private IP, or what > portion could potentially have an ISP or similar reconfigure to point > DHCP at a non-private IP, so DEER could potentially still be applicable > for much more than just that 15%. Pretty much every last-mile access technology will deliver a set of DNS servers to the CPE, whether by DHCP or PPPoE parameters. Many CPE will not pass those addresses on to the client devices, they issue the routers own internal address (typically RFC 1918) in the CPE's own DHCP leases. One reason for this is because it avoids the chicken and egg scenario of what DNS servers to put in the client lease if the CPE is not online and had not yet acquired its own upstream lease. This is particularly common on xDSL technologies where the time to "sync" the WAN port on power-up is quite long. Ray From nobody Mon Nov 16 12:20:54 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A203A13BD for ; Mon, 16 Nov 2020 12:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 wRUOgvsea9Ay for ; Mon, 16 Nov 2020 12:20:51 -0800 (PST) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 5EAFF3A13B4 for ; Mon, 16 Nov 2020 12:20:51 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 0AGKDOma005767; Mon, 16 Nov 2020 12:20:50 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=6m+AWz5cPdwPJLetkDsl/P51sdLlpcgyqi+OZaazXEY=; b=hRFQ2yRJjHoZVUG/SmDQpx/bPtuciAwLpootUIKY+i4fOimx2jCsDsN8SARLeETdR0Bz 8s4bFkfcfQ+CewVB5KgaDhwat3ha+FE+nutMvoWrzxpwYeqU1GzLVqu7ztD9+0bRfKFJ L/aQLKzxAmoW2x0oCUeL9c1ILnAjBOM+M+niBZIqy14hW+t9a5omQ85ekvJZr/nI8K1O oUr8h8O/hHBjDKFbEjLuaXaY7UMEPFfP8H63fBkdhn8+lPY9xq4uGy7lTy4qpD1mAvA9 3pkgfKKdyJop5b08Wz7IUuC0wga2r//0ZqOHO7BB+f8AFiUTnTgVXB9GHAihBa/SRBF/ /Q== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 34tf3yvwh7-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 16 Nov 2020 12:20:50 -0800 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QJW00UA7OIPVA20@rn-mailsvcp-mta-lapp01.rno.apple.com>; Mon, 16 Nov 2020 12:20:49 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QJW00K00O78J100@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Mon, 16 Nov 2020 12:20:49 -0800 (PST) X-Va-A: X-Va-T-CD: 01a37c4388be431533d60b3d58eeb299 X-Va-E-CD: 51bfe255e27da13f692d0a25c2e7ed3e X-Va-R-CD: a07022a626eca0911d133c6f5cdc2d10 X-Va-CD: 0 X-Va-ID: 27b6dd86-7727-4200-a6de-5298e887aa96 X-V-A: X-V-T-CD: 01a37c4388be431533d60b3d58eeb299 X-V-E-CD: 51bfe255e27da13f692d0a25c2e7ed3e X-V-R-CD: a07022a626eca0911d133c6f5cdc2d10 X-V-CD: 0 X-V-ID: 7c8df41b-80a2-4801-928d-ba336163af54 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-16_10:2020-11-13, 2020-11-16 signatures=0 Received: from localhost.localdomain (unknown [17.234.109.15]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QJW00N9NOIFTS00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Mon, 16 Nov 2020 12:20:49 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\)) From: Tommy Pauly In-reply-to: <0d736ecb-f188-4329-8ab5-f5d94e3bddcc@www.fastmail.com> Date: Mon, 16 Nov 2020 12:20:37 -0800 Cc: add@ietf.org Content-transfer-encoding: quoted-printable Message-id: References: <0d736ecb-f188-4329-8ab5-f5d94e3bddcc@www.fastmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.3654.0.3.2.26) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-16_10:2020-11-13, 2020-11-16 signatures=0 Archived-At: Subject: Re: [Add] EER bootstrapping draft scopes X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 20:20:53 -0000 > On Nov 16, 2020, at 2:09 AM, Martin Thomson wrote: >=20 > On Mon, Nov 16, 2020, at 20:48, Tommy Jensen wrote: >> One of the DEER feedback points that came up during the Monday = session=20 >> was that it addresses a minority of cases (someone threw out 15%). = I'm=20 >> surprised to hear folks consider that a blocker to adoption = considering=20 >> the advice from the chairs following the interim to try and clearly=20= >> define solution scopes. >=20 > I don't. I even think that DEER *might* help for more than the 15%, = as I pointed out during the meeting. >=20 > It all depends on your posture. If you start off with the assumption = that you will take whatever you will get, then you might be able to use = DEER for the other 85% as well. Agreed. The mechanism in DEER can be used with looser restrictions = (creating a variation of the Opportunistic mode where you=E2=80=99re = allowed to use a different IP address as long as some conditions are = met). We can restrict it to only private addresses; and clients could = choose to limit the resolver identities they will trust through this = mechanism. >=20 > Of course, that doesn't make DKG or Ekr happy about the security = properties of the situation. You don't get to learn what your resolver = is doing with queries. For that you need a reference identity. But = then I'm not sure that DHCP/RA are up to providing anything worth = relying on their either. For that we all seem to be relying on lists = right now. Mostly. DEER does seem to offer some hope if you have some = reliable way of getting that reference identity. Right=E2=80=94if you want to have something that you can prove matches = your reference identity, I think there may not be any way to get those = guarantees on a network with a forwarder running on a private IP address = that can=E2=80=99t ever update DHCP and can=E2=80=99t add its own = encrypted DNS support. Arguably, for those cases, you are technically = using a resolver (which does little more than forwarding and filtering) = that simply has no equivalent encrypted resolver and will never have = one. You may be trying to figure out the equivalent encrypted resolver = for whatever the forwarder is talking to, but unless you have a trusted = way to find out what that entity is, you don=E2=80=99t have many = options. Let=E2=80=99s find a way to make a solution like DEER work =E2=80=9Cwell = enough=E2=80=9D for that case, with many caveats about how you can=E2=80=99= t really trust it, and put limits on when and how this mode is used. But = it=E2=80=99s important to also define the stronger mode of validation, = so we can at least have a model that networks going forward can adopt = and we can point to. There will always be some old router deployments, = so let=E2=80=99s work with those, but let=E2=80=99s not stop ourselves = from designing a system that can provide better assurances for other = deployments (which will hopefully become increasingly common). Tommy >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add From nobody Mon Nov 16 12:21:51 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A9B3A13BA for ; Mon, 16 Nov 2020 12:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] 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 psjhn_Ml1h62 for ; Mon, 16 Nov 2020 12:21:49 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 72DC13A13CA for ; Mon, 16 Nov 2020 12:21:44 -0800 (PST) Received: from xse27.mail2web.com ([66.113.196.27] helo=xse.mail2web.com) by mx165.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1kel0N-000ity-N9 for add@ietf.org; Mon, 16 Nov 2020 21:21:42 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4CZgT65Hgsz2tP for ; Mon, 16 Nov 2020 12:21:30 -0800 (PST) Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1kel0E-0006QR-KF for add@ietf.org; Mon, 16 Nov 2020 12:21:30 -0800 Received: (qmail 16755 invoked from network); 16 Nov 2020 20:21:30 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.58.43.45]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 16 Nov 2020 20:21:30 -0000 To: "add@ietf.org" From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH Message-ID: <255afe94-837a-8669-55c0-ea85cee7d0af@huitema.net> Date: Mon, 16 Nov 2020 12:21:30 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 66.113.196.27 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.27/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.27/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0cThwnZT+ODcFyeCwCHoUjupSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDNzOpszOkW3faMySFwG163+fH zJ6mVE7ewsipSVIfs4aeq5SsUxF9VCxmaqhgXpwbgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+cAdwcW/8Ox85Le8wqlbs5XUz0sPgnpAk2KA2vJwMd1uY6jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhLSQQ4vSj0QEim26t/Moy0UPX5E73H1QfrH/5kkrV/Cr0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAm65NdfLN8K9b ke08A4pcSPusgSYeYCQMSlpJmALhsMXcTokAgKXZMRpH4/ThBWJCf66fnYtWMT4TiIUGjP1fmnge eIwW6dxAGXuAHG/CZL1ChmNslj5ISm3e0VBk8/xT111677oPXF7r5zsW33ZNlipxi6wSaAMxm3k+ vpDDF6n8N+qh3YF7t/lvtNmPz3Nh3nvDqjt8m/e2EfWTeMUuDxm9yWk+GRbtLNh2hVBskBsSXPWl FdaGOH191uXjgjQN/bk/tOvsMDZmQNfeGxdXg4EHU8pZIn9UQUwZnRafvav383g9ueTJOU6a76yp yxjdeg8YhWenlMfuvb1mNY5/IPiuedK/Z3MvnAyDmuOaA5CGZRWsGw8ac2InzcAP/gmxwNpms+rB 6wJM+NNhN3aT35NSU/fjw6KbqLw80r1gDO3m6U0LjBzYuQztdAThgtWSU3qCINKqlAdh+ePAcEwD s/8= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: [Add] STUN for DNS? X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 20:21:50 -0000 Should we have the equivalent of STUN for DNS? STUN was defined many years ago in the context of NAT traversal, so hosts behind a NAT could enlist help from server and learn how their "public" IP address appears on the other side of the NAT. Likewise, with STUN for DNS, hosts could get help from a third-party server and learn the "public" IP address of the recursive resolver configured on their system. One of the applications would be to obtain the seed needed for the "equivalent encrypted resolver" discovery; there are probably quite a few other applications. The simplest design would be to configure the host with just the domain name of the STUN for DNS resolver, say "s4d.example.net", and with a key for that resolver. The host that wants to identify the local service constructs a unique query by picking a random number "rrr", and asks for a TXT record associated with "rrr.s4d.example.net". The request is routed by the local resolver (maybe a Wi-Fi router) to a recursive resolver and then to the selected server, which is authoritative for the selected domain name (s4d.example.net). The STUN 4 DNS resolver programmatically creates a TXT record containing the encrypted value of the source address from which the query was received -- that is, the address of the recursive resolver. That response will then be relayed to the host. Would there be any interest in defining such service? -- Christian Huitema From nobody Mon Nov 16 13:02:46 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878503A1472 for ; Mon, 16 Nov 2020 13:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 J6vS_Dsf622Y for ; Mon, 16 Nov 2020 13:02:36 -0800 (PST) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 11C6E3A145A for ; Mon, 16 Nov 2020 13:02:35 -0800 (PST) Received: by mail-il1-x130.google.com with SMTP id h6so12941426ilj.8 for ; Mon, 16 Nov 2020 13:02:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CAiCavmD2qxF6Lo32/jS+tc9NWVv8hKWjwlwtXwf9PE=; b=jH8gRZTPNpgio9rSRjzd/l/JOZDRn/vIVgVwzJ7IojdMkb0A0f+En0TxbfcPHAkHn3 TwMyTvFQHNDjoA1or90P5Efn2Lqj4pWLy7fy+eyFqENNqaS/HP+lH8r3f2an82gl+p7Q W9foqgvJXnHliJbW+1b5TC3qdjosccON7kvdwPHyVTY6ds/rqj1RJVIa1iI9Cjhn6pH7 wfhfaBlTrRUWcADm9I4ofPY156PYQd8PdEfFIqAczZq8SRWw3OfDfm3imJx4EWrhdqD5 PFzf08Dr/rCpGakP1JzcalbqmAeY77EhWODrUxCpYVqarcwqzaLVKutweYvTSOtWZwUz 92/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CAiCavmD2qxF6Lo32/jS+tc9NWVv8hKWjwlwtXwf9PE=; b=eWkAJeHPwyjHRo39u2GvWh6lB+dn/MqHa/k4NSdCuBa2QVsF2jxGniIOcYX8Yk65E6 ZJ5soKORjoj8SaZA0fzkj3zYwKz/vkJMj1Fj8I2UUAoerlBwanmmf4lqjaj5g/yHmKP/ 8xonGed7Wa+vrDFnZb6Y5elYvYo5jPPn1FzOoy6i81k0cGGYEXsBxEPl0EPNnINRAD5X nZKKsU0LzbR6UhHkU+R59IED1XjJJ8FZ1HnDUiAeTF3EFq3b3qSsUgk57Dnj+asU3qiE JX/qBRU/fgTAPF/+iMexaN95JIA1lLq9cz+gs+3BEHi8at1+STAZ8JZge+MH/OxS0t22 DEYw== X-Gm-Message-State: AOAM533WhHizNk6lAQ613KBf0rjYLQLd/haLiQo8/jSG50c6B5Fd20my kMSzww9BAMREGZRz9CyvJ7Xa8U1STxXZ1/BcHZM0toaRees= X-Google-Smtp-Source: ABdhPJzgI7UUVBiIyv/CKBjw2XKQlQji/JgPeQYhCVNbsxxGRPApk61+LRwLYSRkZMKMIbtGBtnyd36NC1IxWGjgDIQ= X-Received: by 2002:a05:6e02:ece:: with SMTP id i14mr9862323ilk.24.1605560554847; Mon, 16 Nov 2020 13:02:34 -0800 (PST) MIME-Version: 1.0 References: <394A540C-81A8-4F86-8E62-FADC4A820D81@rfc1035.com> <20201116093136.GA21460@nic.fr> <680ed8e1-bdb9-4ed9-aa12-7c0efe2bb1da@www.fastmail.com> In-Reply-To: <680ed8e1-bdb9-4ed9-aa12-7c0efe2bb1da@www.fastmail.com> From: Ben Schwartz Date: Mon, 16 Nov 2020 16:02:23 -0500 Message-ID: To: Martin Thomson Cc: ADD Mailing list Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000009164f405b43fb275" Archived-At: Subject: Re: [Add] equivalence definition X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 21:02:45 -0000 --0000000000009164f405b43fb275 Content-Type: multipart/alternative; boundary="00000000000089de0605b43fb289" --00000000000089de0605b43fb289 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think "equivalence" here is not an "equivalence relation"; it is not symmetric. What we mean by "equivalent" is more like "equivalent or better". I think part of our confusion is that we are describing two separate things. Before recommending an upgrade from (unencrypted) server A to (encrypted) server B: 1. What properties of these servers can the client prove to itself? 2. What conditions are we asking the operator(s) of these servers to meet? For example, we might ask that the operator of server B conform to the privacy policy of server A, but this is not verifiable by the client. Similarly, I don't think we intend for clients to verify that they get the same answers from servers A and B, even if we want the answers to be "equivalent". In the local network use case, it's important to ask what properties the client can prove about server A. In particular, I posit that any persistent attacker who can answer queries sent to server A is indistinguishable from server A. This suggests a possible solution to the local network use case: ask the client to regularly revalidate server A's intention to upgrade to server B, and stop using server B if server A stops recommending it. On Mon, Nov 16, 2020 at 4:39 AM Martin Thomson wrote: > My definition was slightly different: > > If we assume that either Do53 discovery was perfectly secure, OR that plu= s > the Do53 resolver itself were perfectly secure, then - in the presence of= a > Dolev-Yao attacker and any information obtained from those perfectly secu= re > sources, can we provide something that uses TLS and is reasonably secure? > > I think that we can, but not in the presence of old DNS forwarders that > can't be updated. > > What I heard from David Schinazi (though these were I think Eric Orth's > figures) was that the environment was such that none of our existing > solutions would work and we would need a looser definition if we were to = be > able to offer DoH/DoT to most users. If we don't accept something a litt= le > more opportunistic, we only get ~15% of people (assuming that dataset is > representative, which I believe it should be). > > On Mon, Nov 16, 2020, at 20:31, Stephane Bortzmeyer wrote: > > On Mon, Nov 16, 2020 at 08:41:39AM +0000, > > Jim Reid wrote > > a message of 11 lines which said: > > > > > The point I didn=E2=80=99t get to make at the mike is using =E2=80=9C= two or more > > > resolvers operated by the same entity=E2=80=9D as the definition of > > > equivalence probably doesn=E2=80=99t work: > > > > Another case where it doesn't work is when the same entity offers > > different services (one lying and one not, for instance), which is > > common among public resolvers > > > > , etc > > > > I suggest to not just say "equivalent" but be more specific: "with > > equivalent answers". Equivalent answers being defined by the user's > > use cases. If resolver A censors SciHub and resolver B does not, they > > do not yield equivalent answers. If resolver A sees gmail.com at > > 2a00:1450:400e:809::2005 and resolver B sees it at > > 2a00:1450:4007:816::2005, they probably give equivalent answers, as > > far as the ordinary user is concerned. > > > > "Equivalent" is too loaded to be used alone. > > > > > > -- > > Add mailing list > > Add@ietf.org > > https://www.ietf.org/mailman/listinfo/add > > > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --00000000000089de0605b43fb289 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think "equivalence" here is not an "equiv= alence relation"; it is not symmetric.=C2=A0 What we mean by "equ= ivalent" is more like "equivalent or better".

=
I think part of our confusion is that we are describing=C2=A0two separ= ate things.=C2=A0 Before recommending an upgrade from (unencrypted) server = A to (encrypted) server B:

1. What properties of t= hese servers can the client prove to itself?
2. What conditions a= re we asking the operator(s) of these servers to meet?

=
For example, we might ask that the operator of server B conform to the= privacy policy of server A, but this is not verifiable by the client.=C2= =A0 Similarly, I don't think we intend for clients to verify that they = get the same answers from servers A and B, even if we want the answers to b= e "equivalent".

In the local network use= case, it's important to ask what properties the client can prove about= server A.=C2=A0 In particular, I posit that any persistent attacker who ca= n answer queries sent to server A is indistinguishable from server A.=C2=A0= This suggests a possible solution to the local network use case: ask the c= lient to regularly revalidate server A's intention to upgrade to server= B, and stop using server B if server A stops recommending it.
<= br>
On Mon,= Nov 16, 2020 at 4:39 AM Martin Thomson <mt@lowentropy.net> wrote:
My definition was slightly different:

If we assume that either Do53 discovery was perfectly secure, OR that plus = the Do53 resolver itself were perfectly secure, then - in the presence of a= Dolev-Yao attacker and any information obtained from those perfectly secur= e sources, can we provide something that uses TLS and is reasonably secure?=

I think that we can, but not in the presence of old DNS forwarders that can= 't be updated.

What I heard from David Schinazi (though these were I think Eric Orth's= figures) was that the environment was such that none of our existing solut= ions would work and we would need a looser definition if we were to be able= to offer DoH/DoT to most users.=C2=A0 If we don't accept something a l= ittle more opportunistic, we only get ~15% of people (assuming that dataset= is representative, which I believe it should be).

On Mon, Nov 16, 2020, at 20:31, Stephane Bortzmeyer wrote:
> On Mon, Nov 16, 2020 at 08:41:39AM +0000,
>=C2=A0 Jim Reid <jim@rfc1035.com> wrote
>=C2=A0 a message of 11 lines which said:
>
> > The point I didn=E2=80=99t get to make at the mike is using =E2= =80=9Ctwo or more
> > resolvers operated by the same entity=E2=80=9D as the definition = of
> > equivalence probably doesn=E2=80=99t work:
>
> Another case where it doesn't work is when the same entity offers<= br> > different services (one lying and one not, for instance), which is
> common among public resolvers <https://quad9.net/faq/>
> <https://dns.yandex.com/>
> <https://blog.cloudflare.com/in= troducing-1-1-1-1-for-families/>, etc
>
> I suggest to not just say "equivalent" but be more specific:= "with
> equivalent answers". Equivalent answers being defined by the user= 's
> use cases. If resolver A censors SciHub and resolver B does not, they<= br> > do not yield equivalent answers. If resolver A sees gmail.com at
> 2a00:1450:400e:809::2005 and resolver B sees it at
> 2a00:1450:4007:816::2005, they probably give equivalent answers, as > far as the ordinary user is concerned.
>
> "Equivalent" is too loaded to be used alone.
>
>
> --
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--00000000000089de0605b43fb289-- --0000000000009164f405b43fb275 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPmAYJKoZIhvcNAQcCoIIPiTCCD4UCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggzyMIIEtjCCA56gAwIBAgIQeAMYYHb81ngUVR0WyMTzqzANBgkqhkiG9w0BAQsFADBMMSAwHgYD VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE AxMKR2xvYmFsU2lnbjAeFw0yMDA3MjgwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFQxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFz IFIzIFNNSU1FIENBIDIwMjAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvLe9xPU9W dpiHLAvX7kFnaFZPuJLey7LYaMO8P/xSngB9IN73mVc7YiLov12Fekdtn5kL8PjmDBEvTYmWsuQS 6VBo3vdlqqXZ0M9eMkjcKqijrmDRleudEoPDzTumwQ18VB/3I+vbN039HIaRQ5x+NHGiPHVfk6Rx c6KAbYceyeqqfuJEcq23vhTdium/Bf5hHqYUhuJwnBQ+dAUcFndUKMJrth6lHeoifkbw2bv81zxJ I9cvIy516+oUekqiSFGfzAqByv41OrgLV4fLGCDH3yRh1tj7EtV3l2TngqtrDLUs5R+sWIItPa/4 AJXB1Q3nGNl2tNjVpcSn0uJ7aFPbAgMBAAGjggGKMIIBhjAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHzM CmjXouseLHIb0c1dlW+N+/JjMB8GA1UdIwQYMBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MHsGCCsG AQUFBwEBBG8wbTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3Ry MzA7BggrBgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvcm9vdC1y My5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIz LmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5n bG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEANyYcO+9JZYyqQt41 TMwvFWAw3vLoLOQIfIn48/yea/ekOcParTb0mbhsvVSZ6sGn+txYAZb33wIb1f4wK4xQ7+RUYBfI TuTPL7olF9hDpojC2F6Eu8nuEf1XD9qNI8zFd4kfjg4rb+AME0L81WaCL/WhP2kDCnRU4jm6TryB CHhZqtxkIvXGPGHjwJJazJBnX5NayIce4fGuUEJ7HkuCthVZ3Rws0UyHSAXesT/0tXATND4mNr1X El6adiSQy619ybVERnRi5aDe1PTwE+qNiotEEaeujz1a/+yYaaTY+k+qJcVxi7tbyQ0hi0UB3myM A/z2HmGEwO8hx7hDjKmKbDCCA18wggJHoAMCAQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUA MEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWdu MRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEg MB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzAR BgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4 Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuu l9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJ pij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh 6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti +w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEA S0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9u bG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaM ld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88 q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/f hO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBNEwggO5oAMCAQICEAE/JGAv3XK3SRaKvGds QSwwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gQXRsYXMgUjMgU01JTUUgQ0EgMjAyMDAeFw0yMDA5MDgy MzQzNTNaFw0yMTAzMDcyMzQzNTNaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFzY0Bnb29nbGUuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7rjWsiqQSnXGFTvs/2JDygQFtWsgF+Ce W2I/wmwCuWH2eNUBYslyudWmJsUMi7IbeSsKHrvBI2P7k6sk5p6o3uFlomiFaDMqXcn76t5GNGym CmHm5KBWxc3LfyvR4C2/wg9oUwbL2xxXc6QQpWWE4ONn9NMHwNC396Ih5u7tcrH5eF49HbVarP5i TindWAOzz++JA3VC/1lIkqWvOt2BcBtxQDUnYp8sr8UnMF/6UqtCd0aHJnKkvYi4o8Qo5Qf3YgiJ DzADzBTf54o3NAI3hiIVKPvz1l0g78IcR29Bt9jUrE33qGzGB6HoY7Z8quhA/ngW2XjuLkIY1ZKX AwTXBQIDAQABo4IBzzCCAcswHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5jb20wDgYDVR0PAQH/ BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUu687mSaB85ui VgNNFSUhtTljkxEwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYmaHR0cHM6 Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wCQYDVR0TBAIwADCBmgYIKwYBBQUHAQEE gY0wgYowPgYIKwYBBQUHMAGGMmh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL2NhL2dzYXRsYXNy M3NtaW1lY2EyMDIwMEgGCCsGAQUFBzAChjxodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2Nh Y2VydC9nc2F0bGFzcjNzbWltZWNhMjAyMC5jcnQwHwYDVR0jBBgwFoAUfMwKaNei6x4schvRzV2V b4378mMwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9jYS9nc2F0 bGFzcjNzbWltZWNhMjAyMC5jcmwwDQYJKoZIhvcNAQELBQADggEBAG9R1/y5PatVOc8xLrAmGgNO /Q4+lbJuHNwX3aIpOkM72Ot4r6r5/IFOSx1pMpmzvrECyy5YQzUGkHV4atuNq5YPPNMGa+XlaKSg oU2dA6RCD40dtwmrPxrKiGAfHPNvfmRvgnx9qxBKFPbKF/Tn8BwKSZCSvx33TnQRfqLUTcgrAarQ dF9Oc45moJrn4nVF0VTTPI6LVminvjg3tLgF2bny1N6CitQnb1t67vpYjeNpcXNIGQzEDaYI3WnK rVeZMcLSY+Z2dQH8HvVsA95vFCTywgiWKq5KxFqz/GdB6JhDWcIJIKCJVUyqD/Bjx47+e4Ye/FuD NDSYc+613Ozl3TkxggJqMIICZgIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFzIFIzIFNNSU1FIENBIDIwMjACEAE/ JGAv3XK3SRaKvGdsQSwwDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIJ2wGZd84fj8 VDjXPgFtyP1CQH/uJ0zPWI4BaFXN3K/tMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTIwMTExNjIxMDIzNVowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJ YIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcN AQEHMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQDoWUMKd4LNdxfNseCDSGGetFY2vkNS J/uoN3bvDuvfwEjZWnEjSqFSccsG2t5ECQif5o4pITvLbMrvanhcRSFCBlj8Ju9HMH1FOmTpJrNq x3gglwuwhhxCqyW7arm+oI89GLazHd2xFmJIWWtrmwqfPUPEk8KVDcsQ4Bmv50NQukDS6rppPx7b yZypO/VLYWKo5BvIXMCJRRih/SO7nOMqDSNurz/U/5yC/GyC7qIGb3Gy2vMnPUgNjhqgkCg8MqU0 WJTAjaMkI7g7VGGI0rLnxh79OkUU5uTmJ0ToAJ++jXqWipAxX7eHrV6B7C2Hj3Xwze1uZTojMoLJ FYTmxK+r --0000000000009164f405b43fb275-- From nobody Mon Nov 16 13:22:41 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F0E3A1482 for ; Mon, 16 Nov 2020 13:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 G2I7tJFMaRY5 for ; Mon, 16 Nov 2020 13:22:38 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 54CEF3A147D for ; Mon, 16 Nov 2020 13:22:38 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id s24so18914633ioj.13 for ; Mon, 16 Nov 2020 13:22:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vp3H0Yg0el8CLvNxhOnB6gfNEagZ4TyuoM/su+aUjj8=; b=tqUypPui2cw/qNstIO3Yzd/nHSsJBLzRyTXndGV5BwzyBEooH2T+umffLALBPoTDHS 55OI22s34cZh5GofBu3xvkmlmS1ilbuCxdHiWgNyKbiWptkze/6LdOls0gkDbQlw0CPe w9otySkCrzsROdZT0EKFyJiiKG+oIXGYAgmDRtFroEnWagnFnUqt1YIzw1VxvaF+CqbG I7P/avpjbefNruH4TGaH45nKO21cxkyD+unslDjzK2Jel/Fn0Ze0GtlTMdOwvRlk3JHg x++xavA45trxqlUKID7kh4htxnMwneKzIckR6fX57a6/sDHq725WXi97HbWrrZ9w7V9H 8EYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vp3H0Yg0el8CLvNxhOnB6gfNEagZ4TyuoM/su+aUjj8=; b=h/NLBZ1VxKUGYxoDrkKNJBSQYnTF6hy6z6mCGavng+ZAGy2ZIKS3E1GD72ggLH1ROa 1HYO2gKUYaedvmHKqtnLNM4OPyJEs5PEEibQRD2j2ynHfu+nX7LoJBfoKYH1C6iwudml 1NnHM2OMIpQl9iLhF91sTVzjI1TZrrOxytJnyCX63wI/ykp6N+z2u1Np93ExUEsqPByN L912/XKl3lIJ7TSfxpF9MJLi5/bOaEenaLwR2uuTlq7uEwtZStPXQ/RaVarj3UHdg0ib Og0S2Pcf8/Rpp2F6f+ROIaRXWBsT0rdbBtitMwS6JShUORg3BYQQPURpxXkSpGmUfzyr rWRQ== X-Gm-Message-State: AOAM533l8HtzUlb5U3EKYEpKaU3kZHggmGWaN0IUQf9KbN3XPmpR1sxZ MK3HGDfmkmZ+13NwlB7We3yc5uBlQrI0lIeJlqE7PmBiMmNBQg== X-Google-Smtp-Source: ABdhPJxjc0LzkM8oes91MFmnQjrKgWXc4LUcIiZ/eOjdHAzA/061hTzUBbr3C3N/uNUmw5nDznBd3RE/ZIDykExb7yk= X-Received: by 2002:a6b:4e0b:: with SMTP id c11mr9404340iob.125.1605561757353; Mon, 16 Nov 2020 13:22:37 -0800 (PST) MIME-Version: 1.0 References: <255afe94-837a-8669-55c0-ea85cee7d0af@huitema.net> In-Reply-To: <255afe94-837a-8669-55c0-ea85cee7d0af@huitema.net> From: Ben Schwartz Date: Mon, 16 Nov 2020 16:22:26 -0500 Message-ID: To: Christian Huitema Cc: "add@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000003be01905b43ffab8" Archived-At: Subject: Re: [Add] STUN for DNS? X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 21:22:40 -0000 --0000000000003be01905b43ffab8 Content-Type: multipart/alternative; boundary="000000000000369d0d05b43ffa96" --000000000000369d0d05b43ffa96 Content-Type: text/plain; charset="UTF-8" You might be interested in Akamai's whoami service [1], which does essentially what you're describing. Note that large recursive resolvers load-balance across a large number of exit IPs [2], so every query through such a system will return a different answer. I don't think we should rely on such a design in ADD. [1] https://developer.akamai.com/blog/2018/05/10/introducing-new-whoami-tool-dns-resolver-information [2] https://developers.google.com/speed/public-dns/faq#locations_of_ip_address_ranges_google_public_dns_uses_to_send_queries On Mon, Nov 16, 2020 at 3:21 PM Christian Huitema wrote: > Should we have the equivalent of STUN for DNS? STUN was defined many > years ago in the context of NAT traversal, so hosts behind a NAT could > enlist help from server and learn how their "public" IP address appears > on the other side of the NAT. Likewise, with STUN for DNS, hosts could > get help from a third-party server and learn the "public" IP address of > the recursive resolver configured on their system. One of the > applications would be to obtain the seed needed for the "equivalent > encrypted resolver" discovery; there are probably quite a few other > applications. > > The simplest design would be to configure the host with just the domain > name of the STUN for DNS resolver, say "s4d.example.net", and with a key > for that resolver. The host that wants to identify the local service > constructs a unique query by picking a random number "rrr", and asks for > a TXT record associated with "rrr.s4d.example.net". The request is > routed by the local resolver (maybe a Wi-Fi router) to a recursive > resolver and then to the selected server, which is authoritative for the > selected domain name (s4d.example.net). The STUN 4 DNS resolver > programmatically creates a TXT record containing the encrypted value of > the source address from which the query was received -- that is, the > address of the recursive resolver. That response will then be relayed to > the host. > > Would there be any interest in defining such service? > > -- Christian Huitema > > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000369d0d05b43ffa96 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You might be interested in Akamai's whoami service [1]= , which does essentially=C2=A0what you're describing.

Note that large recursive resolvers load-balance across a large number of= exit IPs [2], so every query through such a system will return a different= answer.

I don't think we should rely on such = a design in ADD.


On Mon, Nov 16, 2020 at 3:21 PM Christian Huitema <<= a href=3D"mailto:huitema@huitema.net">huitema@huitema.net> wrote:
Should we have the= equivalent of STUN for DNS? STUN was defined many
years ago in the context of NAT traversal, so hosts behind a NAT could
enlist help from server and learn how their "public" IP address a= ppears
on the other side of the NAT. Likewise, with STUN for DNS, hosts could
get help from a third-party server and learn the "public" IP addr= ess of
the recursive resolver configured on their system. One of the
applications would be to obtain the seed needed for the "equivalent encrypted resolver" discovery; there are probably quite a few other applications.

The simplest design would be to configure the host with just the domain
name of the STUN for DNS resolver, say "s4d.example.net", and wi= th a key
for that resolver. The host that wants to identify the local service
constructs a unique query by picking a random number "rrr", and a= sks for
a TXT record associated with "rrr.s4d.example.net". The requ= est is
routed by the local resolver (maybe a Wi-Fi router) to a recursive
resolver and then to the selected server, which is authoritative for the selected domain name (s4d.example.net). The STUN 4 DNS resolver
programmatically creates a TXT record containing the encrypted value of
the source address from which the query was received -- that is, the
address of the recursive resolver. That response will then be relayed to the host.

Would there be any interest in defining such service?

-- Christian Huitema


--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000369d0d05b43ffa96-- --0000000000003be01905b43ffab8 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPmAYJKoZIhvcNAQcCoIIPiTCCD4UCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggzyMIIEtjCCA56gAwIBAgIQeAMYYHb81ngUVR0WyMTzqzANBgkqhkiG9w0BAQsFADBMMSAwHgYD VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE AxMKR2xvYmFsU2lnbjAeFw0yMDA3MjgwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFQxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFz IFIzIFNNSU1FIENBIDIwMjAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvLe9xPU9W dpiHLAvX7kFnaFZPuJLey7LYaMO8P/xSngB9IN73mVc7YiLov12Fekdtn5kL8PjmDBEvTYmWsuQS 6VBo3vdlqqXZ0M9eMkjcKqijrmDRleudEoPDzTumwQ18VB/3I+vbN039HIaRQ5x+NHGiPHVfk6Rx c6KAbYceyeqqfuJEcq23vhTdium/Bf5hHqYUhuJwnBQ+dAUcFndUKMJrth6lHeoifkbw2bv81zxJ I9cvIy516+oUekqiSFGfzAqByv41OrgLV4fLGCDH3yRh1tj7EtV3l2TngqtrDLUs5R+sWIItPa/4 AJXB1Q3nGNl2tNjVpcSn0uJ7aFPbAgMBAAGjggGKMIIBhjAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHzM CmjXouseLHIb0c1dlW+N+/JjMB8GA1UdIwQYMBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MHsGCCsG AQUFBwEBBG8wbTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3Ry MzA7BggrBgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvcm9vdC1y My5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIz LmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5n bG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEANyYcO+9JZYyqQt41 TMwvFWAw3vLoLOQIfIn48/yea/ekOcParTb0mbhsvVSZ6sGn+txYAZb33wIb1f4wK4xQ7+RUYBfI TuTPL7olF9hDpojC2F6Eu8nuEf1XD9qNI8zFd4kfjg4rb+AME0L81WaCL/WhP2kDCnRU4jm6TryB CHhZqtxkIvXGPGHjwJJazJBnX5NayIce4fGuUEJ7HkuCthVZ3Rws0UyHSAXesT/0tXATND4mNr1X El6adiSQy619ybVERnRi5aDe1PTwE+qNiotEEaeujz1a/+yYaaTY+k+qJcVxi7tbyQ0hi0UB3myM A/z2HmGEwO8hx7hDjKmKbDCCA18wggJHoAMCAQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUA MEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWdu MRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEg MB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzAR BgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4 Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuu l9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJ pij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh 6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti +w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEA S0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9u bG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaM ld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88 q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/f hO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBNEwggO5oAMCAQICEAE/JGAv3XK3SRaKvGds QSwwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gQXRsYXMgUjMgU01JTUUgQ0EgMjAyMDAeFw0yMDA5MDgy MzQzNTNaFw0yMTAzMDcyMzQzNTNaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFzY0Bnb29nbGUuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7rjWsiqQSnXGFTvs/2JDygQFtWsgF+Ce W2I/wmwCuWH2eNUBYslyudWmJsUMi7IbeSsKHrvBI2P7k6sk5p6o3uFlomiFaDMqXcn76t5GNGym CmHm5KBWxc3LfyvR4C2/wg9oUwbL2xxXc6QQpWWE4ONn9NMHwNC396Ih5u7tcrH5eF49HbVarP5i TindWAOzz++JA3VC/1lIkqWvOt2BcBtxQDUnYp8sr8UnMF/6UqtCd0aHJnKkvYi4o8Qo5Qf3YgiJ DzADzBTf54o3NAI3hiIVKPvz1l0g78IcR29Bt9jUrE33qGzGB6HoY7Z8quhA/ngW2XjuLkIY1ZKX AwTXBQIDAQABo4IBzzCCAcswHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5jb20wDgYDVR0PAQH/ BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUu687mSaB85ui VgNNFSUhtTljkxEwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYmaHR0cHM6 Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wCQYDVR0TBAIwADCBmgYIKwYBBQUHAQEE gY0wgYowPgYIKwYBBQUHMAGGMmh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL2NhL2dzYXRsYXNy M3NtaW1lY2EyMDIwMEgGCCsGAQUFBzAChjxodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2Nh Y2VydC9nc2F0bGFzcjNzbWltZWNhMjAyMC5jcnQwHwYDVR0jBBgwFoAUfMwKaNei6x4schvRzV2V b4378mMwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9jYS9nc2F0 bGFzcjNzbWltZWNhMjAyMC5jcmwwDQYJKoZIhvcNAQELBQADggEBAG9R1/y5PatVOc8xLrAmGgNO /Q4+lbJuHNwX3aIpOkM72Ot4r6r5/IFOSx1pMpmzvrECyy5YQzUGkHV4atuNq5YPPNMGa+XlaKSg oU2dA6RCD40dtwmrPxrKiGAfHPNvfmRvgnx9qxBKFPbKF/Tn8BwKSZCSvx33TnQRfqLUTcgrAarQ dF9Oc45moJrn4nVF0VTTPI6LVminvjg3tLgF2bny1N6CitQnb1t67vpYjeNpcXNIGQzEDaYI3WnK rVeZMcLSY+Z2dQH8HvVsA95vFCTywgiWKq5KxFqz/GdB6JhDWcIJIKCJVUyqD/Bjx47+e4Ye/FuD NDSYc+613Ozl3TkxggJqMIICZgIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFzIFIzIFNNSU1FIENBIDIwMjACEAE/ JGAv3XK3SRaKvGdsQSwwDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIKM5P/2RmJP0 efYhKSUNVFZdt/mII56WtEyKuK3/UG0vMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTIwMTExNjIxMjIzN1owaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJ YIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcN AQEHMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQBnXQ3MgKB7e0eiVRK61vXERPEI9sAI zSTtUy5P91Q5hxk6rmdEp408C+WVcTytw7JiHy6jUOnsrr0YoVcOohctRe+nUkLkUvuM3kcGLxQr jTzXEVA104TtRkQE2bFjeQxjBgorpxo8irHSMTa+467DwUbE+VVvuePTklsCzrFeVpXPIwsRJbmU zwtRRIqlTMHQXRsaTSG6/1mLNYEW4W+FveOf9okcmtCLL+spo0qS1mHxud/GJyEftwz8nB5mI5GM GDVPVJ4EfRQtXuGmM77zViz3w1JyJGgygYBlbfDac5lcY4dpQ36j4LcsN5UiwvkwxADzG1OqjMrn i4UVX71Z --0000000000003be01905b43ffab8-- From nobody Mon Nov 16 13:56:08 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315C63A14ED for ; Mon, 16 Nov 2020 13:56:06 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.onmicrosoft.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 jDpGcrDnl9Jo for ; Mon, 16 Nov 2020 13:56:04 -0800 (PST) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110063.outbound.protection.outlook.com [40.107.11.63]) (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 A236A3A14EF for ; Mon, 16 Nov 2020 13:56:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WTWLmef2ff0lSl0+811p3T3WoYPOsQxC5RUiLMmMY32vl8gOXwyrw3kedZN2PInHrqjU8kfsKNg6GWIwzhALRdsk6MkhqKNhmHCSiyTt2LnSeEfm7C0u5F+fN/DIGWP8vIBPJpAXS/jP3Hfr5rMru1oZRyQFXICWwfjuSvh0kp09234H0DAunGwDn87/lkheS2xqp3IvNRMNDb+OHnu6uicRC8mmEQt4Hn8KvZSDVuW7SOY0FeXFcqaxeiC70QexbeE03xwWPV8xi8v/Xbthj3q8aMoMskXqaIHpJ95+X6SWjRX4KygafuYcWJQXnQrC6bqHSs6LcqURjgbD2AJaDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E05wLc7vOGPhubdoRi/4AydmY57qzMPSIimdTFWPtgs=; b=R/l7ZM60b43jPuaRPf/4i89KUd3F00xdcZQoEiqK4x2lyjpwPY+YcU38gdpXOr+ZJnzM59MEDc3GTP+R2C2rMpsoDgCGts3hyhlVo+GQ2BfbDcEJ/ylcV0Fwgg0vJvVEb0Z5cuSCDIgd0JnYEbVE6n1zbYqwo3l/UEGXzUEQtut1oKIw+Wmqz50ElGZcdVRElxdoU2BWjChhoKwreyVYrz4pkxJTvd/1+HdbQqxjoKxTs3UYLV7PHcbjQ+eiM2XVnnkzP07ZJXb3VNWd8xboeVo9fcCBAnr4aqy3Eu73G36PFLBLCXgviiOoM6v8HWChkEZoc/X0EwZasch3SRWTtw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E05wLc7vOGPhubdoRi/4AydmY57qzMPSIimdTFWPtgs=; b=Gy5YtdFO+zk5SmFdvhoVweUPN5UBZN9c4Z6rsRX0c5OsyYBtVJ71mHgTf6vZqPFj5/7TvKYejTWWq1WigtQd32v6tvXfpC4RcJNhVfLlTeUeef2nbl4kWAjt0cPUYWk5lauahCG/BrS/qitKJw5cTBZkpih/4XSYfsbhTr/Omtg= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:71::15) by LNXP265MB1419.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:7d::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.24; Mon, 16 Nov 2020 21:56:01 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::199b:a430:6264:9bf6]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::199b:a430:6264:9bf6%7]) with mapi id 15.20.3564.028; Mon, 16 Nov 2020 21:56:01 +0000 From: Andrew Campling To: Eric Orth , Tommy Jensen , "add@ietf.org" Thread-Topic: [Add] EER bootstrapping draft scopes Thread-Index: AQHWu//el2OuiKw0V0io/I7dydoZGanLST4w Date: Mon, 16 Nov 2020 21:56:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=419.consulting; x-originating-ip: [86.144.97.96] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2111e13d-0511-4a56-c43b-08d88a7a6837 x-ms-traffictypediagnostic: LNXP265MB1419: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5XQ9euK0TcwDAZwa2G7XCRkWwp1zNF2Ve5maqasJPnlqyM9VY+iQMIA6uIko0r7CNYVeN8qVDH1r++/hDH2HBZbkjdq3DAbqXO76jOeVZjupw5N1CNVX4fUqGq5ASmz+lkXyNJJ+J8OypqzXGJKPwLMssPSb7jkR4+BXe3IvoNShLvExol/F0B8zYbHHNKfBd/BLQiiV8b7+nYk0AC+VZPsiAnXCoe6wb/zHT1h14voFrR18ZTCeR/FZ7SwQFG0OW6+JoQ8bepwen+llqzJskVcOTY9OL3M2bYD8pwKIQGOJzatLu3/qun9IraTs+qRQlAm07C42cMbh0eL2VAuArVKthbuyW6GSrQ/Aj2pc2qNzIOZRbVQSSII8rvt5xBVrnj9KODB+rEFV1OVtstUdHffMFHG+h6+HZKC4eXNjbJLBhiigRlTBXEL1iQs8sP9u x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(396003)(39830400003)(346002)(376002)(136003)(366004)(71200400001)(33656002)(66574015)(316002)(110136005)(86362001)(26005)(478600001)(6506007)(76116006)(66946007)(53546011)(186003)(8676002)(44832011)(7696005)(52536014)(5660300002)(66556008)(2906002)(66446008)(166002)(83380400001)(55016002)(8936002)(9686003)(966005)(64756008)(66476007)(46492008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: HqavLLv6G+mZAdUgtkmHZnLTaUXkSm346AAqejfSjk847CsuRlF5afqZuSNhDPecULCj4nv0Jjj5Hi++7j83i9Bdi6/xTCq+d5F+mtwnWkxp0V/wlW/0IeXOuYs5YYdJLwTyisyIWteJDmI7yevKRhQLHm/o5IklU0WilBGte9tnWQwo4nX+IqLaLuF2iD3VBf1z4XCA64b13mVlQv7MH9cx1VIEygGn1oRwsbv+7sw/F9i5yTLP+/8JJuTwEqhXVkKN0p2WNsKCQahgDdRPJQidk1jD3yKbuAfQy1lyZtIJW8FKEH33lZkjMZWdKCJJxQmJNTAdxU8gqSgm4S4lzPFo9BfTuvRCaWbDn68YzeGjSGgy0eo/xf6UgOv1HxDbUyWK+mWbtjcMSJd+4yLlw401z9bcywy8Vpo8hEYc6S2+8obMJdrmyC2ecY44c6g76lgv/jjINWseVmSPbIt7hqH9JC6+jEvF3nv3v1hOZZow6gvWFsa1NZMoVw4/+nY6k6MpT5aZ+thkA+lZIzxMaUd4XOQzXM2BEa/UlUzAsTtWAiI1+ENF8w4cePWawKabtwaw5joQU/v9/zT7LiITu+FEfOaVUCwIm4A2khPXUDASCnz3oXye8GpL2yeZZlf2Wq/lnu8SAun1QkDfZcYXI7XnQ6b9Nf77QhZy1iwHqZucH5XgO6f4XUWi0PJrAKW21mg3gT8ADHgMcZZEJXyxc+GnDJL5QqnlbB8aoDiJo/jqioadSv6gJAXIH48UjRoTUIJrIx8gQ8Wg/tsrVCvWj6YIaocedINjVcZxLcksa4irdtHPCBnVrzaWIwqE4oTKi3XRt+jHI5CPEzxlgJ95hg5eouYNwdulrPT0kI7SeSX+Z2sxtRYLvxUjDEVMynUR0+7bSDNq/rw2unrpKrVplA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P265MB0573E4604C73BC9214E170EAC2E30LO2P265MB0573GBRP_" MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 2111e13d-0511-4a56-c43b-08d88a7a6837 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2020 21:56:01.1433 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 2sbtZYsDthSrEgbKVnL6K9NGcS4bm6QeS+XLxE8c5WjCeCdOE/5IISsGbByrc3EKEFghn9xUV4VpXt19L9MaRIBsljwyW7iFdCOprpH0Hlg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP265MB1419 Archived-At: Subject: Re: [Add] EER bootstrapping draft scopes X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 21:56:06 -0000 --_000_LO2P265MB0573E4604C73BC9214E170EAC2E30LO2P265MB0573GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gdGhlIDg1JSBmaWd1cmUsIHdoZW4gd2UgZGlkIHRoZSBvcGVyYXRvciBvYnNlcnZhdGlvbnMg ZHJhZnQgdG8gZG9jdW1lbnQgdGhlIEROUyBmb3J3YXJkZXIgLyBSRkMgMTkxOCB1c2FnZSBmb3Ig SUVURiAxMDggKHNlZSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jYW1w bGluZy1vcGVyYXRvci1vYnNlcnZhdGlvbnMvP2luY2x1ZGVfdGV4dD0xKSwgdGhlIHN0YXRzIGZy b20gdGhlIGxhcmdlciBJU1BzIHN1Z2dlc3RlZCBhcm91bmQgOTAlIG9mIHRoZWlyIGNvbnN1bWVy IGJhc2UgdXNlZCB0aGVpciBETlMgcmVzb2x2ZXJzLCBob3dldmVyIHRoZXJlIGFyZSBvZiBjb3Vy c2Ugc29tZSBJU1BzIHRoYXQgb3V0c291cmNlIEROUyB0byBjbG91ZCBwcm92aWRlcnMgc28gODUl IHNlZW1zIHRvIGJlIGluIHRoZSByaWdodCBiYWxscGFyayBvdmVyYWxsLiAgV2UgZGlkbuKAmXQg bG9vayBhdCB0aGUgJSBvZiB0aGUgQ1BFIGJhc2UgdGhhdCBjb3VsZCBiZSB1cGdyYWRlZCBidXQg bm90ZWQgdGhhdCBzb21lIHVuaXRzIHdlcmUgdXAgdG8gdGVuIHllYXJzIG9sZCwgd2l0aCA2MC04 MCUgb2YgdGhlIGJhc2UgdHlwaWNhbGx5IElTUC1wcm92aWRlZCBhbmQgbWFuYWdlZCAodGhlcmUg d2FzIHNvbWUgdmFyaWFiaWxpdHkgaGVyZSkuDQoNCkFuZHJldw0KDQpGcm9tOiBFcmljIE9ydGgg PGVyaWNvcnRoQGdvb2dsZS5jb20+DQpTZW50OiAxNiBOb3ZlbWJlciAyMDIwIDEwOjA0DQpUbzog VG9tbXkgSmVuc2VuIDxKZW5zZW4uVGhvbWFzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9y Zz4NCkNjOiBhZGRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQWRkXSBFRVIgYm9vdHN0cmFwcGlu ZyBkcmFmdCBzY29wZXMNCg0KTXkgdGFrZTogVGhlIGJlc3QgYmFuZy1mb3ItYnVjayBjYXNlIHdl IGNvdWxkIGZpZ3VyZSBvdXQgYSBzb2x1dGlvbiBmb3IgaXMgZGVhbGluZyB3aXRoIHVwZ3JhZGlu ZyB1c2VycyBjdXJyZW50bHkgY29uZmlndXJlZCB0byB1c2UgYSBsZWdhY3kgaG9tZSByb3V0ZXIg dGhhdCBjYW5ub3QgZG8gZW5jcnlwdGlvbiBvciBhZHZlcnRpc2UgYSBkaWZmZXJlbnQgSVAuICBJ IHRoaW5rIGl0J3MgdGhlIGJpZ2dlc3QgcHJvYmxlbSB0aGF0IG1hbnkgY2xpZW50cyBkb24ndCBo YXZlIGFueSBzdG9yeSB0byBkby4gIEJ1dCB0aGF0IGRvZXNuJ3QgbWVhbiBERUVSJ3MgbW9yZSBs aW1pdGVkIGNhc2UgaXMgbm90IGFsc28gYSB3b3J0aHkgcHJvYmxlbSB0byBzb2x2ZSwgYW5kIGl0 IHNlZW1zIHRvIGZpdCB3ZWxsIGludG8gdGhlIHNwaXJpdCBvZiBzaW1wbGVyIGRyYWZ0cyBzY29w ZWQgdG8gaW5kaXZpZHVhbCBjYXNlcy4NCg0KQW5kIHNpbmNlIEknbSB0aGUgc291cmNlIG9mIHRo ZSAxNSUgc3RhdCwgSSBzaG91bGQgY2xhcmlmeTogT25seSBhcHByb3hpbWF0ZWx5IDE1JSBvZiBD aHJvbWUgdXNlcnMgaGF2ZSBhIG5vbi1wcml2YXRlIElQIGNvbmZpZ3VyZWQgYXMgdGhlIEROUyBz ZXJ2ZXIuICBJIGRvbid0IGhhdmUgYW55IGRhdGEgb24gd2hhdCBwb3J0aW9uIG9mIHRoYXQgcmVt YWluaW5nIDg1JSBjYW4gb3IgY2Fubm90IHJ1biBlbmNyeXB0ZWQgRE5TIG9uIHRoYXQgc2FtZSBw cml2YXRlIElQLCBvciB3aGF0IHBvcnRpb24gY291bGQgcG90ZW50aWFsbHkgaGF2ZSBhbiBJU1Ag b3Igc2ltaWxhciByZWNvbmZpZ3VyZSB0byBwb2ludCBESENQIGF0IGEgbm9uLXByaXZhdGUgSVAs IHNvIERFRVIgY291bGQgcG90ZW50aWFsbHkgc3RpbGwgYmUgYXBwbGljYWJsZSBmb3IgbXVjaCBt b3JlIHRoYW4ganVzdCB0aGF0IDE1JS4NCg0KT24gTW9uLCBOb3YgMTYsIDIwMjAgYXQgNDo0OCBB TSBUb21teSBKZW5zZW4gPEplbnNlbi5UaG9tYXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYu b3JnPG1haWx0bzo0MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCihNYXJ0 aW4sIEkgc2VlIHlvdSBqdXN0IHRvdWNoZWQgb24gdGhlIDE1JSBjb21tZW50IG9uIGFub3RoZXIg dGhyZWFkOyBJIGZpZ3VyZSB0aGlzIGRlc2VydmVzIGEgc2VwYXJhdGUgdGhyZWFkKQ0KDQpPbmUg b2YgdGhlIERFRVIgZmVlZGJhY2sgcG9pbnRzIHRoYXQgY2FtZSB1cCBkdXJpbmcgdGhlIE1vbmRh eSBzZXNzaW9uIHdhcyB0aGF0IGl0IGFkZHJlc3NlcyBhIG1pbm9yaXR5IG9mIGNhc2VzIChzb21l b25lIHRocmV3IG91dCAxNSUpLiBJJ20gc3VycHJpc2VkIHRvIGhlYXIgZm9sa3MgY29uc2lkZXIg dGhhdCBhIGJsb2NrZXIgdG8gYWRvcHRpb24gY29uc2lkZXJpbmcgdGhlIGFkdmljZSBmcm9tIHRo ZSBjaGFpcnMgZm9sbG93aW5nIHRoZSBpbnRlcmltIHRvIHRyeSBhbmQgY2xlYXJseSBkZWZpbmUg c29sdXRpb24gc2NvcGVzLiBNeSB0YWtlYXdheSBmcm9tIHRoYXQgd2FzIGl0IHdvdWxkIG1ha2Ug c2Vuc2UgdG8gaGF2ZSBtdWx0aXBsZSwgY2xlYW5seS1zY29wZWQgc29sdXRpb25zIGFzIG9wcG9z ZWQgdG8gYSBtb25vbGl0aGljIHNvbHV0aW9uIGZvciBldmVyeSBzY2VuYXJpby4NCg0KV2UgZmVl bCBicmVha2luZyB1cCB0aGUgZGlmZmVyZW50IHNjZW5hcmlvcyBtYWtlcyBzZW5zZSBnaXZlbiB0 aGUgd2lkZSB2YXJpZXR5IG9mIGRpZmZlcmVudCByZXF1aXJlbWVudHMgZWFjaCBzb2x1dGlvbiBo YXMuIERFRVIgaXMgcHJlc2VudGVkIGFzIGEgd2F5IHRvIHZlcmlmeSBib290c3RyYXBwaW5nIGZy b20gYSBwdWJsaWMgSVAgYWRkcmVzcywgd2l0aCBhbiBvcHBvcnR1bmlzdGljIChub3QgdmVyaWZp YWJsZSkgbWV0aG9kIGZvciBzYW1lIElQIGFkZHJlc3MuIEFub3RoZXIgbWFqb3Igc2NlbmFyaW8g aXMgZm9yIGFuIFJGQzE5MTggZm9yd2FyZGVyIHRvIHJlZmVyIHRvIGFuIHVwc3RyZWFtIHJlc29s dmVyIGdpdmVuIHRoZSBDUEUgY2Fubm90IGJlIHVwZGF0ZWQgd2l0aCBhIHNhbWUtSVAgRUVSLiBE b2VzIGl0IG5vdCBtYWtlIHNlbnNlIHRvIGxldCBhIHNpbmdsZSBkcmFmdCBmb2N1cyBvbiB0aGF0 IHNjZW5hcmlvIHRoYXQgaXNuJ3QgcmVxdWlyZWQgdG8gYWxzbyBhdXRoZW50aWNhdGUgcHVibGlj IHNlcnZlciBib290c3RyYXBwaW5nPw0KDQpJZiB0aGUgdHdvIHNjZW5hcmlvcyBlbmQgdXAgd2l0 aCBkaWZmZXJlbnQgc2VjdXJpdHkgZ3VhcmFudGVlcyAod2hpY2ggc2VlbXMgcHJvYmFibGUpLCBJ IHRoaW5rIGl0IG1ha2VzIHNlbnNlIHRvIGhhdmUgZGlmZmVyZW50IG1lY2hhbmlzbXMgc28gYWRv cHRlcnMgY2FuIGNob29zZSB0byBkbyBvbmUgb3IgdGhlIG90aGVyIG9yIGJvdGggZGVwZW5kaW5n IG9uIHRoZWlyIG5lZWRzLg0KDQpUaGFua3MsDQpUb21teQ0KLS0NCkFkZCBtYWlsaW5nIGxpc3QN CkFkZEBpZXRmLm9yZzxtYWlsdG86QWRkQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9hZGQNCg== --_000_LO2P265MB0573E4604C73BC9214E170EAC2E30LO2P265MB0573GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk9uIHRoZSA4NSUg ZmlndXJlLCB3aGVuIHdlIGRpZCB0aGUgb3BlcmF0b3Igb2JzZXJ2YXRpb25zIGRyYWZ0IHRvIGRv Y3VtZW50IHRoZSBETlMgZm9yd2FyZGVyIC8gUkZDIDE5MTggdXNhZ2UgZm9yIElFVEYgMTA4IChz ZWUNCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNhbXBs aW5nLW9wZXJhdG9yLW9ic2VydmF0aW9ucy8/aW5jbHVkZV90ZXh0PTEiPg0KaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY2FtcGxpbmctb3BlcmF0b3Itb2JzZXJ2YXRpb25z Lz9pbmNsdWRlX3RleHQ9MTwvYT4pLCB0aGUgc3RhdHMgZnJvbSB0aGUgbGFyZ2VyIElTUHMgc3Vn Z2VzdGVkIGFyb3VuZCA5MCUgb2YgdGhlaXIgY29uc3VtZXIgYmFzZSB1c2VkIHRoZWlyIEROUyBy ZXNvbHZlcnMsIGhvd2V2ZXIgdGhlcmUgYXJlIG9mIGNvdXJzZSBzb21lIElTUHMgdGhhdCBvdXRz b3VyY2UgRE5TIHRvIGNsb3VkDQogcHJvdmlkZXJzIHNvIDg1JSBzZWVtcyB0byBiZSBpbiB0aGUg cmlnaHQgYmFsbHBhcmsgb3ZlcmFsbC4mbmJzcDsgV2UgZGlkbuKAmXQgbG9vayBhdCB0aGUgJSBv ZiB0aGUgQ1BFIGJhc2UgdGhhdCBjb3VsZCBiZSB1cGdyYWRlZCBidXQgbm90ZWQgdGhhdCBzb21l IHVuaXRzIHdlcmUgdXAgdG8gdGVuIHllYXJzIG9sZCwgd2l0aCA2MC04MCUgb2YgdGhlIGJhc2Ug dHlwaWNhbGx5IElTUC1wcm92aWRlZCBhbmQgbWFuYWdlZCAodGhlcmUgd2FzIHNvbWUgdmFyaWFi aWxpdHkNCiBoZXJlKS4mbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+QW5kcmV3PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gRXJpYyBPcnRoICZsdDtlcmljb3J0 aEBnb29nbGUuY29tJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IDE2IE5vdmVtYmVyIDIwMjAgMTA6 MDQ8YnI+DQo8Yj5Ubzo8L2I+IFRvbW15IEplbnNlbiAmbHQ7SmVuc2VuLlRob21hcz00MG1pY3Jv c29mdC5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBhZGRAaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtBZGRdIEVFUiBib290c3RyYXBwaW5nIGRyYWZ0IHNj b3BlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgdGFr ZTogVGhlIGJlc3QgYmFuZy1mb3ItYnVjayBjYXNlIHdlIGNvdWxkIGZpZ3VyZSBvdXQgYSBzb2x1 dGlvbiBmb3IgaXMgZGVhbGluZyB3aXRoIHVwZ3JhZGluZyB1c2VycyBjdXJyZW50bHkgY29uZmln dXJlZCB0byB1c2UgYSBsZWdhY3kgaG9tZSByb3V0ZXIgdGhhdCBjYW5ub3QgZG8gZW5jcnlwdGlv biBvciBhZHZlcnRpc2UgYSBkaWZmZXJlbnQgSVAuJm5ic3A7IEkgdGhpbmsgaXQncyB0aGUgYmln Z2VzdCBwcm9ibGVtDQogdGhhdCZuYnNwO21hbnkgY2xpZW50cyBkb24ndCBoYXZlIGFueSBzdG9y eSB0byBkby4mbmJzcDsgQnV0IHRoYXQgZG9lc24ndCBtZWFuIERFRVIncyBtb3JlIGxpbWl0ZWQg Y2FzZSBpcyBub3QgYWxzbyBhIHdvcnRoeSBwcm9ibGVtIHRvIHNvbHZlLCBhbmQgaXQgc2VlbXMg dG8gZml0IHdlbGwgaW50byB0aGUgc3Bpcml0IG9mIHNpbXBsZXIgZHJhZnRzIHNjb3BlZCB0byBp bmRpdmlkdWFsIGNhc2VzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QW5kIHNpbmNlIEknbSB0aGUgc291cmNlIG9mIHRoZSAxNSUgc3RhdCwgSSBzaG91bGQg Y2xhcmlmeTogT25seSBhcHByb3hpbWF0ZWx5IDE1JSBvZiBDaHJvbWUgdXNlcnMgaGF2ZSBhIG5v bi1wcml2YXRlIElQIGNvbmZpZ3VyZWQgYXMgdGhlIEROUyBzZXJ2ZXIuJm5ic3A7IEkgZG9uJ3Qg aGF2ZSBhbnkgZGF0YSBvbiB3aGF0IHBvcnRpb24gb2YgdGhhdCByZW1haW5pbmcgODUlIGNhbiBv ciBjYW5ub3QgcnVuIGVuY3J5cHRlZA0KIEROUyBvbiB0aGF0IHNhbWUgcHJpdmF0ZSBJUCwgb3Ig d2hhdCBwb3J0aW9uIGNvdWxkIHBvdGVudGlhbGx5IGhhdmUgYW4gSVNQIG9yIHNpbWlsYXIgcmVj b25maWd1cmUgdG8gcG9pbnQgREhDUCBhdCBhIG5vbi1wcml2YXRlIElQLCBzbyBERUVSIGNvdWxk IHBvdGVudGlhbGx5IHN0aWxsIGJlIGFwcGxpY2FibGUgZm9yIG11Y2ggbW9yZSB0aGFuIGp1c3Qg dGhhdCAxNSUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIE1vbiwgTm92IDE2LCAyMDIwIGF0IDQ6NDggQU0gVG9tbXkgSmVuc2VuICZsdDtK ZW5zZW4uVGhvbWFzPTxhIGhyZWY9Im1haWx0bzo0MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5v cmciPjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPihNYXJ0aW4sIEkgc2VlIHlvdSBqdXN0IHRvdWNoZWQgb24gdGhl IDE1JSBjb21tZW50IG9uIGFub3RoZXIgdGhyZWFkOyBJIGZpZ3VyZSB0aGlzIGRlc2VydmVzIGEg c2VwYXJhdGUgdGhyZWFkKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5PbmUgb2Yg dGhlIERFRVIgZmVlZGJhY2sgcG9pbnRzIHRoYXQgY2FtZSB1cCBkdXJpbmcgdGhlIE1vbmRheSBz ZXNzaW9uIHdhcyB0aGF0IGl0IGFkZHJlc3NlcyBhIG1pbm9yaXR5IG9mIGNhc2VzIChzb21lb25l IHRocmV3IG91dCAxNSUpLiBJJ20gc3VycHJpc2VkIHRvIGhlYXIgZm9sa3MgY29uc2lkZXINCiB0 aGF0IGEgYmxvY2tlciB0byBhZG9wdGlvbiBjb25zaWRlcmluZyB0aGUgYWR2aWNlIGZyb20gdGhl IGNoYWlycyBmb2xsb3dpbmcgdGhlIGludGVyaW0gdG8gdHJ5IGFuZCBjbGVhcmx5IGRlZmluZSBz b2x1dGlvbiBzY29wZXMuIE15IHRha2Vhd2F5IGZyb20gdGhhdCB3YXMgaXQgd291bGQgbWFrZSBz ZW5zZSB0byBoYXZlIG11bHRpcGxlLCBjbGVhbmx5LXNjb3BlZCBzb2x1dGlvbnMgYXMgb3Bwb3Nl ZCB0byBhIG1vbm9saXRoaWMgc29sdXRpb24NCiBmb3IgZXZlcnkgc2NlbmFyaW8uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPldlIGZlZWwgYnJlYWtpbmcgdXAgdGhlIGRpZmZlcmVu dCBzY2VuYXJpb3MgbWFrZXMgc2Vuc2UgZ2l2ZW4gdGhlIHdpZGUgdmFyaWV0eSBvZiBkaWZmZXJl bnQgcmVxdWlyZW1lbnRzIGVhY2ggc29sdXRpb24gaGFzLiBERUVSIGlzIHByZXNlbnRlZCBhcyBh IHdheSB0byB2ZXJpZnkgYm9vdHN0cmFwcGluZw0KIGZyb20gYSBwdWJsaWMgSVAgYWRkcmVzcywg d2l0aCBhbiBvcHBvcnR1bmlzdGljIChub3QgdmVyaWZpYWJsZSkgbWV0aG9kIGZvciBzYW1lIElQ IGFkZHJlc3MuIEFub3RoZXIgbWFqb3Igc2NlbmFyaW8gaXMgZm9yIGFuIFJGQzE5MTggZm9yd2Fy ZGVyIHRvIHJlZmVyIHRvIGFuIHVwc3RyZWFtIHJlc29sdmVyIGdpdmVuIHRoZSBDUEUgY2Fubm90 IGJlIHVwZGF0ZWQgd2l0aCBhIHNhbWUtSVAgRUVSLiZuYnNwO0RvZXMgaXQgbm90IG1ha2Ugc2Vu c2UgdG8gbGV0DQogYSBzaW5nbGUgZHJhZnQgZm9jdXMgb24gdGhhdCBzY2VuYXJpbyB0aGF0IGlz bid0IHJlcXVpcmVkIHRvIGFsc28gYXV0aGVudGljYXRlIHB1YmxpYyBzZXJ2ZXIgYm9vdHN0cmFw cGluZz8mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+SWYgdGhlIHR3byBz Y2VuYXJpb3MgZW5kIHVwIHdpdGggZGlmZmVyZW50IHNlY3VyaXR5IGd1YXJhbnRlZXMgKHdoaWNo IHNlZW1zIHByb2JhYmxlKSwgSSB0aGluayBpdCBtYWtlcyBzZW5zZSB0byBoYXZlIGRpZmZlcmVu dCBtZWNoYW5pc21zIHNvIGFkb3B0ZXJzIGNhbiBjaG9vc2UgdG8gZG8NCiBvbmUgb3IgdGhlIG90 aGVyIG9yIGJvdGggZGVwZW5kaW5nIG9uIHRoZWlyIG5lZWRzLiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Ub21teTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8YnI+ DQpBZGQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkFkZEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPkFkZEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FkZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWRkPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_LO2P265MB0573E4604C73BC9214E170EAC2E30LO2P265MB0573GBRP_-- From nobody Mon Nov 16 14:21:21 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8033B3A1570 for ; Mon, 16 Nov 2020 14:21:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 t1HTJ8MJDj9l for ; Mon, 16 Nov 2020 14:21:18 -0800 (PST) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (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 05B693A1568 for ; Mon, 16 Nov 2020 14:21:17 -0800 (PST) Received: from pps.filterd (m0156893.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0AGMJIs4013782; Mon, 16 Nov 2020 17:21:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=QsO6a1tSr9VIuUbwxt/YvQY6OTj3tF2/PETLUdl/opE=; b=obkrS/0soMFD3ejyx+UvErdzIN/gAz+9nifSkXDXFq9BgFAgpN2cQKKTq39HcSpjWGJf gPmVCurfUX+w8w4w66+aS5nx9wF/TBufm0FcBjdv6Ba7ky4JW/no9XG8uShjv7HKmE9k MV0WPShqQ6PYrWxnragyFGDWP42NkD7pKmA7y8RgC/YEJlJlYr5hWL34R1eOTVY6XMLv qimp47h7k94aJQBeWeAN6+FnkhFZs63Dp+oWh54kywOwZR5NqMbLqGkf3gvYF8oJopqF /o/BxlaE7HWfLYI2MVn4HqmKnwTTc1VhdJuFyceWklog2FjoBXKq3u3zY0THJXWOtxEU uw== Received: from copdcexc37.cable.comcast.com (dlppfpt-po-1p.slb.comcast.com [96.99.226.137]) by mx0a-00143702.pphosted.com with ESMTP id 34tctrn953-28 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 16 Nov 2020 17:21:17 -0500 Received: from copdcexc33.cable.comcast.com (147.191.125.132) by COPDCEXC37.cable.comcast.com (147.191.125.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 16 Nov 2020 15:20:59 -0700 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by copdcexc33.cable.comcast.com (147.191.125.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Mon, 16 Nov 2020 15:20:59 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.109) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 16 Nov 2020 17:20:48 -0500 Received: from BYAPR11MB3111.namprd11.prod.outlook.com (2603:10b6:a03:90::25) by BYAPR11MB3623.namprd11.prod.outlook.com (2603:10b6:a03:b5::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.25; Mon, 16 Nov 2020 22:20:47 +0000 Received: from BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::190a:85b7:803:2fc7]) by BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::190a:85b7:803:2fc7%6]) with mapi id 15.20.3541.025; Mon, 16 Nov 2020 22:20:47 +0000 From: "Deen, Glenn" To: Stephane Bortzmeyer , Jim Reid CC: ADD Mailing list Thread-Topic: [EXTERNAL] Re: [Add] equivalence definition Thread-Index: AQHWvGa7Ps7gQUCqYkGYfzOuez+8EQ== Date: Mon, 16 Nov 2020 22:20:46 +0000 Message-ID: <015BB2D3-A0AC-441D-A5FF-765B772F0F58@nbcuni.com> References: <394A540C-81A8-4F86-8E62-FADC4A820D81@rfc1035.com> <20201116093136.GA21460@nic.fr> In-Reply-To: <20201116093136.GA21460@nic.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: nic.fr; dkim=none (message not signed) header.d=none;nic.fr; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2605:e000:141b:121:a134:b670:4185:15bf] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 445688b1-4911-4b5c-f42e-08d88a7dde02 x-ms-traffictypediagnostic: BYAPR11MB3623: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Mx5Z/xfO1C6VCqWzuynM0FgIVbIpQNgid2r93ipNp2hnPWsbjlEd8eSJi96ytoH/L/3UM2UV/eNBwv32ArN0hSHCpPobgOksOnDbveEFC8Ybb7rrRv7Fmn+oSJ1EJcnVvutWiFGLd8Fn9eBqov/CG0gr9HMX8oaeaxLw+b6Jn9yMufK6J6sa7ihnNraWtOFWAJ7xc0lmT/J0VTdhljn3GEngctR2Jaym7+7oNfBx76LXtLxc55XzfG2GBy0Fe9S3OEfzXZCnXiwngVRreYy3XMzGr9hT1oOz3vKZExYjxdO5FcovsOb7tezihrySpd+1oLb8vVmf5Oc8/Npj+MMaRApSQf9DEyTJpdH/0uIqEagXnsc8L38c+5yC0GvzguOaRd2bkNc3KSUPVPx3c8SNfQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3111.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(376002)(346002)(39860400002)(366004)(6512007)(9686003)(83380400001)(6486002)(186003)(316002)(2906002)(8936002)(110136005)(36756003)(6506007)(5660300002)(86362001)(8676002)(478600001)(66556008)(64756008)(66446008)(76116006)(53546011)(33656002)(71200400001)(66476007)(4326008)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: +hyWYyzSMQQxMSuHOKRL8SPmT3fzSrHeQDwF8tJ8LFzUAxHm8nPs4HCsW5bQMQ7pdyAh0NrRbvuFqBEaox/EoXCTRO5rieGmp6abI6KphT7uoRedcUxp1mUy+5cIZ2r7m7iy6tAH7dkR9/fj2AC0qRQPicLoSgELWvGNMYkQWIw4dDlaSBS88QdHnH/wt2jCPG5mf+25ETPquACajMi4BnBcTWH3Ctp3n99j+yziGYp6gbTrpAN5cH1KtzFqPqy+9oehXOvMfaTKrM3FAmDSWSs4uU1d4QQ8cgs3XTJ/SQBJ0lO6LR1jaWB1WMt/c7zLAkSeAg6cGkEcHCKQTx2fbEMmbrawRB5XYo45LFXSt80D8SM8TZ/BTx673Dx6I76NZpNWa1FkeQA1M1d4216QHm4/LNgXAyI6wRQrxpp+3so/ktvjZkJ3/alU69pubIe/kkf9wSKPQMs6ISlEUh0c11ygLmw2jquW0vUx6LbAq6f9oMpK418gvv3mwczDXwEmleOr0YDBWLHB2G9VpfjNs62lB2W1rXoz9wjNFwo0Zy3NDGsoBE0oWIVD1qFLQZIGH9lI4WZY6elvUhmaYpUbT1O45lvRksdaSsdaSivQbHSQZJkYQN1f43E499Od+YjVib7qvgCFGCq5sJJs6lEpQHK1px1azhERgdO+7wMitNtywT5EUJwYLfhr5U+eLU1ZyWhfKFh9Iicgb2Em2YD4LnGw2yph8Kh3kCEg2CMxQdPQlHnir/lqRf76xotlI0phEcbVdaqP3TT6SDQug8A6CYXRkNBtbEVQIvEboseo2DQLkEr7e0metGhjNbot1PuhNFx4T8fkPQhR4+cnthCI1XOht9fNqe2BYUS8b4olPflgRupiL/alzeKpMEHz7F6D/xawkzaoKqxKwTV056X7DvB5VqCQeRqfEJ3YkeCB0R+LaRtVgjGUG0NT6Eme5HB9IXBu4cE0upd8h2TP63rQDg== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IL6SdhiWRXnWXWWqkOE5OO6S3Ls3gC1TYqCNo/nrRxY40C7AORP+705hexmCVAuczhEu1+g6YW9t28osYymS0MDoot7j5EcayG+i82WIxsPG2cVZ2MY4Gn9k8f9dPuqqdFV+Zov2j9DN5qJJa89kLSPIB5YzFbc6f5RxlPwj/N0R2gCd3ULMgxMX8baRs3WlKxb0S//lr+OJkD+QJg0BpSK9OLK2z+T+KYa0nYPZz3HVuzddYicb/8WP9qRlbW3FXplrZ2bYst1QXLMv0UTG6t0oZSs+jOD+A1CRcLwVx6rY8AkTmvpkMDllsc48/HP2+/MKw/er+/HfVg+KKRe/eA== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ISyBFzdLqfCc75V1kE7TbahWxQ29l5d5+27ZNbWhK4U=; b=J6t/LS6c3D0lnTjT2yAy1ttsx/okVrrlyDqNuoPLcJuXapPKkp0teEXvKw7ENl9sKZpUEn4ee1iXVZN0gXTZ36noqHEfPnmKBYJJcGaWTOjDUCIWUxISgOvElNSFnU3Zyk0GLcnTGCSbHHD1SjB/WUHGWXUx0wHh/6YhCdu6Soos19l4OWor4G39VzyuDMuIJXoZ3PrQ+s5x9Izd+fgKVQVaxVonRiF3HM2fERszKgg12K8/Q+k91loxit5pbQ3UYrCFe2zqXPuTVlkTac9QPh9lRx/F6Sl23w98la9Xg4WW9m37pFk92tXLfLPfXabf72WGmSgOAmdbQrPLAl6xcg== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: BYAPR11MB3111.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 445688b1-4911-4b5c-f42e-08d88a7dde02 x-ms-exchange-crosstenant-originalarrivaltime: 16 Nov 2020 22:20:47.1306 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: /Dh1EsLlmr+4jdO7dn/dadyFx+ESwl8h9Dmu3ZiSXHW2UrAUZEovJbcYu/414awrHLa80UGWSg8FflvoKy/P2uCbwHNGTzKhDcOCMaRCKkE= x-ms-exchange-transport-crosstenantheadersstamped: BYAPR11MB3623 x-originatororg: comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <1E9A7F952394834FB13A7AA5ABE0F850@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWA X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-16_11:2020-11-13, 2020-11-16 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Add] [EXTERNAL] Re: equivalence definition X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 22:21:20 -0000 DQpPbiAxMS8xNi8yMCwgMTozMiBBTSwgIkFkZCBvbiBiZWhhbGYgb2YgU3RlcGhhbmUgQm9ydHpt ZXllciIgPGFkZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBib3J0em1leWVyQG5pYy5m cj4gd3JvdGU6DQoNCiAgICBPbiBNb24sIE5vdiAxNiwgMjAyMCBhdCAwODo0MTozOUFNICswMDAw LA0KICAgICBKaW0gUmVpZCA8amltQHJmYzEwMzUuY29tPiB3cm90ZQ0KICAgICBhIG1lc3NhZ2Ug b2YgMTEgbGluZXMgd2hpY2ggc2FpZDoNCg0KICAgID4gVGhlIHBvaW50IEkgZGlkbuKAmXQgZ2V0 IHRvIG1ha2UgYXQgdGhlIG1pa2UgaXMgdXNpbmcg4oCcdHdvIG9yIG1vcmUNCiAgICA+IHJlc29s dmVycyBvcGVyYXRlZCBieSB0aGUgc2FtZSBlbnRpdHnigJ0gYXMgdGhlIGRlZmluaXRpb24gb2YN CiAgICA+IGVxdWl2YWxlbmNlIHByb2JhYmx5IGRvZXNu4oCZdCB3b3JrOg0KDQogICAgQW5vdGhl ciBjYXNlIHdoZXJlIGl0IGRvZXNuJ3Qgd29yayBpcyB3aGVuIHRoZSBzYW1lIGVudGl0eSBvZmZl cnMNCiAgICBkaWZmZXJlbnQgc2VydmljZXMgKG9uZSBseWluZyBhbmQgb25lIG5vdCwgZm9yIGlu c3RhbmNlKSwgd2hpY2ggaXMNCiAgICBjb21tb24gYW1vbmcgcHVibGljIHJlc29sdmVycyA8aHR0 cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vcXVhZDkubmV0L2ZhcS9fXzshIVBJWmVl VzV3c2N5blJRITRDdkRrNVdCZDE4NkQ4bXQxalZ2WXg4T3kzODg3ejRLZ0dkQzFseVp5RlJoUktQ RU9PQ044ZmNGdmFsdnF0SHAkID4NCiAgICA8aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0 dHBzOi8vZG5zLnlhbmRleC5jb20vX187ISFQSVplZVc1d3NjeW5SUSE0Q3ZEazVXQmQxODZEOG10 MWpWdll4OE95Mzg4N3o0S2dHZEMxbHlaeUZSaFJLUEVPT0NOOGZjRnZiZFRrTmpxJCA+DQogICAg PGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL2Jsb2cuY2xvdWRmbGFyZS5jb20v aW50cm9kdWNpbmctMS0xLTEtMS1mb3ItZmFtaWxpZXMvX187ISFQSVplZVc1d3NjeW5SUSE0Q3ZE azVXQmQxODZEOG10MWpWdll4OE95Mzg4N3o0S2dHZEMxbHlaeUZSaFJLUEVPT0NOOGZjRnZaaTJ6 NndTJCA+LCBldGMNCg0KICAgIEkgc3VnZ2VzdCB0byBub3QganVzdCBzYXkgImVxdWl2YWxlbnQi IGJ1dCBiZSBtb3JlIHNwZWNpZmljOiAid2l0aA0KICAgIGVxdWl2YWxlbnQgYW5zd2VycyIuIEVx dWl2YWxlbnQgYW5zd2VycyBiZWluZyBkZWZpbmVkIGJ5IHRoZSB1c2VyJ3MNCiAgICB1c2UgY2Fz ZXMuIElmIHJlc29sdmVyIEEgY2Vuc29ycyBTY2lIdWIgYW5kIHJlc29sdmVyIEIgZG9lcyBub3Qs IHRoZXkNCiAgICBkbyBub3QgeWllbGQgZXF1aXZhbGVudCBhbnN3ZXJzLiBJZiByZXNvbHZlciBB IHNlZXMgZ21haWwuY29tIGF0DQogICAgMmEwMDoxNDUwOjQwMGU6ODA5OjoyMDA1IGFuZCByZXNv bHZlciBCIHNlZXMgaXQgYXQNCiAgICAyYTAwOjE0NTA6NDAwNzo4MTY6OjIwMDUsIHRoZXkgcHJv YmFibHkgZ2l2ZSBlcXVpdmFsZW50IGFuc3dlcnMsIGFzDQogICAgZmFyIGFzIHRoZSBvcmRpbmFy eSB1c2VyIGlzIGNvbmNlcm5lZC4NCg0KDQpGcm9tIHRoZSB1c2VyJ3MgcG9pbnQgb2YgdmlldyAt IHdoaWNoIGlzIGFsd2F5cyBhIHByaW9yaXR5IC0gdGhlIGdvYWwgaXMgdG8gbWVldCB0aGUgdXNl cidzIGV4cGVjdGF0aW9uIHRoYXQgdGhlICJ1cGdyYWRlZCIgRG9IL0RvVCByZXNvbHZlciB3aWxs IGNvbnRpbnVlIHRvIGdpdmUgdGhlIHNhbWUgc2VydmljZSB0aGF0IHRoZSBEbzUzIGRpZCBmb3Ig dGhlIHVzZXIsIHdpdGggdGhlIGFkZGl0aW9uIHRoYXQgdGhlIGNvbW11bmljYXRpb24gd2l0aCB0 aGUgc2VydmVyIGlzIG5vdyBlbmNyeXB0ZWQuDQoNCi1nbGVubg0KDQoNCg0KDQoNCg== From nobody Mon Nov 16 14:22:23 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150B83A1572 for ; Mon, 16 Nov 2020 14:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 G0cFI_doffPk for ; Mon, 16 Nov 2020 14:22:19 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 7989F3A1570 for ; Mon, 16 Nov 2020 14:22:18 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id u18so27315786lfd.9 for ; Mon, 16 Nov 2020 14:22:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=35eYKs4pSyCv8CtK/sFzsNtTQnH7Wctbp3wlOeX8ruQ=; b=NMMsiHwSty/JdKcEca/QhL0Bxd2wbll9POBCtBJENpkaMcuK/wLEsSiW3wrAb1RqWP la1QI8XgKWtLgjW6+hdmjvj6KTFKf16voEpL8/OII1J+9WRYWcFWiq9actoqv0pEFc/T CFSPVCNdTPiMb6JAx/SCpe/UFUUMlYXNTL+kOaSlwsbL5Ni+MC0vnEZr7/i5Tt6/FS7h nWgpQVxZ/d5yO7Bt/40EvY6A5sNUbrtKxU4zPFjH1DkFK2yS3qTIxYp/iSY3byUqofwZ 6Z/jIa17JEw2tDhDYkEqCut7QaAlyBWRdTTWiQhumkE8aS0A8tlYvf62yUvdxR1h+Czv kjEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=35eYKs4pSyCv8CtK/sFzsNtTQnH7Wctbp3wlOeX8ruQ=; b=JHp8++Nk1mIQcQiAweKSgkn3qWYEIgqtJYcDDpNKc2PwMDsYSw5xwFGhIZGCXiy++r OirBj21ZA5ANbl2ynYCTarnUY4Xeq9B+lYdthnUvNfH3Dc5wejfxh5W7B4EqlQkuf7HR VIbi+CEEcLh1g0LT0T+Q1o1K6iCFjDd+bqgG1aRsAmV0cJHvpOBFKAchzOli5XbS4dpX 1h3L31oKlcs5VfjjkajtV1Y3MIROME5S958TSKIOlUROohq34MjGvss04fmg/pl6tHO+ OoJhsV0yGu74k9xph0+fQM53ddnDg3hioN7USrWcMzwL+BVqsgy0yFdlwRyHacivs5bw 3Qlw== X-Gm-Message-State: AOAM5318CFLIkOqkdraBlL9JToOYdL2sdc8IZXJ3cG9vVZ/vjWRZdtaJ abb2S85AwcQOAN7eMpH0T/KE0udo5/GR529fwml62Q== X-Google-Smtp-Source: ABdhPJzScw4ILIjuNK5XeooqvmFdbSPZyL38Dqt6m233H881Geesx7tNhP+86OFAxVbWwWs+481gSyhACCQE48KOH1g= X-Received: by 2002:a05:6512:74e:: with SMTP id c14mr578372lfs.463.1605565336606; Mon, 16 Nov 2020 14:22:16 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Mon, 16 Nov 2020 14:21:40 -0800 Message-ID: To: Andrew Campling Cc: Eric Orth , Tommy Jensen , "add@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008d6b0905b440cfd2" Archived-At: Subject: Re: [Add] EER bootstrapping draft scopes X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 22:22:22 -0000 --0000000000008d6b0905b440cfd2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 16, 2020 at 1:56 PM Andrew Campling wrote: > On the 85% figure, when we did the operator observations draft to documen= t > the DNS forwarder / RFC 1918 usage for IETF 108 (see > https://datatracker.ietf.org/doc/draft-campling-operator-observations/?in= clude_text=3D1), > the stats from the larger ISPs suggested around 90% of their consumer bas= e > used their DNS resolvers > Does this distinguish between directly and indirectly. For instance, devices on my network (other than Fx, obviously) use the ISP-provided resolver but my AP DHCP vends a 1918 address and presumably proxies that in some way. -Ekr , however there are of course some ISPs that outsource DNS to cloud > providers so 85% seems to be in the right ballpark overall. We didn=E2= =80=99t look > at the % of the CPE base that could be upgraded but noted that some units > were up to ten years old, with 60-80% of the base typically ISP-provided > and managed (there was some variability here). > > > > *Andrew* > > > > *From:* Eric Orth > *Sent:* 16 November 2020 10:04 > *To:* Tommy Jensen > *Cc:* add@ietf.org > *Subject:* Re: [Add] EER bootstrapping draft scopes > > > > My take: The best bang-for-buck case we could figure out a solution for i= s > dealing with upgrading users currently configured to use a legacy home > router that cannot do encryption or advertise a different IP. I think it= 's > the biggest problem that many clients don't have any story to do. But th= at > doesn't mean DEER's more limited case is not also a worthy problem to > solve, and it seems to fit well into the spirit of simpler drafts scoped = to > individual cases. > > > > And since I'm the source of the 15% stat, I should clarify: Only > approximately 15% of Chrome users have a non-private IP configured as the > DNS server. I don't have any data on what portion of that remaining 85% > can or cannot run encrypted DNS on that same private IP, or what portion > could potentially have an ISP or similar reconfigure to point DHCP at a > non-private IP, so DEER could potentially still be applicable for much mo= re > than just that 15%. > > > > On Mon, Nov 16, 2020 at 4:48 AM Tommy Jensen 40microsoft.com@dmarc.ietf.org> wrote: > > (Martin, I see you just touched on the 15% comment on another thread; I > figure this deserves a separate thread) > > > > One of the DEER feedback points that came up during the Monday session wa= s > that it addresses a minority of cases (someone threw out 15%). I'm > surprised to hear folks consider that a blocker to adoption considering t= he > advice from the chairs following the interim to try and clearly define > solution scopes. My takeaway from that was it would make sense to have > multiple, cleanly-scoped solutions as opposed to a monolithic solution fo= r > every scenario. > > > > We feel breaking up the different scenarios makes sense given the wide > variety of different requirements each solution has. DEER is presented as= a > way to verify bootstrapping from a public IP address, with an opportunist= ic > (not verifiable) method for same IP address. Another major scenario is fo= r > an RFC1918 forwarder to refer to an upstream resolver given the CPE canno= t > be updated with a same-IP EER. Does it not make sense to let a single dra= ft > focus on that scenario that isn't required to also authenticate public > server bootstrapping? > > > > If the two scenarios end up with different security guarantees (which > seems probable), I think it makes sense to have different mechanisms so > adopters can choose to do one or the other or both depending on their > needs. > > > > Thanks, > > Tommy > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --0000000000008d6b0905b440cfd2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 16, 2020 at 1:56 PM Andre= w Campling <andrew.campling@419.consulting> wrote:

On the 85% figure, wh= en we did the operator observations draft to document the DNS forwarder / R= FC 1918 usage for IETF 108 (see https://datatracker.ietf.org/doc/draft-campling-operator-observations/?incl= ude_text=3D1), the stats from the larger ISPs suggested around 90% of t= heir consumer base used their DNS resolvers


Does this distinguish between directly and indirect= ly. For instance, devices on my network (other than Fx, obviously) use the = ISP-provided resolver but my AP DHCP vends a 1918 address and presumably pr= oxies that in some way.

-Ekr



, however there are of course some ISPs that outso= urce DNS to cloud providers so 85% seems to be in the right ballpark overall.=C2=A0 We didn= =E2=80=99t look at the % of the CPE base that could be upgraded but noted t= hat some units were up to ten years old, with 60-80% of the base typically = ISP-provided and managed (there was some variability here).=C2=A0

=C2=A0

Andrew

=C2=A0<= /span>

From: Eric Orth <ericorth@google.com>
Sent: 16 November 2020 10:04
To: Tommy Jensen <Jensen.Thomas=3D40microsoft.com@dmarc.ietf.org>=
Cc: add@ietf.org
Subject: Re: [Add] EER bootstrapping draft scopes

=C2=A0

My take: The best bang-for-buck case we could figure= out a solution for is dealing with upgrading users currently configured to= use a legacy home router that cannot do encryption or advertise a differen= t IP.=C2=A0 I think it's the biggest problem that=C2=A0many clients don't have any story to do.=C2=A0 But that does= n't mean DEER's more limited case is not also a worthy problem to s= olve, and it seems to fit well into the spirit of simpler drafts scoped to = individual cases.

=C2=A0

And since I'm the source of the 15% stat, I shou= ld clarify: Only approximately 15% of Chrome users have a non-private IP co= nfigured as the DNS server.=C2=A0 I don't have any data on what portion= of that remaining 85% can or cannot run encrypted DNS on that same private IP, or what portion could potentially have an ISP= or similar reconfigure to point DHCP at a non-private IP, so DEER could po= tentially still be applicable for much more than just that 15%.

=C2=A0

= (Martin, I see you just touched = on the 15% comment on another thread; I figure this deserves a separate thr= ead)

= =C2=A0

= One of the DEER feedback points = that came up during the Monday session was that it addresses a minority of = cases (someone threw out 15%). I'm surprised to hear folks consider that a blocker to adoption considering the advice from the chairs followin= g the interim to try and clearly define solution scopes. My takeaway from t= hat was it would make sense to have multiple, cleanly-scoped solutions as o= pposed to a monolithic solution for every scenario.

= =C2=A0

= We feel breaking up the differen= t scenarios makes sense given the wide variety of different requirements ea= ch solution has. DEER is presented as a way to verify bootstrapping from a public IP address, with an opportunistic (not verifiable) method fo= r same IP address. Another major scenario is for an RFC1918 forwarder to re= fer to an upstream resolver given the CPE cannot be updated with a same-IP = EER.=C2=A0Does it not make sense to let a single draft focus on that scenario that isn't required to also auth= enticate public server bootstrapping?=C2=A0

= =C2=A0

= If the two scenarios end up with= different security guarantees (which seems probable), I think it makes sen= se to have different mechanisms so adopters can choose to do one or the other or both depending on their needs.=C2=A0

= =C2=A0

= Thanks,

= Tommy

--
Add mailing list
Add@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/add

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--0000000000008d6b0905b440cfd2-- From nobody Mon Nov 16 15:54:26 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2413A1701 for ; Mon, 16 Nov 2020 15:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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 BWxeuNXI81Q2 for ; Mon, 16 Nov 2020 15:54:22 -0800 (PST) Received: from jax4mhob19.registeredsite.com (jax4mhob19.registeredsite.com [64.69.218.107]) (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 5FE223A1700 for ; Mon, 16 Nov 2020 15:54:22 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by jax4mhob19.registeredsite.com (8.14.4/8.14.4) with ESMTP id 0AGNsHnL063449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 16 Nov 2020 18:54:18 -0500 Message-Id: <202011162354.0AGNsHnL063449@jax4mhob19.registeredsite.com> Received: (qmail 32730 invoked by uid 0); 16 Nov 2020 23:54:17 -0000 X-TCPREMOTEIP: 73.251.233.169 X-Authenticated-UID: jw@pcthink.com Received: from unknown (HELO ?10.2.1.116?) (jw@pcthink.com@73.251.233.169) by 0 with ESMTPA; 16 Nov 2020 23:54:17 -0000 SavedFromEmail: jw@pcthink.com Date: Mon, 16 Nov 2020 18:54:15 -0500 Importance: normal From: =?UTF-8?Q?JW_=CE=BB_John_Woodworth?= To: add@ietf.org Cc: jw@pcthink.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_511245257172160" Archived-At: Subject: [Add] CAA recommendation (DEER) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 23:54:24 -0000 ----_com.samsung.android.email_511245257172160 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGVsbG8sV2hpbGUgcmVhZGluZyB0aGUgREVFUiBkcmFmdCwgSSBoYWQgdGhlIHRob3VnaHQgdGhh dCBpdCBtYXkgYmUgYSBnb29kIGlkZWEgdG8gbWFrZSB1c2Ugb2YgQ0FBIHJlY29yZHMgYSByZWNv bW1lbmRhdGlvbiBmb3IgZW5jcnlwdGVkLUROUyBjZXJ0aWZpY2F0ZXMuwqAgSSBjYW4gc2VlIHBv dGVudGlhbCBpc3N1ZXMgd2l0aCBvcGVuIENBIGlzc3VlZCBjZXJ0aWZpY2F0ZXMuVGhhbmtzLMKg Sm9obg== ----_com.samsung.android.email_511245257172160 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXYgZGlyPSJh dXRvIj5IZWxsbyw8L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRv Ij5XaGlsZSByZWFkaW5nIHRoZSBERUVSIGRyYWZ0LCBJIGhhZCB0aGUgdGhvdWdodCB0aGF0IGl0 IG1heSBiZSBhIGdvb2QgaWRlYSB0byBtYWtlIHVzZSBvZiBDQUEgcmVjb3JkcyBhIHJlY29tbWVu ZGF0aW9uIGZvciBlbmNyeXB0ZWQtRE5TIGNlcnRpZmljYXRlcy4mbmJzcDsgSSBjYW4gc2VlIHBv dGVudGlhbCBpc3N1ZXMgd2l0aCBvcGVuIENBIGlzc3VlZCBjZXJ0aWZpY2F0ZXMuPC9kaXY+PGRp diBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGly PSJhdXRvIj5UaGFua3MsJm5ic3A7PC9kaXY+PGRpdiBkaXI9ImF1dG8iPkpvaG48L2Rpdj48ZGl2 IGRpcj0iYXV0byI+PGJyPjwvZGl2PjwvYm9keT48L2h0bWw+ ----_com.samsung.android.email_511245257172160-- From nobody Mon Nov 16 21:16:21 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFDB3A0DCF for ; Mon, 16 Nov 2020 21:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Hn0SQJ0ozx0r for ; Mon, 16 Nov 2020 21:16:17 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 D33163A0DCC for ; Mon, 16 Nov 2020 21:15:18 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id m9so19873823iox.10 for ; Mon, 16 Nov 2020 21:15:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qnCQfXjlUn+85Ci0Dm0D5HIBMBIaPbUwLPq9o0jRCus=; b=A6NSHITegxEH65PSXnPJw3autZBzTwfCzSwMvKKrkqxChjWpfa8Rqi7TZ/XusXxFV+ n9Zzbk9QM1jZYkjRlv6mt1I8n8dTuu7Q7dPN4B0TPot5nV577Er6W+YtxbWZPpIqnyBN ud3oUEw64kdGfKZWZ3NEdLsCBOQej07Qml2yxW1fyVhnWt62hGr/RmONDNhQU3QU5sac nr0s6OqP0yZiTkcccPwLQQI2cG3goyOzzzJhFVbBLKIkmngPvMOdk0Pkk2gP8VxYmT8u 7CAd18apEQTYYA1QzTggKTbrL5P07OEjYgUEd6S3Hebz2UMU/64D389S+D9kNKbKje8f V+pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qnCQfXjlUn+85Ci0Dm0D5HIBMBIaPbUwLPq9o0jRCus=; b=WyhOOvFI1QZXTByaI1LOZ9gSWA+zbEAYSqFR/RPjTNVeAuQxLyz+kgXJuQt7OifvBK g6NemK+P7+cu4ygA/stg7pW9xdRMxt/Z1Wyc8D8R/7vIdhEWLDSWvJZhMWsyu03A/M53 JVNiwbBI/P6JDLXiyglQ8pAIAwZYcdS7fEL1JU6c2vli6YGbkVpg+MsoWs4PhFVJk6A5 ojBDw1Zb0HPN696r+BNz9FxbTDbPNnQnsqG7WnpldMw90hBQ/X9HGcNcsXwvicwGW4Cc cZxekpYVX1SpZTlh/FJqbW30gCD7jF4KxTLgI8XSIUS4o1Wo67ETwXT8BqVjHnWWk3d4 MDYA== X-Gm-Message-State: AOAM533s4isJvYUWYB7H9hFDd8yPdQuci7jlB/EvHF5s/RKFZUvVCQcA 12yjBsjJ54cS0kuhf+5jAk380hFEmYU81Z0GLSFXEALBw3s= X-Google-Smtp-Source: ABdhPJyNn+9gyRSbMW/0OduF/ZoFcwilb1dfrkeNHm0+XMLg3SycjE5thhTodqkyVOpvHwF/AmXNGfjPnRHUWt1Tfhc= X-Received: by 2002:a05:6602:24c7:: with SMTP id h7mr3248295ioe.73.1605590118031; Mon, 16 Nov 2020 21:15:18 -0800 (PST) MIME-Version: 1.0 References: <394A540C-81A8-4F86-8E62-FADC4A820D81@rfc1035.com> <20201116093136.GA21460@nic.fr> <680ed8e1-bdb9-4ed9-aa12-7c0efe2bb1da@www.fastmail.com> In-Reply-To: From: tirumal reddy Date: Tue, 17 Nov 2020 12:15:06 +0700 Message-ID: To: Ben Schwartz Cc: Martin Thomson , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000a3e42a05b44694e8" Archived-At: Subject: Re: [Add] equivalence definition X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 05:16:19 -0000 --000000000000a3e42a05b44694e8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 17 Nov 2020 at 04:03, Ben Schwartz wrote: > I think "equivalence" here is not an "equivalence relation"; it is not > symmetric. What we mean by "equivalent" is more like "equivalent or > better". > > I think part of our confusion is that we are describing two separate > things. Before recommending an upgrade from (unencrypted) server A to > (encrypted) server B: > > 1. What properties of these servers can the client prove to itself? > 2. What conditions are we asking the operator(s) of these servers to meet= ? > > For example, we might ask that the operator of server B conform to the > privacy policy of server A, but this is not verifiable by the client. > Similarly, I don't think we intend for clients to verify that they get th= e > same answers from servers A and B, even if we want the answers to be > "equivalent". > > In the local network use case, it's important to ask what properties the > client can prove about server A. In particular, I posit that any > persistent attacker who can answer queries sent to server A is > indistinguishable from server A. This suggests a possible solution to th= e > local network use case: ask the client to regularly revalidate server A's > intention to upgrade to server B, and stop using server B if server A sto= ps > recommending it. > Yes, an attacker may not be alway on-path. TOFU can also help to identify an non-zero day attacker modifying the responses to server A. -Tiru > > On Mon, Nov 16, 2020 at 4:39 AM Martin Thomson wrote: > >> My definition was slightly different: >> >> If we assume that either Do53 discovery was perfectly secure, OR that >> plus the Do53 resolver itself were perfectly secure, then - in the prese= nce >> of a Dolev-Yao attacker and any information obtained from those perfectl= y >> secure sources, can we provide something that uses TLS and is reasonably >> secure? >> >> I think that we can, but not in the presence of old DNS forwarders that >> can't be updated. >> >> What I heard from David Schinazi (though these were I think Eric Orth's >> figures) was that the environment was such that none of our existing >> solutions would work and we would need a looser definition if we were to= be >> able to offer DoH/DoT to most users. If we don't accept something a lit= tle >> more opportunistic, we only get ~15% of people (assuming that dataset is >> representative, which I believe it should be). >> >> On Mon, Nov 16, 2020, at 20:31, Stephane Bortzmeyer wrote: >> > On Mon, Nov 16, 2020 at 08:41:39AM +0000, >> > Jim Reid wrote >> > a message of 11 lines which said: >> > >> > > The point I didn=E2=80=99t get to make at the mike is using =E2=80= =9Ctwo or more >> > > resolvers operated by the same entity=E2=80=9D as the definition of >> > > equivalence probably doesn=E2=80=99t work: >> > >> > Another case where it doesn't work is when the same entity offers >> > different services (one lying and one not, for instance), which is >> > common among public resolvers >> > >> > , etc >> > >> > I suggest to not just say "equivalent" but be more specific: "with >> > equivalent answers". Equivalent answers being defined by the user's >> > use cases. If resolver A censors SciHub and resolver B does not, they >> > do not yield equivalent answers. If resolver A sees gmail.com at >> > 2a00:1450:400e:809::2005 and resolver B sees it at >> > 2a00:1450:4007:816::2005, they probably give equivalent answers, as >> > far as the ordinary user is concerned. >> > >> > "Equivalent" is too loaded to be used alone. >> > >> > >> > -- >> > Add mailing list >> > Add@ietf.org >> > https://www.ietf.org/mailman/listinfo/add >> > >> >> -- >> Add mailing list >> Add@ietf.org >> https://www.ietf.org/mailman/listinfo/add >> > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000a3e42a05b44694e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, 17 Nov 2020 at 04:03, Ben Schwart= z <bemasc=3D40google.com@= dmarc.ietf.org> wrote:
I think "equ= ivalence" here is not an "equivalence relation"; it is not s= ymmetric.=C2=A0 What we mean by "equivalent" is more like "e= quivalent or better".

I think part of our confusion= is that we are describing=C2=A0two separate things.=C2=A0 Before recommend= ing an upgrade from (unencrypted) server A to (encrypted) server B:

1. What properties of these servers can the client prove = to itself?
2. What conditions are we asking the operator(s) of th= ese servers to meet?

For example, we might ask tha= t the operator of server B conform to the privacy policy of server A, but t= his is not verifiable by the client.=C2=A0 Similarly, I don't think we = intend for clients to verify that they get the same answers from servers A = and B, even if we want the answers to be "equivalent".
=
In the local network use case, it's important to ask wha= t properties the client can prove about server A.=C2=A0 In particular, I po= sit that any persistent attacker who can answer queries sent to server A is= indistinguishable from server A.=C2=A0 This suggests a possible solution t= o the local network use case: ask the client to regularly revalidate server= A's intention to upgrade to server B, and stop using server B if serve= r A stops recommending it.

Yes,= an attacker may not be alway on-path. TOFU can also help to identify an no= n-zero day attacker modifying the responses to server A.=C2=A0
-Tiru=C2=A0

O= n Mon, Nov 16, 2020 at 4:39 AM Martin Thomson <mt@lowentropy.net> wrote:
My definition was slightly d= ifferent:

If we assume that either Do53 discovery was perfectly secure, OR that plus = the Do53 resolver itself were perfectly secure, then - in the presence of a= Dolev-Yao attacker and any information obtained from those perfectly secur= e sources, can we provide something that uses TLS and is reasonably secure?=

I think that we can, but not in the presence of old DNS forwarders that can= 't be updated.

What I heard from David Schinazi (though these were I think Eric Orth's= figures) was that the environment was such that none of our existing solut= ions would work and we would need a looser definition if we were to be able= to offer DoH/DoT to most users.=C2=A0 If we don't accept something a l= ittle more opportunistic, we only get ~15% of people (assuming that dataset= is representative, which I believe it should be).

On Mon, Nov 16, 2020, at 20:31, Stephane Bortzmeyer wrote:
> On Mon, Nov 16, 2020 at 08:41:39AM +0000,
>=C2=A0 Jim Reid <jim@rfc1035.com> wrote
>=C2=A0 a message of 11 lines which said:
>
> > The point I didn=E2=80=99t get to make at the mike is using =E2= =80=9Ctwo or more
> > resolvers operated by the same entity=E2=80=9D as the definition = of
> > equivalence probably doesn=E2=80=99t work:
>
> Another case where it doesn't work is when the same entity offers<= br> > different services (one lying and one not, for instance), which is
> common among public resolvers <https://quad9.net/faq/>
> <https://dns.yandex.com/>
> <https://blog.cloudflare.com/in= troducing-1-1-1-1-for-families/>, etc
>
> I suggest to not just say "equivalent" but be more specific:= "with
> equivalent answers". Equivalent answers being defined by the user= 's
> use cases. If resolver A censors SciHub and resolver B does not, they<= br> > do not yield equivalent answers. If resolver A sees gmail.com at
> 2a00:1450:400e:809::2005 and resolver B sees it at
> 2a00:1450:4007:816::2005, they probably give equivalent answers, as > far as the ordinary user is concerned.
>
> "Equivalent" is too loaded to be used alone.
>
>
> --
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000a3e42a05b44694e8-- From nobody Mon Nov 16 22:02:01 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C558B3A0EE0 for ; Mon, 16 Nov 2020 22:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 C3geeE-icmeo for ; Mon, 16 Nov 2020 22:01:58 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640139.outbound.protection.outlook.com [40.107.64.139]) (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 670453A0EE1 for ; Mon, 16 Nov 2020 22:01:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ryj+Wi0tWOn4lTI+ocHDWS3B9vTDSbckmuVbHqyxKlaRy4oOCTkaroy2VPs0NkC/ZjGoh2E1hvzBKOgfMOFFUrmB/IMWqI0FP5/tFMAY13oLb4rLhVckTDeXC1kBT1Q9yfYFWID1EghN50cZJ28AFkURL3uxtX4EA/RbM2ceMsCqxICo4tfLazVmdtSS8pPLGsY6REl02Q8O/uxq6q5qgUTVZAfrwkFWNWHKdGpndSXNpdZG8DHnaUVXD7D6ROHF2Hg/Ex0U6XGKvltY9ojT+0T3QzgEdwntGJUScio6aQNqoDMLwvZahBza3zODoY9qnWbmfeO9V5HIB9/cMEeAFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KR9V8/YakPtFsqtH7/BTjN/sjDOhjBw2AC9FEZ8soic=; b=SgaY7p9Ax8ayy9tfcs8GjBA7yTe0CJN6viqmQ/zo4b1WQ4sX11x8H+AZObrFeoF1rWbgOKs7lqS4Trcc7w1InKEcQ9kG+E4syCH28RlcIHLXBSJLEnj2nE10jfJD0zDAFmOixQnelG5kBKSA3NXWpUQnC9Culm5DQqMTAOIbqOy4pqYskWzs1w78fNnEE2UkmLEaLN05wzoiTtrkOGl0doLu7/dG3qdzdyf0pTD69DNcXt/oeCVHHHnFa+gGRIFMeK3wUv8iJcEr8vwSwDJsL7+kKp2HcqlloOVrME1rIu7EeWX25g5+u0NQKWhJ/LmJCckrgxftDllg2pyDbujVAw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KR9V8/YakPtFsqtH7/BTjN/sjDOhjBw2AC9FEZ8soic=; b=Z2WfgCqsxJbDWmN/+HAgiHUQbxNhHa4XGNAXn7Rl1b0E6lP/aj+t2XYS/VwcWFFlwwk0RYvroco30hvNOqPfUvza/pnce2zCUO7FC/oyh3ClXATowsuGEQOO+uFmiidSxYrfcgG37cM/hWD4Cw1ShPMHQYW8LdaSeYz/5O/Kens= Received: from (2603:10b6:5:220::23) by DM5PR00MB0438.namprd00.prod.outlook.com (2603:10b6:4:a0::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3622.0; Tue, 17 Nov 2020 06:01:56 +0000 Received: from DM6PR00MB0666.namprd00.prod.outlook.com ([fe80::64d6:c3e3:e54d:bf9b]) by DM6PR00MB0666.namprd00.prod.outlook.com ([fe80::64d6:c3e3:e54d:bf9b%6]) with mapi id 15.20.3625.000; Tue, 17 Nov 2020 06:01:56 +0000 From: Tommy Jensen To: "jw@pcthink.com" , "add@ietf.org" Thread-Topic: [EXTERNAL] [Add] CAA recommendation (DEER) Thread-Index: AQHWvHPpazjG68V4SkOHdFEK9wRdIqnL1KWs Date: Tue, 17 Nov 2020 06:01:56 +0000 Message-ID: References: <202011162354.0AGNsHnL063449@jax4mhob19.registeredsite.com> In-Reply-To: <202011162354.0AGNsHnL063449@jax4mhob19.registeredsite.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-11-17T06:01:55.760Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; authentication-results: pcthink.com; dkim=none (message not signed) header.d=none;pcthink.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.35.73.96] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 0ecdfc36-3663-49ff-67e9-08d88abe4a11 x-ms-traffictypediagnostic: DM5PR00MB0438: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ow/iJ5qNXRyi+mItrpKglEtQoxIOiq3zfhbVjFnI1NBB9Qm8mfb714+sX9zR4iumfFJQg6JXWJG1eLbAKjHz1cP+A4fYr2hpJ51y6c1V7vfmEj0/XIat0e5y4twhc2BDV7cBQcLkiWua11EdDE7302Q7RoCOgbWBNi5qxM72vkB1CLb2uDYItoqo6Vtf0Wf/fZnauKi5t50bIwO7LDHVA8kgGgOnWkr7RVgzGu4QVx+L3l4lpa0xkgze0fyoVuf7MF4fSSSneD/QMrDm5ocj+G39rIPUVv6m00lz/xQ6Ia1srzehC+lpetiwrXBSTXAkbvLLd9v09yJPu4n1HNM02g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0666.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(39860400002)(366004)(136003)(376002)(396003)(33656002)(6506007)(4744005)(9686003)(64756008)(186003)(5660300002)(26005)(82950400001)(7696005)(66556008)(52536014)(66946007)(66446008)(66476007)(8676002)(8936002)(8990500004)(53546011)(82960400001)(76116006)(19627405001)(10290500003)(478600001)(86362001)(2906002)(91956017)(55016002)(71200400001)(316002)(110136005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-7?Q?nd3DzoHhwc+dfybX8LkxI8xchluBuIAjYXj271T+IPwlcpPYqoCWGpHukn?= =?iso-8859-7?Q?lQ+p8yrEaECoV3EcOPraagP0dPh/dip0MOslSNTuKm0UrsuQ/UWwbMD8sb?= =?iso-8859-7?Q?uRU9ojXTMUrFY5SWTGXNQcHrBysVTxJzJDL+t0RcpbUdO0y/ZedlZ2+iKV?= =?iso-8859-7?Q?YBE5sRCHbGqo1RAQauQ9OEzQ6JTTAaLcgRHes7Q7L0ZqeoPn1Rg0kdoQK5?= =?iso-8859-7?Q?Ay5UW9UQWVAX1K7AqFJxe4dHxjjSSr/odNiXFxnSh7GlmdH9i2ayczH2xG?= =?iso-8859-7?Q?fLX7KTD23vkrcgvgVoQekn9r7alk9pXMh0lZgV2yT0Gs18aGBjHw3QpC2r?= =?iso-8859-7?Q?xR2IPvLkkSuFYNCpSC3We3KSgU77UflRD0JVG6D6Is/j7Sew3g6RLslLwF?= =?iso-8859-7?Q?c3xsJ35WHTgg5zSAVkJQKzKzBncGid9nNbvIIjLdwfq0kYTRRXOOI7vgdJ?= =?iso-8859-7?Q?xCbe6vfhXxTWULNt02nXAbiFSLOE7SaSrdZdiSxEy6tgvi8Z1zg25il+Zo?= =?iso-8859-7?Q?IL/G3p4dYPSUcK7maY+QZ06StqNC8dmSrgg6JAFkvDGTM5pQJQ+5X4uU4d?= =?iso-8859-7?Q?dSBja9hJS1fqZl0y8qlveygKg7/a0bH87vlb3mwHP0F8MtEEgIz83Z+nTH?= =?iso-8859-7?Q?YKL/wM9yKJge4ZTXdI+hJX3E8y053B2RXJPV1HyP6atuzrrn3Ri27lEmBo?= =?iso-8859-7?Q?LPV5fgz4SCV7/N9CI91DAxyO+K69rz0mfOP2BgQ4Oe734TBLTUNI+gYuAw?= =?iso-8859-7?Q?TOgwdG/S4sP1Mz9uHMrWNdN3m6dfKQ2/oQJG83MCdSif0QZWfhac2nRjkp?= =?iso-8859-7?Q?l0wi4rZBEGiI5q+5mNCk6AKzwbxUNPUadHA6Wqx+iFJhOq9eRRtcTOZgwq?= =?iso-8859-7?Q?z4Q8oOqHKownUPiCtznBjByflwF/ZjmdfF6oCGQNN0LVnmbYi1gHB21bwM?= =?iso-8859-7?Q?sKjGKUOau8xCMIPkkY+zJ4FZM6pdhQHtyMccFZBMldnvbsJWLAcQ94ieek?= =?iso-8859-7?Q?VmTb9200W4/u0AEWg=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB06665F7B965E7B81618D6F82FAE21DM6PR00MB0666namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0666.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0ecdfc36-3663-49ff-67e9-08d88abe4a11 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2020 06:01:56.3222 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qZ9vM1JPTUCA4zse2Dm0+xKp0DSY1Gq0aTRtj7xWpSQ7ajfyopkffSC8AHZ+9t/IkNFXvDN+78hJE13QAALUmQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0438 Archived-At: Subject: Re: [Add] [EXTERNAL] CAA recommendation (DEER) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 06:02:00 -0000 --_000_DM6PR00MB06665F7B965E7B81618D6F82FAE21DM6PR00MB0666namp_ Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Hey John, I'm not sure how CAA records would help in the primary scenario of DEER whe= re the stub is configured only with an IP address. Can you elaborate? Thanks, Tommy ________________________________ From: Add on behalf of JW =EB John Woodworth Sent: Monday, November 16, 2020 3:54 PM To: add@ietf.org Cc: jw@pcthink.com Subject: [EXTERNAL] [Add] CAA recommendation (DEER) Hello, While reading the DEER draft, I had the thought that it may be a good idea = to make use of CAA records a recommendation for encrypted-DNS certificates.= I can see potential issues with open CA issued certificates. Thanks, John --_000_DM6PR00MB06665F7B965E7B81618D6F82FAE21DM6PR00MB0666namp_ Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable
Hey John,

I'm not sure how CAA records would help in the primary scenario of DEER whe= re the stub is configured only with an IP address. Can you elaborate?

Thanks,
Tommy

From: Add <add-bounces= @ietf.org> on behalf of JW =EB John Woodworth <jw@pcthink.com>
Sent: Monday, November 16, 2020 3:54 PM
To: add@ietf.org <add@ietf.org>
Cc: jw@pcthink.com <jw@pcthink.com>
Subject: [EXTERNAL] [Add] CAA recommendation (DEER)
 
Hello,

While reading the DEER draft, I had the thought that it m= ay be a good idea to make use of CAA records a recommendation for encrypted= -DNS certificates.  I can see potential issues with open CA issued cer= tificates.


Thanks, 
John

--_000_DM6PR00MB06665F7B965E7B81618D6F82FAE21DM6PR00MB0666namp_-- From nobody Mon Nov 16 23:34:19 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2B53A1153 for ; Mon, 16 Nov 2020 23:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.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 w0gjw5ShnS_v for ; Mon, 16 Nov 2020 23:34:15 -0800 (PST) Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 96BC83A1152 for ; Mon, 16 Nov 2020 23:34:15 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id DE6D36A305; Tue, 17 Nov 2020 08:34:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1605598453; bh=v6P59PDSdFRLuz2FlSqTHRUyacfh5TBhn4S3tDqD1RA=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=Tp3V6mBvmmL48SBfMs0MrOvX1kUE43vzBoTYzjWs0dJxyCl11M2b5kmPkgOBuoikc ny3uLF6jpZ9WTXNhoNT6iLk3Q0ZobgnX5gv8GO1Ahce5GzY2sD6SCm6/Ko19EPqD4j jAfJsgbT/lvhJYV9TrJxsKWAYAV0RAtzCKS2L4l7OIbdroinFbJBvfoqoaat71zan1 Sivyko2Orys01oBv72OaXO477gH9L6+rQ1NxoC/3r/l4KnPAMbDSAYO4IMaRzjm1O1 ZKD4vwvBQkF3YIJS6818Ndp823jxgeCgN5wEy4wUXLla4KT6Wp35JFGs19qJWakBS2 k7t0GnRqU+57w== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id CDF313C01B0; Tue, 17 Nov 2020 08:34:13 +0100 (CET) Date: Tue, 17 Nov 2020 08:34:13 +0100 (CET) From: Vittorio Bertola To: Tommy Pauly , Martin Thomson Cc: add@ietf.org Message-ID: <1939673914.41605.1605598453715@appsuite-gw2.open-xchange.com> In-Reply-To: References: <0d736ecb-f188-4329-8ab5-f5d94e3bddcc@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.4-Rev10 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: Subject: Re: [Add] EER bootstrapping draft scopes X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 07:34:17 -0000 > Il 16/11/2020 21:20 Tommy Pauly ha = scritto: >=20 > Right=E2=80=94if you want to have something that you can prove matches yo= ur reference identity, I think there may not be any way to get those guaran= tees on a network with a forwarder running on a private IP address that can= =E2=80=99t ever update DHCP and can=E2=80=99t add its own encrypted DNS sup= port. Arguably, for those cases, you are technically using a resolver (whic= h does little more than forwarding and filtering) that simply has no equiva= lent encrypted resolver and will never have one.=20 This really depends on how you define "equivalent encrypted resolver". If your definition is functional and user-centred, i.e. "an encrypted resol= ver that behaves like the unencrypted one that the user is currently using = and that is managed by the same entity, but can be reached over encrypted t= ransport", then there will easily be an EER in that case as well. IMHO it would be useful to break down the discovery discussion and work sep= arately on an agreed definition of EER, rather than having each discovery d= raft adopt its own slightly different one. --=20 Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com=20 Office @ Via Treviso 12, 10144 Torino, Italy From nobody Tue Nov 17 00:29:50 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1733A08BB for ; Tue, 17 Nov 2020 00:29:49 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam-Report: ...T_ADDRESS@@ for details. Content previ[...] 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 n5PM6KrEK0pL for ; Tue, 17 Nov 2020 00:29:47 -0800 (PST) Received: from saturn.zonnestelsel.tk (saturn.zonnestelsel.tk [IPv6:2001:470:78c8:2::11]) (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 43F093A08DA for ; Tue, 17 Nov 2020 00:29:45 -0800 (PST) Received: from earth.zonnestelsel.tk ([2001:470:78c8:2::9]) by saturn.zonnestelsel.tk with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kewMu-00026W-Hy for add@ietf.org; Tue, 17 Nov 2020 08:29:42 +0000 To: add@ietf.org References: <255afe94-837a-8669-55c0-ea85cee7d0af@huitema.net> From: Shane Kerr Message-ID: <1fa5f2e6-64e2-e742-6108-1ba294de1cf1@time-travellers.org> Date: Tue, 17 Nov 2020 09:29:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <255afe94-837a-8669-55c0-ea85cee7d0af@huitema.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score-Int: -28 X-Spam-Bar: -- Archived-At: Subject: Re: [Add] STUN for DNS? X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 08:29:50 -0000 Christian, On 16/11/2020 21.21, Christian Huitema wrote: > Should we have the equivalent of STUN for DNS? STUN was defined many > years ago in the context of NAT traversal, so hosts behind a NAT could > enlist help from server and learn how their "public" IP address appears > on the other side of the NAT. Likewise, with STUN for DNS, hosts could > get help from a third-party server and learn the "public" IP address of > the recursive resolver configured on their system. One of the > applications would be to obtain the seed needed for the "equivalent > encrypted resolver" discovery; there are probably quite a few other > applications. > > The simplest design would be to configure the host with just the domain > name of the STUN for DNS resolver, say "s4d.example.net", and with a key > for that resolver. The host that wants to identify the local service > constructs a unique query by picking a random number "rrr", and asks for > a TXT record associated with "rrr.s4d.example.net". The request is > routed by the local resolver (maybe a Wi-Fi router) to a recursive > resolver and then to the selected server, which is authoritative for the > selected domain name (s4d.example.net). The STUN 4 DNS resolver > programmatically creates a TXT record containing the encrypted value of > the source address from which the query was received -- that is, the > address of the recursive resolver. That response will then be relayed to > the host. > > Would there be any interest in defining such service? I have long thought that some STUN-like approach would be useful for DNS. In the same way that before STUN every host would need their own proprietary, ad hoc approach for dealing with NAT, today every mobile system that wants to gracefully navigate the Internet likely has at least minimal inference of how the local DNS works. Maybe a better approach than defining a specific algorithm is to look at the various local resolution approaches and seeing what setups they are designed to work around (maybe GetDNS, systemd-resolved, and Android as a reasonable start), and then either steal^Wstandardize their work or develop even better versions? I have no idea if such work should happen in ADD, DNSOP, some other working group, or even a new working group (assuming there is interest). Cheers, -- Shane From nobody Tue Nov 17 01:34:48 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDD13A0CF2 for ; Tue, 17 Nov 2020 01:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 EHtKniesJ7hC for ; Tue, 17 Nov 2020 01:33:49 -0800 (PST) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 3523D3A0D6D for ; Tue, 17 Nov 2020 01:33:36 -0800 (PST) Received: by mail-io1-xd35.google.com with SMTP id n12so20469779ioc.2 for ; Tue, 17 Nov 2020 01:33:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CdwKoLAX2s1nAbrQGSx0r8KOmcgI2fdUQ7471q+wKGA=; b=rYFg8nWC2nQsAvcBL9rIyDiZKY5dT4iffpi0j6gyX6LtpriKf2Qnk/PiDsn6uKw93f lqB2oczJR/PpILHCii+7Lvg1oFPE+zhou3/ssYTgt9OHO5ABUSS2Tu12tfWgiTKBazWb 4IBteUwFuwg4NSHcHl7i8T2odiEWT16kOnAaYKR8oOUPgJueR+K76LwrMo1hHchJjkmC Dv4W1Ay9Hrdj5p597O8wDWHeDwAKG0zOudDaxEMk7cDmrSU/21jkJDwElNFJqZUMNwqa APtUMI5oloCp+wfgff8OqtrtILyrZxh6EJlY76bBZgsgStE0jIxi4I88pAxEOi95MA1b sD1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CdwKoLAX2s1nAbrQGSx0r8KOmcgI2fdUQ7471q+wKGA=; b=qpN2WSLiYq46vluQWWv+lhNW+VR/9F4HgElFMxikgpV0hFkb+QxaWgNl/+yNlh50KV GzLMX3CLxmSCTmjnIDkb8UUwFl9Y0hL8W8Z5V6f/Lj2hPMM10W0fg9yo84Barn7S+xC4 Hc2dsJWVL1mkOAABj/sogiFTnrklq4o1n+KUCrt0tYhlzjJnJkR1PXJynj2XA0YHzVIt ibdJBoehXt/muBdaCqbdmqv46qIIxkGP3SPYT4mEWW4TTM94YRqbH7HaVBZIqwsLz1Az zqvl9njF6wAfyOixGIMG76leeUvB0EEFQLF4vleRhED6BjuVjbmkEkj6gQBbkDj2OaDm 12CQ== X-Gm-Message-State: AOAM532T3LDC0JZpZ7HOeAfdrbTu/IbjcBdgkDGXASwkguwvvUOJ3F6e eZjRszmtxqWO3P+EtiEEo8KV8PJA/wjR34kYC/c= X-Google-Smtp-Source: ABdhPJzkFrvnEBfRLxtD278o0BzU7LX8cGifnIaCURogGkZWPHACv+hRMS63iYubWvZPFOuwnuIrbZ8pBXXGcD5OI70= X-Received: by 2002:a05:6638:120d:: with SMTP id n13mr2841757jas.35.1605605615448; Tue, 17 Nov 2020 01:33:35 -0800 (PST) MIME-Version: 1.0 References: <0d736ecb-f188-4329-8ab5-f5d94e3bddcc@www.fastmail.com> <1939673914.41605.1605598453715@appsuite-gw2.open-xchange.com> In-Reply-To: <1939673914.41605.1605598453715@appsuite-gw2.open-xchange.com> From: tirumal reddy Date: Tue, 17 Nov 2020 16:33:24 +0700 Message-ID: To: Vittorio Bertola Cc: Tommy Pauly , Martin Thomson , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000005bb5d405b44a30d9" Archived-At: Subject: Re: [Add] EER bootstrapping draft scopes X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 09:33:51 -0000 --0000000000005bb5d405b44a30d9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 17 Nov 2020 at 14:34, Vittorio Bertola wrote: > > > > Il 16/11/2020 21:20 Tommy Pauly h= a > scritto: > > > > Right=E2=80=94if you want to have something that you can prove matches = your > reference identity, I think there may not be any way to get those > guarantees on a network with a forwarder running on a private IP address > that can=E2=80=99t ever update DHCP and can=E2=80=99t add its own encrypt= ed DNS support. > Arguably, for those cases, you are technically using a resolver (which do= es > little more than forwarding and filtering) that simply has no equivalent > encrypted resolver and will never have one. > > This really depends on how you define "equivalent encrypted resolver". > > If your definition is functional and user-centred, i.e. "an encrypted > resolver that behaves like the unencrypted one that the user is currently > using and that is managed by the same entity, but can be reached over > encrypted transport", then there will easily be an EER in that case as we= ll. > > IMHO it would be useful to break down the discovery discussion and work > separately on an agreed definition of EER, rather than having each > discovery draft adopt its own slightly different one. > Yes, identifying EER is only required for resolver-identified encrypted resolver discovery (like DEER) and not for network-identified encrypted resolver (using DHCP/RA extension to provision the name of the resolver). -Tiru > -- > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bertola@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --0000000000005bb5d405b44a30d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, 17 Nov 2020 at 14:34, Vittorio Be= rtola <vittorio.bertola=3D40open-xchange.com@dmarc.ietf.org> wrote:


> Il 16/11/2020 21:20 Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> h= a scritto:
>
> Right=E2=80=94if you want to have something that you can prove matches= your reference identity, I think there may not be any way to get those gua= rantees on a network with a forwarder running on a private IP address that = can=E2=80=99t ever update DHCP and can=E2=80=99t add its own encrypted DNS = support. Arguably, for those cases, you are technically using a resolver (w= hich does little more than forwarding and filtering) that simply has no equ= ivalent encrypted resolver and will never have one.

This really depends on how you define "equivalent encrypted resolver&q= uot;.

If your definition is functional and user-centred, i.e. "an encrypted = resolver that behaves like the unencrypted one that the user is currently u= sing and that is managed by the same entity, but can be reached over encryp= ted transport", then there will easily be an EER in that case as well.=

IMHO it would be useful to break down the discovery discussion and work sep= arately on an agreed definition of EER, rather than having each discovery d= raft adopt its own slightly different one.

<= div>Yes, identifying EER is only required for resolver-identified encrypted= resolver discovery (like DEER) and not for network-identified encrypted re= solver (using DHCP/RA extension to provision the name of the resolver).

-Tiru


--
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vitt= orio.bertola@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--0000000000005bb5d405b44a30d9-- From nobody Tue Nov 17 10:15:34 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888243A1504 for ; Tue, 17 Nov 2020 10:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 n5r9pMwI0cRS for ; Tue, 17 Nov 2020 10:15:30 -0800 (PST) Received: from jax4mhob11.registeredsite.com (jax4mhob11.myregisteredsite.com [64.69.218.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 5752B3A14FE for ; Tue, 17 Nov 2020 10:15:30 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by jax4mhob11.registeredsite.com (8.14.4/8.14.4) with ESMTP id 0AHIFPdq005232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 17 Nov 2020 13:15:25 -0500 Message-Id: <202011171815.0AHIFPdq005232@jax4mhob11.registeredsite.com> Received: (qmail 31382 invoked by uid 0); 17 Nov 2020 18:15:25 -0000 X-TCPREMOTEIP: 73.251.233.169 X-Authenticated-UID: jw@pcthink.com Received: from unknown (HELO ?10.2.1.116?) (jw@pcthink.com@73.251.233.169) by 0 with ESMTPA; 17 Nov 2020 18:15:25 -0000 SavedFromEmail: jw@pcthink.com Date: Tue, 17 Nov 2020 13:15:15 -0500 In-Reply-To: Importance: normal From: =?UTF-8?Q?JW_=CE=BB_John_Woodworth?= To: Tommy Jensen , "add@ietf.org" Cc: jw@pcthink.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_662515112538250" Archived-At: Subject: Re: [Add] [EXTERNAL] CAA recommendation (DEER) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 18:15:33 -0000 ----_com.samsung.android.email_662515112538250 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgVG9tbXkswqBBcG9sb2dpZXMgZm9yIG15IHZhZ3VlbmVzcy5PbmUgb2YgbXkgb2JqZWN0aXZl cyBpcyB0byBtb3ZlIHNvbWUgb2YgdGhlIEROUyBkZWNpc2lvbiBtYWtpbmcgYmFjayB0byB0aGUg Q1BFLsKgIFdlIGhhdmUgc29tZSBpbmZsdWVuY2Ugb3ZlciBvdXIgdmVuZG9ycyByZWdhcmRpbmcg ZmVhdHVyZXMuVG9kYXksIHRoZSBDUEUgaGFzIGtub3dsZWRnZSBvZiBib3RoIHBhcnRzIG9mIGEg c3BsaXQtaG9yaXpvbiBETlMgYW5kIEkgd291bGQgbGlrZSB0byBsZXZlcmFnZSB0aGlzIGtub3ds ZWRnZSB2aWEgYW4gZW5jcnlwdGVkLUROUyBlbmFibGVkIHByb3h5IG9uIHN1cHBvcnRlZCBDUEUn cy5UaGlzIG1lYW5zIF9wb3RlbnRpYWxseV8gbWFuYWdpbmcgbWlsbGlvbnMgb2YgY2VydGlmaWNh dGVzIGFuZCBob3N0bmFtZXMswqAgdW5pcXVlIHJmYzE5MTggYWRkcmVzc2VzLCBldGMuwqAgSSdt IHRoaW5raW5nIGluIHRoaXMgc2NlbmFyaW8gd2UnZCB3YW50IHRvIHRyZWFkIGNhcmVmdWxseSBy ZWdhcmRpbmcgd2hpY2ggQ0Egd2lucyBpbiBhIHRpZSwgc2hvdWxkIGJhZCB0aGluZ3MgaGFwcGVu LkkgcmVhbGl6ZSB0aGlzIG1heSBiZSBhIGNvcm5lciBjYXNlIGJ1dCBmZWx0IGl0IHdvcnRoIHNo YXJpbmcuVGhhbmtzLMKgSm9obgotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tRnJv bTogVG9tbXkgSmVuc2VuIDxKZW5zZW4uVGhvbWFzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRm Lm9yZz4KCkhleSBKb2huLAoKCgoKSSdtIG5vdCBzdXJlIGhvdyBDQUEgcmVjb3JkcyB3b3VsZCBo ZWxwIGluIHRoZSBwcmltYXJ5IHNjZW5hcmlvIG9mIERFRVIgd2hlcmUgdGhlIHN0dWIgaXMgY29u ZmlndXJlZCBvbmx5IHdpdGggYW4gSVAgYWRkcmVzcy4gQ2FuIHlvdSBlbGFib3JhdGU/CgoKCgpU aGFua3MsCgpUb21teQoKCgoKCkZyb206IEFkZCA8YWRkLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJl aGFsZiBvZiBKVyDOuyBKb2huIFdvb2R3b3J0aCA8andAcGN0aGluay5jb20+ClNlbnQ6IE1vbmRh eSwgTm92ZW1iZXIgMTYsIDIwMjAgMzo1NCBQTQpUbzogYWRkQGlldGYub3JnIDxhZGRAaWV0Zi5v cmc+CkNjOiBqd0BwY3RoaW5rLmNvbSA8andAcGN0aGluay5jb20+ClN1YmplY3Q6IFtFWFRFUk5B TF0gW0FkZF0gQ0FBIHJlY29tbWVuZGF0aW9uIChERUVSKQrCoAoKCkhlbGxvLAoKCldoaWxlIHJl YWRpbmcgdGhlIERFRVIgZHJhZnQsIEkgaGFkIHRoZSB0aG91Z2h0IHRoYXQgaXQgbWF5IGJlIGEg Z29vZCBpZGVhIHRvIG1ha2UgdXNlIG9mIENBQSByZWNvcmRzIGEgcmVjb21tZW5kYXRpb24gZm9y IGVuY3J5cHRlZC1ETlMgY2VydGlmaWNhdGVzLsKgIEkgY2FuIHNlZSBwb3RlbnRpYWwgaXNzdWVz IHdpdGggb3BlbiBDQSBpc3N1ZWQgY2VydGlmaWNhdGVzLgoKCgoKVGhhbmtzLMKgCkpvaG4KCgoK Cgo= ----_com.samsung.android.email_662515112538250 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPkhpIFRvbW15LCZu YnNwOzxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPkFwb2xvZ2llcyBm b3IgbXkgdmFndWVuZXNzLjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9 ImF1dG8iPk9uZSBvZiBteSBvYmplY3RpdmVzIGlzIHRvIG1vdmUgc29tZSBvZiB0aGUgRE5TIGRl Y2lzaW9uIG1ha2luZyBiYWNrIHRvIHRoZSBDUEUuJm5ic3A7IFdlIGhhdmUgc29tZSBpbmZsdWVu Y2Ugb3ZlciBvdXIgdmVuZG9ycyByZWdhcmRpbmcgZmVhdHVyZXMuPC9kaXY+PGRpdiBkaXI9ImF1 dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+VG9kYXksIHRoZSBDUEUgaGFzIGtub3dsZWRn ZSBvZiBib3RoIHBhcnRzIG9mIGEgc3BsaXQtaG9yaXpvbiBETlMgYW5kIEkgd291bGQgbGlrZSB0 byBsZXZlcmFnZSB0aGlzIGtub3dsZWRnZSB2aWEgYW4gZW5jcnlwdGVkLUROUyBlbmFibGVkIHBy b3h5IG9uIHN1cHBvcnRlZCBDUEUncy48L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2Pjxk aXYgZGlyPSJhdXRvIj5UaGlzIG1lYW5zIF9wb3RlbnRpYWxseV8gbWFuYWdpbmcgbWlsbGlvbnMg b2YgY2VydGlmaWNhdGVzIGFuZCBob3N0bmFtZXMsJm5ic3A7IHVuaXF1ZSByZmMxOTE4IGFkZHJl c3NlcywgZXRjLiZuYnNwOyBJJ20gdGhpbmtpbmcgaW4gdGhpcyBzY2VuYXJpbyB3ZSdkIHdhbnQg dG8gdHJlYWQgY2FyZWZ1bGx5IHJlZ2FyZGluZyB3aGljaCBDQSB3aW5zIGluIGEgdGllLCBzaG91 bGQgYmFkIHRoaW5ncyBoYXBwZW4uPC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2 IGRpcj0iYXV0byI+SSByZWFsaXplIHRoaXMgbWF5IGJlIGEgY29ybmVyIGNhc2UgYnV0IGZlbHQg aXQgd29ydGggc2hhcmluZy48L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGly PSJhdXRvIj5UaGFua3MsJm5ic3A7PC9kaXY+PGRpdiBkaXI9ImF1dG8iPkpvaG48L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2IGFsaWduPSJsZWZ0IiBkaXI9ImF1dG8iIHN0eWxlPSJmb250LXNpemU6 MTAwJTtjb2xvcjojMDAwMDAwIj48ZGl2Pi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0t LS08L2Rpdj48ZGl2PkZyb206IFRvbW15IEplbnNlbiAmbHQ7SmVuc2VuLlRob21hcz00MG1pY3Jv c29mdC5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PC9kaXY+PGRpdj48YnI+PC9kaXY+PC9kaXY+Cjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29s b3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiIGRpcj0iYXV0byI+CkhleSBKb2huLDwvZGl2Pgo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9y OiByZ2IoMjU1LCAyNTUsIDI1NSk7IiBkaXI9ImF1dG8iPgo8YnI+CjwvZGl2Pgo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2Io MjU1LCAyNTUsIDI1NSk7IiBkaXI9ImF1dG8iPgpJJ20gbm90IHN1cmUgaG93IENBQSByZWNvcmRz IHdvdWxkIGhlbHAgaW4gdGhlIHByaW1hcnkgc2NlbmFyaW8gb2YgREVFUiB3aGVyZSB0aGUgc3R1 YiBpcyBjb25maWd1cmVkIG9ubHkgd2l0aCBhbiBJUCBhZGRyZXNzLiBDYW4geW91IGVsYWJvcmF0 ZT88L2Rpdj4KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIEFyaWFsLCBIZWx2ZXRp Y2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFj a2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgZGlyPSJhdXRvIj4KPGJyPgo8L2Rp dj4KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3Vu ZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgZGlyPSJhdXRvIj4KVGhhbmtzLDwvZGl2Pgo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNv bG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IiBkaXI9ImF1dG8iPgpUb21teTwvZGl2Pgo8ZGl2IGlk PSJhcHBlbmRvbnNlbmQiIGRpcj0iYXV0byI+PC9kaXY+CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7 IGNvbG9yOiByZ2IoMCwgMCwgMCk7IiBkaXI9ImF1dG8iPgo8YnI+CjwvZGl2Pgo8aHIgc3R5bGU9 ImRpc3BsYXk6aW5saW5lLWJsb2NrOyB3aWR0aDo5OCUiIHRhYmluZGV4PSItMSIgZGlyPSJhdXRv Ij4KPGRpdiBkaXI9Imx0ciIgaWQ9ImRpdlJwbHlGd2RNc2ciPjxmb250IHN0eWxlPSJmb250LXNp emU6IDExcHQ7IiBjb2xvcj0iIzAwMDAwMCIgZmFjZT0iQ2FsaWJyaSwgc2Fucy1zZXJpZiI+PGI+ RnJvbTo8L2I+IEFkZCAmbHQ7YWRkLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBK VyDOuyBKb2huIFdvb2R3b3J0aCAmbHQ7andAcGN0aGluay5jb20mZ3Q7PGJyPgo8Yj5TZW50Ojwv Yj4gTW9uZGF5LCBOb3ZlbWJlciAxNiwgMjAyMCAzOjU0IFBNPGJyPgo8Yj5Ubzo8L2I+IGFkZEBp ZXRmLm9yZyAmbHQ7YWRkQGlldGYub3JnJmd0Ozxicj4KPGI+Q2M6PC9iPiBqd0BwY3RoaW5rLmNv bSAmbHQ7andAcGN0aGluay5jb20mZ3Q7PGJyPgo8Yj5TdWJqZWN0OjwvYj4gW0VYVEVSTkFMXSBb QWRkXSBDQUEgcmVjb21tZW5kYXRpb24gKERFRVIpPC9mb250Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8 L2Rpdj4KPGRpdiBkaXI9ImF1dG8iPgo8ZGl2IGRpcj0iYXV0byI+SGVsbG8sPC9kaXY+CjxkaXYg ZGlyPSJhdXRvIj48YnI+CjwvZGl2Pgo8ZGl2IGRpcj0iYXV0byI+V2hpbGUgcmVhZGluZyB0aGUg REVFUiBkcmFmdCwgSSBoYWQgdGhlIHRob3VnaHQgdGhhdCBpdCBtYXkgYmUgYSBnb29kIGlkZWEg dG8gbWFrZSB1c2Ugb2YgQ0FBIHJlY29yZHMgYSByZWNvbW1lbmRhdGlvbiBmb3IgZW5jcnlwdGVk LUROUyBjZXJ0aWZpY2F0ZXMuJm5ic3A7IEkgY2FuIHNlZSBwb3RlbnRpYWwgaXNzdWVzIHdpdGgg b3BlbiBDQSBpc3N1ZWQgY2VydGlmaWNhdGVzLjwvZGl2Pgo8ZGl2IGRpcj0iYXV0byI+PGJyPgo8 L2Rpdj4KPGRpdiBkaXI9ImF1dG8iPjxicj4KPC9kaXY+CjxkaXYgZGlyPSJhdXRvIj5UaGFua3Ms Jm5ic3A7PC9kaXY+CjxkaXYgZGlyPSJhdXRvIj5Kb2huPC9kaXY+CjxkaXYgZGlyPSJhdXRvIj48 YnI+CjwvZGl2Pgo8L2Rpdj4KCgo8L2JvZHk+PC9odG1sPg== ----_com.samsung.android.email_662515112538250-- From nobody Tue Nov 17 13:24:15 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E449F3A03F1 for ; Tue, 17 Nov 2020 13:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 0_JtmBlK4Rfs for ; Tue, 17 Nov 2020 13:24:12 -0800 (PST) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 D68913A03C9 for ; Tue, 17 Nov 2020 13:24:12 -0800 (PST) Received: by mail-il1-x130.google.com with SMTP id w8so9928888ilg.12 for ; Tue, 17 Nov 2020 13:24:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=67sNuSogbSCH+C64TEprgpNrEMTDB8CNb6NU43aFhjc=; b=fxGGbrFPSAr9IaF1LAqMApI7dB2+Sz/Bzp0wPC3jWZ2+eiffmNClz0sFoFowMSlBa+ SwuX2o0fej21kN7oF8RLLC5LUF0gZ+3ghn5yuag5vYJTpMkJcZC+Q9RpXU1Idg6nEyqF rQNxFx7ZT1MSLYOzzigksmKv37d0T4eouRPHyC9qvBIWnRv4PQWHfXTVFctcEN5pIl5S XN6QNNHuUrXRdioUnkWsagn9J6cviYxldDYZRKDHpVA2f/brxTiTxIURzru1RyqjYPoT B9M8WLQOcPfNukk+srox20OPSTCCrK+HWN6oQuejBOwuJo596oNSUVkIyucMK3H2Cil1 O9XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=67sNuSogbSCH+C64TEprgpNrEMTDB8CNb6NU43aFhjc=; b=Fhz7uqlmXxhiG/ONejvBLbYbhSGtFquEmJ58/Z+tWIsd3gtrr2wq9Uixd6SIPVzBhy jZveNNwHICusHHokHmztHBsrDJq3ikorm+Rh1odSPOCU4v9y/wXQJaBmVOjoaIBdqNHK KlNrqqBIETxRguX0g2w0OQ6qDoiXUgQc4HfoMvsOigP31FmicPwFwz1HiDRDCQEVRAkf 99K9fhqO3YOUtvyazntEAKX1AYG2sC8+7GNwm0MvsxsxS1sXnsarhwphiw3oJCWG5luT TRg+PcnYmYfPm9P2DcwFd0IlluQGuk6EzfqVnTxBkBrKqgmQ373QJKzIuNr00gtLQ0wq IawA== X-Gm-Message-State: AOAM532aN87sgFe0RYkDCnNENiZ7X0XWtf7pmkHvVwzajJ2gQnjlH6mm G5HB+LBetr/RnOTlFITJqjW5qRqPDZaWo5rC9tpC14OsSDzqbQ== X-Google-Smtp-Source: ABdhPJwquTTGpBLBGRcRvmq9BWG1zNwUMsSmJNTUM8S5I/xRjhoLGNsd3TYPJOt7eAcAza4B6QgT2QOCOOH/iL/ShkQ= X-Received: by 2002:a92:a311:: with SMTP id a17mr10850550ili.275.1605648251692; Tue, 17 Nov 2020 13:24:11 -0800 (PST) MIME-Version: 1.0 References: <394A540C-81A8-4F86-8E62-FADC4A820D81@rfc1035.com> <20201116093136.GA21460@nic.fr> <680ed8e1-bdb9-4ed9-aa12-7c0efe2bb1da@www.fastmail.com> In-Reply-To: From: Ben Schwartz Date: Tue, 17 Nov 2020 16:23:59 -0500 Message-ID: To: Martin Thomson Cc: ADD Mailing list Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000b44d9e05b4541da5" Archived-At: Subject: Re: [Add] equivalence definition X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 21:24:14 -0000 --000000000000b44d9e05b4541da5 Content-Type: multipart/alternative; boundary="000000000000adaad305b4541d30" --000000000000adaad305b4541d30 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 16, 2020 at 4:02 PM Ben Schwartz wrote: ... > I posit that any persistent attacker who can answer queries sent to server > A is indistinguishable from server A. This suggests a possible solution to > the local network use case: ask the client to regularly revalidate server > A's intention to upgrade to server B, and stop using server B if server A > stops recommending it. > I've taken the liberty of turning this into a PR for DEER: https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/pull/147. I believe this solves the "85%" problem securely, assuming this security model. --000000000000adaad305b4541d30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 16, 2020 at 4:02 PM Ben Schwa= rtz <bemasc@google.com> wrot= e:
...
I posit that = any persistent attacker who can answer queries sent to server A is indistin= guishable from server A.=C2=A0 This suggests a possible solution to the loc= al network use case: ask the client to regularly revalidate server A's = intention to upgrade to server B, and stop using server B if server A stops= recommending it.

I've take= n the liberty of turning this into a PR for DEER:=C2=A0https://github= .com/tfpauly/draft-pauly-adaptive-dns-privacy/pull/147.=C2=A0 I believe= this solves the "85%" problem securely, assuming this security m= odel.
--000000000000adaad305b4541d30-- --000000000000b44d9e05b4541da5 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPmAYJKoZIhvcNAQcCoIIPiTCCD4UCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggzyMIIEtjCCA56gAwIBAgIQeAMYYHb81ngUVR0WyMTzqzANBgkqhkiG9w0BAQsFADBMMSAwHgYD VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE AxMKR2xvYmFsU2lnbjAeFw0yMDA3MjgwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFQxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFz IFIzIFNNSU1FIENBIDIwMjAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvLe9xPU9W dpiHLAvX7kFnaFZPuJLey7LYaMO8P/xSngB9IN73mVc7YiLov12Fekdtn5kL8PjmDBEvTYmWsuQS 6VBo3vdlqqXZ0M9eMkjcKqijrmDRleudEoPDzTumwQ18VB/3I+vbN039HIaRQ5x+NHGiPHVfk6Rx c6KAbYceyeqqfuJEcq23vhTdium/Bf5hHqYUhuJwnBQ+dAUcFndUKMJrth6lHeoifkbw2bv81zxJ I9cvIy516+oUekqiSFGfzAqByv41OrgLV4fLGCDH3yRh1tj7EtV3l2TngqtrDLUs5R+sWIItPa/4 AJXB1Q3nGNl2tNjVpcSn0uJ7aFPbAgMBAAGjggGKMIIBhjAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHzM CmjXouseLHIb0c1dlW+N+/JjMB8GA1UdIwQYMBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MHsGCCsG AQUFBwEBBG8wbTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3Ry MzA7BggrBgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvcm9vdC1y My5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIz LmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5n bG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEANyYcO+9JZYyqQt41 TMwvFWAw3vLoLOQIfIn48/yea/ekOcParTb0mbhsvVSZ6sGn+txYAZb33wIb1f4wK4xQ7+RUYBfI TuTPL7olF9hDpojC2F6Eu8nuEf1XD9qNI8zFd4kfjg4rb+AME0L81WaCL/WhP2kDCnRU4jm6TryB CHhZqtxkIvXGPGHjwJJazJBnX5NayIce4fGuUEJ7HkuCthVZ3Rws0UyHSAXesT/0tXATND4mNr1X El6adiSQy619ybVERnRi5aDe1PTwE+qNiotEEaeujz1a/+yYaaTY+k+qJcVxi7tbyQ0hi0UB3myM A/z2HmGEwO8hx7hDjKmKbDCCA18wggJHoAMCAQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUA MEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWdu MRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEg MB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzAR BgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4 Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuu l9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJ pij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh 6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti +w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEA S0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9u bG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaM ld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88 q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/f hO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBNEwggO5oAMCAQICEAE/JGAv3XK3SRaKvGds QSwwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gQXRsYXMgUjMgU01JTUUgQ0EgMjAyMDAeFw0yMDA5MDgy MzQzNTNaFw0yMTAzMDcyMzQzNTNaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFzY0Bnb29nbGUuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7rjWsiqQSnXGFTvs/2JDygQFtWsgF+Ce W2I/wmwCuWH2eNUBYslyudWmJsUMi7IbeSsKHrvBI2P7k6sk5p6o3uFlomiFaDMqXcn76t5GNGym CmHm5KBWxc3LfyvR4C2/wg9oUwbL2xxXc6QQpWWE4ONn9NMHwNC396Ih5u7tcrH5eF49HbVarP5i TindWAOzz++JA3VC/1lIkqWvOt2BcBtxQDUnYp8sr8UnMF/6UqtCd0aHJnKkvYi4o8Qo5Qf3YgiJ DzADzBTf54o3NAI3hiIVKPvz1l0g78IcR29Bt9jUrE33qGzGB6HoY7Z8quhA/ngW2XjuLkIY1ZKX AwTXBQIDAQABo4IBzzCCAcswHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5jb20wDgYDVR0PAQH/ BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUu687mSaB85ui VgNNFSUhtTljkxEwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYmaHR0cHM6 Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wCQYDVR0TBAIwADCBmgYIKwYBBQUHAQEE gY0wgYowPgYIKwYBBQUHMAGGMmh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL2NhL2dzYXRsYXNy M3NtaW1lY2EyMDIwMEgGCCsGAQUFBzAChjxodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2Nh Y2VydC9nc2F0bGFzcjNzbWltZWNhMjAyMC5jcnQwHwYDVR0jBBgwFoAUfMwKaNei6x4schvRzV2V b4378mMwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9jYS9nc2F0 bGFzcjNzbWltZWNhMjAyMC5jcmwwDQYJKoZIhvcNAQELBQADggEBAG9R1/y5PatVOc8xLrAmGgNO /Q4+lbJuHNwX3aIpOkM72Ot4r6r5/IFOSx1pMpmzvrECyy5YQzUGkHV4atuNq5YPPNMGa+XlaKSg oU2dA6RCD40dtwmrPxrKiGAfHPNvfmRvgnx9qxBKFPbKF/Tn8BwKSZCSvx33TnQRfqLUTcgrAarQ dF9Oc45moJrn4nVF0VTTPI6LVminvjg3tLgF2bny1N6CitQnb1t67vpYjeNpcXNIGQzEDaYI3WnK rVeZMcLSY+Z2dQH8HvVsA95vFCTywgiWKq5KxFqz/GdB6JhDWcIJIKCJVUyqD/Bjx47+e4Ye/FuD NDSYc+613Ozl3TkxggJqMIICZgIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFzIFIzIFNNSU1FIENBIDIwMjACEAE/ JGAv3XK3SRaKvGdsQSwwDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEII16ZI8M2ed2 e/SG7ZF0E0+HMaWlqkL+h6M6fBS3En09MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTIwMTExNzIxMjQxMlowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJ YIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcN AQEHMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQDBBwTMOpPUk0yGhToVPNus0XiQylnV CpW9uLGzQcqXt7c2sT2XHUb+ktIzREF+sneV17AQdE6T40gLK0Bug0lhUEeXwBuAMHKRf0YEYIBn 3ObtEjbJ/JX+rspjZV+la10L9BNnVm045zxaMfcRv01IMjDbm0z00naNMiy3x6tsoRQNKTXmiRDT xqYEb/7znvtHj/khKNxT+Lq7b3fMd1hNoV32h5cS3uiejVkNVgQQh9hgD/ASPbDdKKyD7ud49bu/ GuQwqlimJ7kgU4NE43l5lnWgobVAP6A+gXwG1Wx2LMHBay7OKAhlYYWpJJfS3WnXg1HnETLcNhnV znX7aS6t --000000000000b44d9e05b4541da5-- From nobody Tue Nov 17 19:34:05 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BB23A136E for ; Tue, 17 Nov 2020 19:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=QGbCdbNY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TgneGxe2 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 V9JVZKqAKKp2 for ; Tue, 17 Nov 2020 19:34:01 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C6BE3A136C for ; Tue, 17 Nov 2020 19:34:01 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A08B95C03DF for ; Tue, 17 Nov 2020 22:34:00 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Tue, 17 Nov 2020 22:34:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm3; bh=k0Flz Y7U1g9Zx4So7TUxTB3YIc6SDcJ3B75+UBNdw/E=; b=QGbCdbNYmkUeZZcRH39r1 SlLXreqg0nvhK8yMR/zx/OwoTZ5cos/41r9Aiz4zNtrMsrnnsHwOCtzmX9sY4PGD ucl2Kd+m5ZeersXj9ZO9YD94zbR0O7rcIk5213hSIYw+kpfzgL8739CZGC2Js+20 euQCj276V6MPge/pQ+lN1l1ZKwA9L8B6jHCYeK1f5pQAA1I6j2g36f4FatSGibY6 3eV13G8tOuNzXsg0pwshH+vWOZRTz3cRWCpZlzI7ABoYZuTygoJbFfXtgKU62uz6 Fi862SjFJKsJPaBJ+5cZjRdjqwt9ZnqY9cUdsf0Ea15OJVPuc5BXlvzDfkHkn1jA Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=k0FlzY7U1g9Zx4So7TUxTB3YIc6SDcJ3B75+UBNdw /E=; b=TgneGxe25dQV1iOBQueG9/asKT7unkNpalZgR/q55e48BpPDDDYFja9uU 5xc7DcH0UyAeCg6/StdEQrKZAsEz5kVz0xeGz3Z4qUxc6K58udcs7yS2siZuvJu8 fv4ZFMJz5mlpkoZw2GMgz+2Zec/l6wipNRfvJe1kuJP+eBVGCbHKXinRrb5IPKEI 4VHd14BHV+gcJf3fucOIZJ5W81KkLG44n2espZS4n+1q17c5NIuay0LXhxiz7CNu M74RvnvpwgCVOVzBSEw61bEPnQJvoDO39V6tAt0jr5q+HoUwB3CIHOjM/Ifc/Trr dpyNDGHCvTYoyo4P1QcEM31QUbRXw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefgedgiedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepffetgfevvdfhtdffhe ejudefhffhveehudefhffgleelteeifeegfefggfelhefgnecuffhomhgrihhnpehivght fhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 61643200AD; Tue, 17 Nov 2020 22:34:00 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: In-Reply-To: <202011171815.0AHIFPdq005232@jax4mhob11.registeredsite.com> References: <202011171815.0AHIFPdq005232@jax4mhob11.registeredsite.com> Date: Wed, 18 Nov 2020 14:33:40 +1100 From: "Martin Thomson" To: add@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Add] [EXTERNAL] CAA recommendation (DEER) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 03:34:03 -0000 I think that the DHCP/RA options for discovery provide that path. If yo= u can advertise DoT/DoH that way, then the clients might well decide the= re is no need to use DEER on that network. On Wed, Nov 18, 2020, at 05:15, JW =CE=BB John Woodworth wrote: > Hi Tommy,=20 >=20 > Apologies for my vagueness. >=20 > One of my objectives is to move some of the DNS decision making back t= o=20 > the CPE. We have some influence over our vendors regarding features. >=20 > Today, the CPE has knowledge of both parts of a split-horizon DNS and = I=20 > would like to leverage this knowledge via an encrypted-DNS enabled=20 > proxy on supported CPE's. >=20 > This means _potentially_ managing millions of certificates and=20 > hostnames, unique rfc1918 addresses, etc. I'm thinking in this=20 > scenario we'd want to tread carefully regarding which CA wins in a tie= ,=20 > should bad things happen. >=20 > I realize this may be a corner case but felt it worth sharing. >=20 > Thanks,=20 > John >=20 > -------- Original message -------- > From: Tommy Jensen >=20 > Hey John, >=20 > I'm not sure how CAA records would help in the primary scenario of DEE= R=20 > where the stub is configured only with an IP address. Can you elaborat= e? >=20 > Thanks, > Tommy >=20 > *From:* Add on behalf of JW =CE=BB John Woodwor= th=20 > > *Sent:* Monday, November 16, 2020 3:54 PM > *To:* add@ietf.org > *Cc:* jw@pcthink.com > *Subject:* [EXTERNAL] [Add] CAA recommendation (DEER)=20 > =20 > Hello, >=20 > While reading the DEER draft, I had the thought that it may be a good=20= > idea to make use of CAA records a recommendation for encrypted-DNS=20 > certificates. I can see potential issues with open CA issued=20 > certificates. >=20 >=20 > Thanks,=20 > John >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > From nobody Tue Nov 17 20:06:01 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7033A13E0 for ; Tue, 17 Nov 2020 20:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 ALa8FKtB8VTb for ; Tue, 17 Nov 2020 20:05:57 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 D8F3F3A13DD for ; Tue, 17 Nov 2020 20:05:56 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id m13so541936ioq.9 for ; Tue, 17 Nov 2020 20:05:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KUaUWxh8zgQXfR11Zs+QXaAGQUGQeB26210nUH/bPWo=; b=Vb+VgcTEUGKSKlRm8v7FGCoeEh6e+/eEK0/dW/QvfgOFSjk4fNl2Wlt8NpoSTi2NlU gCbqNlIfk0bl1Z6BwUqSo0Lnrq3OjE40nNLFPCsAxOK+zfaXX63rRtgetBgixJRURlVc LW5HIPsDe/PmSrGtwpYkO76g3NN+hO1lJ3GT/oxH8XiA3/P1F9+jObg5sMCenmJ4ahf5 9og0STSQekJVhjlByxu9NxrpOnPAnEGnroYcYaQd1/UbIdj3lvx/pZNGOJFxWg+dtDDW 1GhSKI/LnflizFvCJobtW7+2muh4iXxFmJm0oYH702HLaA2r18YO547gtkyXNILYcQlp sYXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KUaUWxh8zgQXfR11Zs+QXaAGQUGQeB26210nUH/bPWo=; b=C47doem8qetjcREflrG+oVGw32zErI6ydF5vrAIXFQGh2vpkVD8RsoRzEgJOa8YR2a HoUPxJccjIQn1Vndvmym4fNHvEMHgoYli4W7X/cqAZsNdEDU+NOxR6qj+8M1cVT5Z9BD hVPEfVMHfZ66mW54X9Q4pS6TUPUDwMSaCclzk/ni2+T9+YSuaLv7UNyMTIU+yUZBOj/L rxUT+CucrKHi5WiQ0UpGgURVYNZIJXMuXrEsDPjEr36vsh2KxE2dA4gmjHN7NX5phuqv ADICeEH+VoNZNECNjVR8EQZ+a0D8P9sKrch7SLok4y5ihHjZ6riKH0HovJx605Vizw/h vsKA== X-Gm-Message-State: AOAM530Rrh8RIxjRqF7opifChyuE8hN2xbgzO1QmJ8DqF/Rj2srpFBVS npzocP8SagegzRPVXNJiSsjSAaI21is35XofYpI= X-Google-Smtp-Source: ABdhPJx+7ezD2nxg31VOsaRe4Pr6tCcGzp/65FVV6e04r8rzu4MbldasvrCkZQpJRRa5F5Y4OzkiVRUYG8eaOE8GaGA= X-Received: by 2002:a05:6602:59:: with SMTP id z25mr5353451ioz.2.1605672355875; Tue, 17 Nov 2020 20:05:55 -0800 (PST) MIME-Version: 1.0 References: <202011171815.0AHIFPdq005232@jax4mhob11.registeredsite.com> In-Reply-To: <202011171815.0AHIFPdq005232@jax4mhob11.registeredsite.com> From: tirumal reddy Date: Wed, 18 Nov 2020 11:05:44 +0700 Message-ID: To: =?UTF-8?Q?JW_=CE=BB_John_Woodworth?= Cc: Tommy Jensen , "add@ietf.org" Content-Type: multipart/alternative; boundary="00000000000065d0da05b459ba43" Archived-At: Subject: Re: [Add] [EXTERNAL] CAA recommendation (DEER) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 04:05:59 -0000 --00000000000065d0da05b459ba43 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi John, You may want to look into https://tools.ietf.org/html/draft-btw-add-home-10= , it discusses DHCP/RA extensions to discover the network-provided encrypted forwarder hosted on the CPE or network-provided encrypted resolver hosted in the ISP cloud. Resolver-identified discovery (DEER) can be used as a fallback for legacy (or non-upgradable) CPE. The draft also discusses that a ISP can assign a unique FQDN (e.g., cpe1.example.com) and a domain-validated public certificate to the encrypted DNS forwarder hosted on the managed CPE. Automatic Certificate Management Environment (ACME) can be used by the ISP to automate certificate management functions such as domain validation procedure, certificate issuance and certificate revocation. The other possible approach without having to manage public certificates on the home router is delegated credentials for TLS (see https://tools.ietf.org/html/draft-ietf-tls-subcerts-09) with keyless as a fallback. Cheers, -Tiru On Wed, 18 Nov 2020 at 01:15, JW =CE=BB John Woodworth wro= te: > Hi Tommy, > > Apologies for my vagueness. > > One of my objectives is to move some of the DNS decision making back to > the CPE. We have some influence over our vendors regarding features. > > Today, the CPE has knowledge of both parts of a split-horizon DNS and I > would like to leverage this knowledge via an encrypted-DNS enabled proxy = on > supported CPE's. > > This means _potentially_ managing millions of certificates and hostnames, > unique rfc1918 addresses, etc. I'm thinking in this scenario we'd want t= o > tread carefully regarding which CA wins in a tie, should bad things happe= n. > > I realize this may be a corner case but felt it worth sharing. > > Thanks, > John > > -------- Original message -------- > From: Tommy Jensen > > Hey John, > > I'm not sure how CAA records would help in the primary scenario of DEER > where the stub is configured only with an IP address. Can you elaborate? > > Thanks, > Tommy > > ------------------------------ > *From:* Add on behalf of JW =CE=BB John Woodworth = < > jw@pcthink.com> > *Sent:* Monday, November 16, 2020 3:54 PM > *To:* add@ietf.org > *Cc:* jw@pcthink.com > *Subject:* [EXTERNAL] [Add] CAA recommendation (DEER) > > Hello, > > While reading the DEER draft, I had the thought that it may be a good ide= a > to make use of CAA records a recommendation for encrypted-DNS > certificates. I can see potential issues with open CA issued certificate= s. > > > Thanks, > John > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --00000000000065d0da05b459ba43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi John,

You may want to loo= k into=C2=A0https://tools.ietf.org/html/draft-btw-add-home-10, it = discusses DHCP/RA extensions to discover the network-provided encrypted for= warder hosted on the CPE or network-provided encrypted resolver hosted in t= he ISP cloud.=C2=A0

Resolver-identified discovery (DEER)= can be used as a fallback for legacy (or non-upgradable) CPE.
The draft also discusses that a ISP can assign a unique FQDN (= e.g., cpe1.example.com) and a
= domain-validated public certificate to the encrypted DNS forwarder=C2=A0hos= ted on the managed CPE.=C2=A0 Automatic Certificate Management Environment= =C2=A0(ACME) can be used by the ISP to automate certificate=C2=A0management= functions such as domain validation procedure, certificate
issuance an= d certificate revocation.

The other possible appro= ach without having to manage public certificates on the home router is dele= gated credentials for TLS (see https://tools.ietf.org/html/draft-ietf-tls-subcerts-= 09) with keyless as a fallback.

Cheers,
<= div>-Tiru

On Wed, 18 Nov 2020 at 01:15, JW =CE=BB John Woodworth <= jw@pcthink.com> = wrote:
Hi Tommy,=C2=A0

Apol= ogies for my vagueness.

= One of my objectives is to move some of the DNS decision making back to the= CPE.=C2=A0 We have some influence over our vendors regarding features.

Today, the CPE has knowledg= e of both parts of a split-horizon DNS and I would like to leverage this kn= owledge via an encrypted-DNS enabled proxy on supported CPE's.

This means _potentially_ managin= g millions of certificates and hostnames,=C2=A0 unique rfc1918 addresses, e= tc.=C2=A0 I'm thinking in this scenario we'd want to tread carefull= y regarding which CA wins in a tie, should bad things happen.

I realize this may be a corner case b= ut felt it worth sharing.

Thanks,=C2=A0
John

-----= --- Original message --------
From: Tommy Jensen <Jensen.Thoma= s=3D40m= icrosoft.com@dmarc.ietf.org>

Hey John,

I'm not sure how CAA records would help in the primary scenario of DEER= where the stub is configured only with an IP address. Can you elaborate?

Thanks,
Tommy

From: Add <add-bounces@ietf.org> on behalf of JW =CE=BB John = Woodworth <jw@pcthin= k.com>
Sent: Monday, November 16, 2020 3:54 PM
To: add@ietf.org <add@ietf.org&g= t;
Cc: jw@pcthink.c= om <jw@pcthink.c= om>
Subject: [EXTERNAL] [Add] CAA recommendation (DEER)
=C2=A0
Hello,

While reading the DEER draft, I had the thought that it m= ay be a good idea to make use of CAA records a recommendation for encrypted= -DNS certificates.=C2=A0 I can see potential issues with open CA issued cer= tificates.


Thanks,=C2=A0
John

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--00000000000065d0da05b459ba43-- From nobody Tue Nov 17 23:10:56 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3B83A0C33 for ; Tue, 17 Nov 2020 23:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 2tYU9F_dJSew for ; Tue, 17 Nov 2020 23:10:53 -0800 (PST) Received: from jax4mhob19.registeredsite.com (jax4mhob19.registeredsite.com [64.69.218.107]) (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 12B2C3A0C25 for ; Tue, 17 Nov 2020 23:10:52 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by jax4mhob19.registeredsite.com (8.14.4/8.14.4) with ESMTP id 0AI7Amnn173332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 18 Nov 2020 02:10:48 -0500 Message-Id: <202011180710.0AI7Amnn173332@jax4mhob19.registeredsite.com> Received: (qmail 15461 invoked by uid 0); 18 Nov 2020 07:10:48 -0000 X-TCPREMOTEIP: 73.251.233.169 X-Authenticated-UID: jw@pcthink.com Received: from unknown (HELO ?10.2.1.116?) (jw@pcthink.com@73.251.233.169) by 0 with ESMTPA; 18 Nov 2020 07:10:47 -0000 SavedFromEmail: jw@pcthink.com Date: Wed, 18 Nov 2020 02:10:44 -0500 In-Reply-To: Importance: normal From: =?UTF-8?Q?JW_=CE=BB_John_Woodworth?= To: Martin Thomson , add@ietf.org Cc: jw@pcthink.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_827404295260640" Archived-At: Subject: Re: [Add] [EXTERNAL] CAA recommendation (DEER) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 07:10:55 -0000 ----_com.samsung.android.email_827404295260640 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgTWFydGluLFRoYW5rIHlvdSHCoCBJIHdpbGwgZGlnIGludG8gdGhpcyBtb3JlLi9Kb2huwqAK LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLUZyb206IE1hcnRpbiBUaG9tc29uIDxt dEBsb3dlbnRyb3B5Lm5ldD5JIHRoaW5rIHRoYXQgdGhlIERIQ1AvUkEgb3B0aW9ucyBmb3IgZGlz Y292ZXJ5IHByb3ZpZGUgdGhhdCBwYXRoLsKgIElmIHlvdSBjYW4gYWR2ZXJ0aXNlIERvVC9Eb0gg dGhhdCB3YXksIHRoZW4gdGhlIGNsaWVudHMgbWlnaHQgd2VsbCBkZWNpZGUgdGhlcmUgaXMgbm8g bmVlZCB0byB1c2UgREVFUiBvbiB0aGF0IG5ldHdvcmsuT24gV2VkLCBOb3YgMTgsIDIwMjAsIGF0 IDA1OjE1LCBKVyDOuyBKb2huIFdvb2R3b3J0aCB3cm90ZTo+IEhpIFRvbW15LCA+ID4gQXBvbG9n aWVzIGZvciBteSB2YWd1ZW5lc3MuPiA+IE9uZSBvZiBteSBvYmplY3RpdmVzIGlzIHRvIG1vdmUg c29tZSBvZiB0aGUgRE5TIGRlY2lzaW9uIG1ha2luZyBiYWNrIHRvID4gdGhlIENQRS7CoCBXZSBo YXZlIHNvbWUgaW5mbHVlbmNlIG92ZXIgb3VyIHZlbmRvcnMgcmVnYXJkaW5nIGZlYXR1cmVzLj4g PiBUb2RheSwgdGhlIENQRSBoYXMga25vd2xlZGdlIG9mIGJvdGggcGFydHMgb2YgYSBzcGxpdC1o b3Jpem9uIEROUyBhbmQgSSA+IHdvdWxkIGxpa2UgdG8gbGV2ZXJhZ2UgdGhpcyBrbm93bGVkZ2Ug dmlhIGFuIGVuY3J5cHRlZC1ETlMgZW5hYmxlZCA+IHByb3h5IG9uIHN1cHBvcnRlZCBDUEUncy4+ ID4gVGhpcyBtZWFucyBfcG90ZW50aWFsbHlfIG1hbmFnaW5nIG1pbGxpb25zIG9mIGNlcnRpZmlj YXRlcyBhbmQgPiBob3N0bmFtZXMswqAgdW5pcXVlIHJmYzE5MTggYWRkcmVzc2VzLCBldGMuwqAg SSdtIHRoaW5raW5nIGluIHRoaXMgPiBzY2VuYXJpbyB3ZSdkIHdhbnQgdG8gdHJlYWQgY2FyZWZ1 bGx5IHJlZ2FyZGluZyB3aGljaCBDQSB3aW5zIGluIGEgdGllLCA+IHNob3VsZCBiYWQgdGhpbmdz IGhhcHBlbi4+ID4gSSByZWFsaXplIHRoaXMgbWF5IGJlIGEgY29ybmVyIGNhc2UgYnV0IGZlbHQg aXQgd29ydGggc2hhcmluZy4+ID4gVGhhbmtzLCA+IEpvaG4+ID4gLS0tLS0tLS0gT3JpZ2luYWwg bWVzc2FnZSAtLS0tLS0tLT4gRnJvbTogVG9tbXkgSmVuc2VuIDxKZW5zZW4uVGhvbWFzPTQwbWlj cm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4+ID4gSGV5IEpvaG4sPiA+IEknbSBub3Qgc3VyZSBo b3cgQ0FBIHJlY29yZHMgd291bGQgaGVscCBpbiB0aGUgcHJpbWFyeSBzY2VuYXJpbyBvZiBERUVS ID4gd2hlcmUgdGhlIHN0dWIgaXMgY29uZmlndXJlZCBvbmx5IHdpdGggYW4gSVAgYWRkcmVzcy4g Q2FuIHlvdSBlbGFib3JhdGU/PiA+IFRoYW5rcyw+IFRvbW15PiA+ICpGcm9tOiogQWRkIDxhZGQt Ym91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEpXIM67IEpvaG4gV29vZHdvcnRoID4gPGp3 QHBjdGhpbmsuY29tPj4gKlNlbnQ6KiBNb25kYXksIE5vdmVtYmVyIDE2LCAyMDIwIDM6NTQgUE0+ ICpUbzoqIGFkZEBpZXRmLm9yZyA8YWRkQGlldGYub3JnPj4gKkNjOiogandAcGN0aGluay5jb20g PGp3QHBjdGhpbmsuY29tPj4gKlN1YmplY3Q6KiBbRVhURVJOQUxdIFtBZGRdIENBQSByZWNvbW1l bmRhdGlvbiAoREVFUikgPsKgID4gSGVsbG8sPiA+IFdoaWxlIHJlYWRpbmcgdGhlIERFRVIgZHJh ZnQsIEkgaGFkIHRoZSB0aG91Z2h0IHRoYXQgaXQgbWF5IGJlIGEgZ29vZCA+IGlkZWEgdG8gbWFr ZSB1c2Ugb2YgQ0FBIHJlY29yZHMgYSByZWNvbW1lbmRhdGlvbiBmb3IgZW5jcnlwdGVkLUROUyA+ IGNlcnRpZmljYXRlcy7CoCBJIGNhbiBzZWUgcG90ZW50aWFsIGlzc3VlcyB3aXRoIG9wZW4gQ0Eg aXNzdWVkID4gY2VydGlmaWNhdGVzLj4gPiA+IFRoYW5rcywgPiBKb2huPiA+IC0tID4gQWRkIG1h aWxpbmcgbGlzdD4gQWRkQGlldGYub3JnPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2FkZD4tLSBBZGQgbWFpbGluZyBsaXN0QWRkQGlldGYub3JnaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hZGQ= ----_com.samsung.android.email_827404295260640 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPkhpIE1hcnRpbiw8 ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5UaGFuayB5b3UhJm5ic3A7 IEkgd2lsbCBkaWcgaW50byB0aGlzIG1vcmUuPC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rp dj48ZGl2IGRpcj0iYXV0byI+L0pvaG4mbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IGFs aWduPSJsZWZ0IiBkaXI9ImF1dG8iIHN0eWxlPSJmb250LXNpemU6MTAwJTtjb2xvcjojMDAwMDAw Ij48ZGl2Pi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2PkZyb206 IE1hcnRpbiBUaG9tc29uICZsdDttdEBsb3dlbnRyb3B5Lm5ldCZndDs8L2Rpdj48ZGl2Pjxicj48 L2Rpdj48L2Rpdj5JIHRoaW5rIHRoYXQgdGhlIERIQ1AvUkEgb3B0aW9ucyBmb3IgZGlzY292ZXJ5 IHByb3ZpZGUgdGhhdCBwYXRoLiZuYnNwOyBJZiB5b3UgY2FuIGFkdmVydGlzZSBEb1QvRG9IIHRo YXQgd2F5LCB0aGVuIHRoZSBjbGllbnRzIG1pZ2h0IHdlbGwgZGVjaWRlIHRoZXJlIGlzIG5vIG5l ZWQgdG8gdXNlIERFRVIgb24gdGhhdCBuZXR3b3JrLjxiciBkaXI9ImF1dG8iPjxiciBkaXI9ImF1 dG8iPk9uIFdlZCwgTm92IDE4LCAyMDIwLCBhdCAwNToxNSwgSlcgzrsgSm9obiBXb29kd29ydGgg d3JvdGU6PGJyIGRpcj0iYXV0byI+Jmd0OyBIaSBUb21teSwgPGJyIGRpcj0iYXV0byI+Jmd0OyA8 YnIgZGlyPSJhdXRvIj4mZ3Q7IEFwb2xvZ2llcyBmb3IgbXkgdmFndWVuZXNzLjxiciBkaXI9ImF1 dG8iPiZndDsgPGJyIGRpcj0iYXV0byI+Jmd0OyBPbmUgb2YgbXkgb2JqZWN0aXZlcyBpcyB0byBt b3ZlIHNvbWUgb2YgdGhlIEROUyBkZWNpc2lvbiBtYWtpbmcgYmFjayB0byA8YnIgZGlyPSJhdXRv Ij4mZ3Q7IHRoZSBDUEUuJm5ic3A7IFdlIGhhdmUgc29tZSBpbmZsdWVuY2Ugb3ZlciBvdXIgdmVu ZG9ycyByZWdhcmRpbmcgZmVhdHVyZXMuPGJyIGRpcj0iYXV0byI+Jmd0OyA8YnIgZGlyPSJhdXRv Ij4mZ3Q7IFRvZGF5LCB0aGUgQ1BFIGhhcyBrbm93bGVkZ2Ugb2YgYm90aCBwYXJ0cyBvZiBhIHNw bGl0LWhvcml6b24gRE5TIGFuZCBJIDxiciBkaXI9ImF1dG8iPiZndDsgd291bGQgbGlrZSB0byBs ZXZlcmFnZSB0aGlzIGtub3dsZWRnZSB2aWEgYW4gZW5jcnlwdGVkLUROUyBlbmFibGVkIDxiciBk aXI9ImF1dG8iPiZndDsgcHJveHkgb24gc3VwcG9ydGVkIENQRSdzLjxiciBkaXI9ImF1dG8iPiZn dDsgPGJyIGRpcj0iYXV0byI+Jmd0OyBUaGlzIG1lYW5zIF9wb3RlbnRpYWxseV8gbWFuYWdpbmcg bWlsbGlvbnMgb2YgY2VydGlmaWNhdGVzIGFuZCA8YnIgZGlyPSJhdXRvIj4mZ3Q7IGhvc3RuYW1l cywmbmJzcDsgdW5pcXVlIHJmYzE5MTggYWRkcmVzc2VzLCBldGMuJm5ic3A7IEknbSB0aGlua2lu ZyBpbiB0aGlzIDxiciBkaXI9ImF1dG8iPiZndDsgc2NlbmFyaW8gd2UnZCB3YW50IHRvIHRyZWFk IGNhcmVmdWxseSByZWdhcmRpbmcgd2hpY2ggQ0Egd2lucyBpbiBhIHRpZSwgPGJyIGRpcj0iYXV0 byI+Jmd0OyBzaG91bGQgYmFkIHRoaW5ncyBoYXBwZW4uPGJyIGRpcj0iYXV0byI+Jmd0OyA8YnIg ZGlyPSJhdXRvIj4mZ3Q7IEkgcmVhbGl6ZSB0aGlzIG1heSBiZSBhIGNvcm5lciBjYXNlIGJ1dCBm ZWx0IGl0IHdvcnRoIHNoYXJpbmcuPGJyIGRpcj0iYXV0byI+Jmd0OyA8YnIgZGlyPSJhdXRvIj4m Z3Q7IFRoYW5rcywgPGJyIGRpcj0iYXV0byI+Jmd0OyBKb2huPGJyIGRpcj0iYXV0byI+Jmd0OyA8 YnIgZGlyPSJhdXRvIj4mZ3Q7IC0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08YnIg ZGlyPSJhdXRvIj4mZ3Q7IEZyb206IFRvbW15IEplbnNlbiAmbHQ7SmVuc2VuLlRob21hcz00MG1p Y3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyIGRpcj0iYXV0byI+Jmd0OyA8YnIgZGly PSJhdXRvIj4mZ3Q7IEhleSBKb2huLDxiciBkaXI9ImF1dG8iPiZndDsgPGJyIGRpcj0iYXV0byI+ Jmd0OyBJJ20gbm90IHN1cmUgaG93IENBQSByZWNvcmRzIHdvdWxkIGhlbHAgaW4gdGhlIHByaW1h cnkgc2NlbmFyaW8gb2YgREVFUiA8YnIgZGlyPSJhdXRvIj4mZ3Q7IHdoZXJlIHRoZSBzdHViIGlz IGNvbmZpZ3VyZWQgb25seSB3aXRoIGFuIElQIGFkZHJlc3MuIENhbiB5b3UgZWxhYm9yYXRlPzxi ciBkaXI9ImF1dG8iPiZndDsgPGJyIGRpcj0iYXV0byI+Jmd0OyBUaGFua3MsPGJyIGRpcj0iYXV0 byI+Jmd0OyBUb21teTxiciBkaXI9ImF1dG8iPiZndDsgPGJyIGRpcj0iYXV0byI+Jmd0OyAqRnJv bToqIEFkZCAmbHQ7YWRkLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBKVyDOuyBK b2huIFdvb2R3b3J0aCA8YnIgZGlyPSJhdXRvIj4mZ3Q7ICZsdDtqd0BwY3RoaW5rLmNvbSZndDs8 YnIgZGlyPSJhdXRvIj4mZ3Q7ICpTZW50OiogTW9uZGF5LCBOb3ZlbWJlciAxNiwgMjAyMCAzOjU0 IFBNPGJyIGRpcj0iYXV0byI+Jmd0OyAqVG86KiBhZGRAaWV0Zi5vcmcgJmx0O2FkZEBpZXRmLm9y ZyZndDs8YnIgZGlyPSJhdXRvIj4mZ3Q7ICpDYzoqIGp3QHBjdGhpbmsuY29tICZsdDtqd0BwY3Ro aW5rLmNvbSZndDs8YnIgZGlyPSJhdXRvIj4mZ3Q7ICpTdWJqZWN0OiogW0VYVEVSTkFMXSBbQWRk XSBDQUEgcmVjb21tZW5kYXRpb24gKERFRVIpIDxiciBkaXI9ImF1dG8iPiZndDsmbmJzcDsgPGJy IGRpcj0iYXV0byI+Jmd0OyBIZWxsbyw8YnIgZGlyPSJhdXRvIj4mZ3Q7IDxiciBkaXI9ImF1dG8i PiZndDsgV2hpbGUgcmVhZGluZyB0aGUgREVFUiBkcmFmdCwgSSBoYWQgdGhlIHRob3VnaHQgdGhh dCBpdCBtYXkgYmUgYSBnb29kIDxiciBkaXI9ImF1dG8iPiZndDsgaWRlYSB0byBtYWtlIHVzZSBv ZiBDQUEgcmVjb3JkcyBhIHJlY29tbWVuZGF0aW9uIGZvciBlbmNyeXB0ZWQtRE5TIDxiciBkaXI9 ImF1dG8iPiZndDsgY2VydGlmaWNhdGVzLiZuYnNwOyBJIGNhbiBzZWUgcG90ZW50aWFsIGlzc3Vl cyB3aXRoIG9wZW4gQ0EgaXNzdWVkIDxiciBkaXI9ImF1dG8iPiZndDsgY2VydGlmaWNhdGVzLjxi ciBkaXI9ImF1dG8iPiZndDsgPGJyIGRpcj0iYXV0byI+Jmd0OyA8YnIgZGlyPSJhdXRvIj4mZ3Q7 IFRoYW5rcywgPGJyIGRpcj0iYXV0byI+Jmd0OyBKb2huPGJyIGRpcj0iYXV0byI+Jmd0OyA8YnIg ZGlyPSJhdXRvIj4mZ3Q7IC0tIDxiciBkaXI9ImF1dG8iPiZndDsgQWRkIG1haWxpbmcgbGlzdDxi ciBkaXI9ImF1dG8iPiZndDsgQWRkQGlldGYub3JnPGJyIGRpcj0iYXV0byI+Jmd0OyBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FkZDxiciBkaXI9ImF1dG8iPiZndDs8YnIg ZGlyPSJhdXRvIj48YnIgZGlyPSJhdXRvIj4tLSA8YnIgZGlyPSJhdXRvIj5BZGQgbWFpbGluZyBs aXN0PGJyIGRpcj0iYXV0byI+QWRkQGlldGYub3JnPGJyIGRpcj0iYXV0byI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hZGQ8YnIgZGlyPSJhdXRvIj48L2JvZHk+PC9odG1s Pg== ----_com.samsung.android.email_827404295260640-- From nobody Tue Nov 17 23:13:49 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBD83A0C51 for ; Tue, 17 Nov 2020 23:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 6YQtneQVmnz9 for ; Tue, 17 Nov 2020 23:13:46 -0800 (PST) Received: from jax4mhob12.registeredsite.com (jax4mhob12.myregisteredsite.com [64.69.218.92]) (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 18DF33A0C4E for ; Tue, 17 Nov 2020 23:13:46 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by jax4mhob12.registeredsite.com (8.14.4/8.14.4) with ESMTP id 0AI7DeRQ029619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 18 Nov 2020 02:13:40 -0500 Message-Id: <202011180713.0AI7DeRQ029619@jax4mhob12.registeredsite.com> Received: (qmail 4757 invoked by uid 0); 18 Nov 2020 07:13:40 -0000 X-TCPREMOTEIP: 73.251.233.169 X-Authenticated-UID: jw@pcthink.com Received: from unknown (HELO ?10.2.1.116?) (jw@pcthink.com@73.251.233.169) by 0 with ESMTPA; 18 Nov 2020 07:13:39 -0000 SavedFromEmail: jw@pcthink.com Date: Wed, 18 Nov 2020 02:13:35 -0500 In-Reply-To: Importance: normal From: =?UTF-8?Q?JW_=CE=BB_John_Woodworth?= To: tirumal reddy Cc: jw@pcthink.com, "add@ietf.org" , Tommy Jensen MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_829117631977690" Archived-At: Subject: Re: [Add] [EXTERNAL] CAA recommendation (DEER) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 07:13:48 -0000 ----_com.samsung.android.email_829117631977690 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgVGlydSxUaGFuayB5b3UgZm9yIHRoZSBsaW5rcyHCoCBJIHdpbGwgcmV2aWV3IGFuZCBzZWUg aWYgdGhpcyBzb2x2ZXMgdGhpbmdzIGZvciBtZS4vSm9obsKgCi0tLS0tLS0tIE9yaWdpbmFsIG1l c3NhZ2UgLS0tLS0tLS1Gcm9tOiB0aXJ1bWFsIHJlZGR5IDxrb25kdGlyQGdtYWlsLmNvbT5IaSBK b2huLFlvdSBtYXkgd2FudCB0byBsb29rIGludG/CoGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1idHctYWRkLWhvbWUtMTAsIGl0IGRpc2N1c3NlcyBESENQL1JBIGV4dGVuc2lvbnMg dG8gZGlzY292ZXIgdGhlIG5ldHdvcmstcHJvdmlkZWQgZW5jcnlwdGVkIGZvcndhcmRlciBob3N0 ZWQgb24gdGhlIENQRSBvciBuZXR3b3JrLXByb3ZpZGVkIGVuY3J5cHRlZCByZXNvbHZlciBob3N0 ZWQgaW4gdGhlIElTUCBjbG91ZC7CoFJlc29sdmVyLWlkZW50aWZpZWQgZGlzY292ZXJ5IChERUVS KSBjYW4gYmUgdXNlZCBhcyBhIGZhbGxiYWNrIGZvciBsZWdhY3kgKG9yIG5vbi11cGdyYWRhYmxl KSBDUEUuVGhlIGRyYWZ0IGFsc28gZGlzY3Vzc2VzIHRoYXQgYSBJU1AgY2FuIGFzc2lnbiBhIHVu aXF1ZSBGUUROIChlLmcuLCBjcGUxLmV4YW1wbGUuY29tKSBhbmQgYWRvbWFpbi12YWxpZGF0ZWQg cHVibGljIGNlcnRpZmljYXRlIHRvIHRoZSBlbmNyeXB0ZWQgRE5TIGZvcndhcmRlcsKgaG9zdGVk IG9uIHRoZSBtYW5hZ2VkIENQRS7CoCBBdXRvbWF0aWMgQ2VydGlmaWNhdGUgTWFuYWdlbWVudCBF bnZpcm9ubWVudMKgKEFDTUUpIGNhbiBiZSB1c2VkIGJ5IHRoZSBJU1AgdG8gYXV0b21hdGUgY2Vy dGlmaWNhdGXCoG1hbmFnZW1lbnQgZnVuY3Rpb25zIHN1Y2ggYXMgZG9tYWluIHZhbGlkYXRpb24g cHJvY2VkdXJlLCBjZXJ0aWZpY2F0ZWlzc3VhbmNlIGFuZCBjZXJ0aWZpY2F0ZSByZXZvY2F0aW9u LlRoZSBvdGhlciBwb3NzaWJsZSBhcHByb2FjaCB3aXRob3V0IGhhdmluZyB0byBtYW5hZ2UgcHVi bGljIGNlcnRpZmljYXRlcyBvbiB0aGUgaG9tZSByb3V0ZXIgaXMgZGVsZWdhdGVkIGNyZWRlbnRp YWxzIGZvciBUTFMgKHNlZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10 bHMtc3ViY2VydHMtMDkpIHdpdGgga2V5bGVzcyBhcyBhIGZhbGxiYWNrLkNoZWVycywtVGlydU9u IFdlZCwgMTggTm92IDIwMjAgYXQgMDE6MTUsIEpXIM67IEpvaG4gV29vZHdvcnRoIDxqd0BwY3Ro aW5rLmNvbT4gd3JvdGU6SGkgVG9tbXkswqBBcG9sb2dpZXMgZm9yIG15IHZhZ3VlbmVzcy5PbmUg b2YgbXkgb2JqZWN0aXZlcyBpcyB0byBtb3ZlIHNvbWUgb2YgdGhlIEROUyBkZWNpc2lvbiBtYWtp bmcgYmFjayB0byB0aGUgQ1BFLsKgIFdlIGhhdmUgc29tZSBpbmZsdWVuY2Ugb3ZlciBvdXIgdmVu ZG9ycyByZWdhcmRpbmcgZmVhdHVyZXMuVG9kYXksIHRoZSBDUEUgaGFzIGtub3dsZWRnZSBvZiBi b3RoIHBhcnRzIG9mIGEgc3BsaXQtaG9yaXpvbiBETlMgYW5kIEkgd291bGQgbGlrZSB0byBsZXZl cmFnZSB0aGlzIGtub3dsZWRnZSB2aWEgYW4gZW5jcnlwdGVkLUROUyBlbmFibGVkIHByb3h5IG9u IHN1cHBvcnRlZCBDUEUncy5UaGlzIG1lYW5zIF9wb3RlbnRpYWxseV8gbWFuYWdpbmcgbWlsbGlv bnMgb2YgY2VydGlmaWNhdGVzIGFuZCBob3N0bmFtZXMswqAgdW5pcXVlIHJmYzE5MTggYWRkcmVz c2VzLCBldGMuwqAgSSdtIHRoaW5raW5nIGluIHRoaXMgc2NlbmFyaW8gd2UnZCB3YW50IHRvIHRy ZWFkIGNhcmVmdWxseSByZWdhcmRpbmcgd2hpY2ggQ0Egd2lucyBpbiBhIHRpZSwgc2hvdWxkIGJh ZCB0aGluZ3MgaGFwcGVuLkkgcmVhbGl6ZSB0aGlzIG1heSBiZSBhIGNvcm5lciBjYXNlIGJ1dCBm ZWx0IGl0IHdvcnRoIHNoYXJpbmcuVGhhbmtzLMKgSm9obi0tLS0tLS0tIE9yaWdpbmFsIG1lc3Nh Z2UgLS0tLS0tLS1Gcm9tOiBUb21teSBKZW5zZW4gPEplbnNlbi5UaG9tYXM9NDBtaWNyb3NvZnQu Y29tQGRtYXJjLmlldGYub3JnPgoKSGV5IEpvaG4sCgoKCgpJJ20gbm90IHN1cmUgaG93IENBQSBy ZWNvcmRzIHdvdWxkIGhlbHAgaW4gdGhlIHByaW1hcnkgc2NlbmFyaW8gb2YgREVFUiB3aGVyZSB0 aGUgc3R1YiBpcyBjb25maWd1cmVkIG9ubHkgd2l0aCBhbiBJUCBhZGRyZXNzLiBDYW4geW91IGVs YWJvcmF0ZT8KCgoKClRoYW5rcywKClRvbW15CgoKCgoKRnJvbTogQWRkIDxhZGQtYm91bmNlc0Bp ZXRmLm9yZz4gb24gYmVoYWxmIG9mIEpXIM67IEpvaG4gV29vZHdvcnRoIDxqd0BwY3RoaW5rLmNv bT4KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxNiwgMjAyMCAzOjU0IFBNClRvOiBhZGRAaWV0Zi5v cmcgPGFkZEBpZXRmLm9yZz4KQ2M6IGp3QHBjdGhpbmsuY29tIDxqd0BwY3RoaW5rLmNvbT4KU3Vi amVjdDogW0VYVEVSTkFMXSBbQWRkXSBDQUEgcmVjb21tZW5kYXRpb24gKERFRVIpCsKgCgoKSGVs bG8sCgoKV2hpbGUgcmVhZGluZyB0aGUgREVFUiBkcmFmdCwgSSBoYWQgdGhlIHRob3VnaHQgdGhh dCBpdCBtYXkgYmUgYSBnb29kIGlkZWEgdG8gbWFrZSB1c2Ugb2YgQ0FBIHJlY29yZHMgYSByZWNv bW1lbmRhdGlvbiBmb3IgZW5jcnlwdGVkLUROUyBjZXJ0aWZpY2F0ZXMuwqAgSSBjYW4gc2VlIHBv dGVudGlhbCBpc3N1ZXMgd2l0aCBvcGVuIENBIGlzc3VlZCBjZXJ0aWZpY2F0ZXMuCgoKCgpUaGFu a3MswqAKSm9obgoKCgoKCi0tIApBZGQgbWFpbGluZyBsaXN0CkFkZEBpZXRmLm9yZwpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FkZAoK ----_com.samsung.android.email_829117631977690 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPkhpIFRpcnUsPGRp diBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+VGhhbmsgeW91IGZvciB0aGUg bGlua3MhJm5ic3A7IEkgd2lsbCByZXZpZXcgYW5kIHNlZSBpZiB0aGlzIHNvbHZlcyB0aGluZ3Mg Zm9yIG1lLjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPi9K b2huJm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBhbGlnbj0ibGVmdCIgZGlyPSJhdXRv IiBzdHlsZT0iZm9udC1zaXplOjEwMCU7Y29sb3I6IzAwMDAwMCI+PGRpdj4tLS0tLS0tLSBPcmln aW5hbCBtZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiB0aXJ1bWFsIHJlZGR5ICZsdDtr b25kdGlyQGdtYWlsLmNvbSZndDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rpdj48ZGl2IGRpcj0i bHRyIj48ZGl2PkhpIEpvaG4sPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Zb3UgbWF5IHdhbnQg dG8gbG9vayBpbnRvJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWJ0dy1hZGQtaG9tZS0xMCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ0 dy1hZGQtaG9tZS0xMDwvYT4sIGl0IGRpc2N1c3NlcyBESENQL1JBIGV4dGVuc2lvbnMgdG8gZGlz Y292ZXIgdGhlIG5ldHdvcmstcHJvdmlkZWQgZW5jcnlwdGVkIGZvcndhcmRlciBob3N0ZWQgb24g dGhlIENQRSBvciBuZXR3b3JrLXByb3ZpZGVkIGVuY3J5cHRlZCByZXNvbHZlciBob3N0ZWQgaW4g dGhlIElTUCBjbG91ZC4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5z LXNlcmlmO2ZvbnQtc2l6ZToxMXB0Ij48L3NwYW4+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5S ZXNvbHZlci1pZGVudGlmaWVkIGRpc2NvdmVyeSAoREVFUikgY2FuIGJlIHVzZWQgYXMgYSBmYWxs YmFjayBmb3IgbGVnYWN5IChvciBub24tdXBncmFkYWJsZSkgQ1BFLjwvZGl2PjxkaXY+PGJyPjwv ZGl2PjxkaXY+VGhlIGRyYWZ0IGFsc28gZGlzY3Vzc2VzIHRoYXQgYSBJU1AgY2FuIGFzc2lnbiBh IHVuaXF1ZSBGUUROIChlLmcuLCA8YSBocmVmPSJodHRwOi8vY3BlMS5leGFtcGxlLmNvbSI+Y3Bl MS5leGFtcGxlLmNvbTwvYT4pIGFuZCBhPC9kaXY+ZG9tYWluLXZhbGlkYXRlZCBwdWJsaWMgY2Vy dGlmaWNhdGUgdG8gdGhlIGVuY3J5cHRlZCBETlMgZm9yd2FyZGVyJm5ic3A7aG9zdGVkIG9uIHRo ZSBtYW5hZ2VkIENQRS4mbmJzcDsgQXV0b21hdGljIENlcnRpZmljYXRlIE1hbmFnZW1lbnQgRW52 aXJvbm1lbnQmbmJzcDsoQUNNRSkgY2FuIGJlIHVzZWQgYnkgdGhlIElTUCB0byBhdXRvbWF0ZSBj ZXJ0aWZpY2F0ZSZuYnNwO21hbmFnZW1lbnQgZnVuY3Rpb25zIHN1Y2ggYXMgZG9tYWluIHZhbGlk YXRpb24gcHJvY2VkdXJlLCBjZXJ0aWZpY2F0ZTxkaXY+aXNzdWFuY2UgYW5kIGNlcnRpZmljYXRl IHJldm9jYXRpb24uPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGUgb3RoZXIgcG9zc2libGUg YXBwcm9hY2ggd2l0aG91dCBoYXZpbmcgdG8gbWFuYWdlIHB1YmxpYyBjZXJ0aWZpY2F0ZXMgb24g dGhlIGhvbWUgcm91dGVyIGlzIGRlbGVnYXRlZCBjcmVkZW50aWFscyBmb3IgVExTIChzZWUgPGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGxzLXN1YmNlcnRz LTA5Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10bHMtc3ViY2VydHMt MDk8L2E+KSB3aXRoIGtleWxlc3MgYXMgYSBmYWxsYmFjay48L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2PkNoZWVycyw8L2Rpdj48ZGl2Pi1UaXJ1PC9kaXY+PGRpdj48YnI+PGRpdiBjbGFzcz0iZ21h aWxfcXVvdGUiPjxkaXYgY2xhc3M9ImdtYWlsX2F0dHIiIGRpcj0ibHRyIj5PbiBXZWQsIDE4IE5v diAyMDIwIGF0IDAxOjE1LCBKVyDOuyBKb2huIFdvb2R3b3J0aCAmbHQ7PGEgaHJlZj0ibWFpbHRv Omp3QHBjdGhpbmsuY29tIj5qd0BwY3RoaW5rLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj48L2Rpdj48 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFw eCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiIGNsYXNzPSJnbWFpbF9x dW90ZSI+PGRpdiBkaXI9ImF1dG8iPkhpIFRvbW15LCZuYnNwOzxkaXYgZGlyPSJhdXRvIj48YnI+ PC9kaXY+PGRpdiBkaXI9ImF1dG8iPkFwb2xvZ2llcyBmb3IgbXkgdmFndWVuZXNzLjwvZGl2Pjxk aXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPk9uZSBvZiBteSBvYmplY3Rp dmVzIGlzIHRvIG1vdmUgc29tZSBvZiB0aGUgRE5TIGRlY2lzaW9uIG1ha2luZyBiYWNrIHRvIHRo ZSBDUEUuJm5ic3A7IFdlIGhhdmUgc29tZSBpbmZsdWVuY2Ugb3ZlciBvdXIgdmVuZG9ycyByZWdh cmRpbmcgZmVhdHVyZXMuPC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0i YXV0byI+VG9kYXksIHRoZSBDUEUgaGFzIGtub3dsZWRnZSBvZiBib3RoIHBhcnRzIG9mIGEgc3Bs aXQtaG9yaXpvbiBETlMgYW5kIEkgd291bGQgbGlrZSB0byBsZXZlcmFnZSB0aGlzIGtub3dsZWRn ZSB2aWEgYW4gZW5jcnlwdGVkLUROUyBlbmFibGVkIHByb3h5IG9uIHN1cHBvcnRlZCBDUEUncy48 L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5UaGlzIG1lYW5z IF9wb3RlbnRpYWxseV8gbWFuYWdpbmcgbWlsbGlvbnMgb2YgY2VydGlmaWNhdGVzIGFuZCBob3N0 bmFtZXMsJm5ic3A7IHVuaXF1ZSByZmMxOTE4IGFkZHJlc3NlcywgZXRjLiZuYnNwOyBJJ20gdGhp bmtpbmcgaW4gdGhpcyBzY2VuYXJpbyB3ZSdkIHdhbnQgdG8gdHJlYWQgY2FyZWZ1bGx5IHJlZ2Fy ZGluZyB3aGljaCBDQSB3aW5zIGluIGEgdGllLCBzaG91bGQgYmFkIHRoaW5ncyBoYXBwZW4uPC9k aXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+SSByZWFsaXplIHRo aXMgbWF5IGJlIGEgY29ybmVyIGNhc2UgYnV0IGZlbHQgaXQgd29ydGggc2hhcmluZy48L2Rpdj48 ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5UaGFua3MsJm5ic3A7PC9k aXY+PGRpdiBkaXI9ImF1dG8iPkpvaG48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IHN0eWxlPSJm b250LXNpemU6MTAwJTtjb2xvcjpyZ2IoMCwwLDApIiBkaXI9ImF1dG8iIGFsaWduPSJsZWZ0Ij48 ZGl2Pi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2PkZyb206IFRv bW15IEplbnNlbiAmbHQ7SmVuc2VuLlRob21hcz08YSBocmVmPSJtYWlsdG86NDBtaWNyb3NvZnQu Y29tQGRtYXJjLmlldGYub3JnIj40MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0 OzwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2Pgo8ZGl2IGRpcj0iYXV0byIgc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOjEycHQ7 Y29sb3I6cmdiKDAsMCwwKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPgpIZXkg Sm9obiw8L2Rpdj4KPGRpdiBkaXI9ImF1dG8iIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEFy aWFsLEhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMnB0O2NvbG9yOnJnYigwLDAsMCk7 YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj4KPGJyPgo8L2Rpdj4KPGRpdiBkaXI9 ImF1dG8iIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNl cmlmO2ZvbnQtc2l6ZToxMnB0O2NvbG9yOnJnYigwLDAsMCk7YmFja2dyb3VuZC1jb2xvcjpyZ2Io MjU1LDI1NSwyNTUpIj4KSSdtIG5vdCBzdXJlIGhvdyBDQUEgcmVjb3JkcyB3b3VsZCBoZWxwIGlu IHRoZSBwcmltYXJ5IHNjZW5hcmlvIG9mIERFRVIgd2hlcmUgdGhlIHN0dWIgaXMgY29uZmlndXJl ZCBvbmx5IHdpdGggYW4gSVAgYWRkcmVzcy4gQ2FuIHlvdSBlbGFib3JhdGU/PC9kaXY+CjxkaXYg ZGlyPSJhdXRvIiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fu cy1zZXJpZjtmb250LXNpemU6MTJwdDtjb2xvcjpyZ2IoMCwwLDApO2JhY2tncm91bmQtY29sb3I6 cmdiKDI1NSwyNTUsMjU1KSI+Cjxicj4KPC9kaXY+CjxkaXYgZGlyPSJhdXRvIiBzdHlsZT0iZm9u dC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6MTJw dDtjb2xvcjpyZ2IoMCwwLDApO2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+ClRo YW5rcyw8L2Rpdj4KPGRpdiBkaXI9ImF1dG8iIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEFy aWFsLEhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMnB0O2NvbG9yOnJnYigwLDAsMCk7 YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj4KVG9tbXk8L2Rpdj4KPGRpdiBkaXI9 ImF1dG8iIGlkPSJtXzM0MTE0OTQ5NzYwMDMzMTM3MjBnbWFpbC1tXzE0MzA5MTExNzE0MzQ0Mzg1 MjJhcHBlbmRvbnNlbmQiPjwvZGl2Pgo8ZGl2IGRpcj0iYXV0byIgc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOjEycHQ7Y29sb3I6 cmdiKDAsMCwwKSI+Cjxicj4KPC9kaXY+CjxociBkaXI9ImF1dG8iIHN0eWxlPSJkaXNwbGF5Omlu bGluZS1ibG9jazt3aWR0aDo5OCUiPgo8ZGl2IGlkPSJtXzM0MTE0OTQ5NzYwMDMzMTM3MjBnbWFp bC1tXzE0MzA5MTExNzE0MzQ0Mzg1MjJkaXZScGx5RndkTXNnIiBkaXI9Imx0ciI+PGZvbnQgZmFj ZT0iQ2FsaWJyaSwgc2Fucy1zZXJpZiIgY29sb3I9IiMwMDAwMDAiIHN0eWxlPSJmb250LXNpemU6 MTFwdCI+PGI+RnJvbTo8L2I+IEFkZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkZC1ib3VuY2VzQGll dGYub3JnIj5hZGQtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBKVyDOuyBK b2huIFdvb2R3b3J0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmp3QHBjdGhpbmsuY29tIj5qd0BwY3Ro aW5rLmNvbTwvYT4mZ3Q7PGJyPgo8Yj5TZW50OjwvYj4gTW9uZGF5LCBOb3ZlbWJlciAxNiwgMjAy MCAzOjU0IFBNPGJyPgo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzphZGRAaWV0Zi5vcmciPmFk ZEBpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzphZGRAaWV0Zi5vcmciPmFkZEBpZXRm Lm9yZzwvYT4mZ3Q7PGJyPgo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpqd0BwY3RoaW5rLmNv bSI+andAcGN0aGluay5jb208L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86andAcGN0aGluay5jb20i Pmp3QHBjdGhpbmsuY29tPC9hPiZndDs8YnI+CjxiPlN1YmplY3Q6PC9iPiBbRVhURVJOQUxdIFtB ZGRdIENBQSByZWNvbW1lbmRhdGlvbiAoREVFUik8L2ZvbnQ+CjxkaXY+Jm5ic3A7PC9kaXY+Cjwv ZGl2Pgo8ZGl2IGRpcj0iYXV0byI+CjxkaXYgZGlyPSJhdXRvIj5IZWxsbyw8L2Rpdj4KPGRpdiBk aXI9ImF1dG8iPjxicj4KPC9kaXY+CjxkaXYgZGlyPSJhdXRvIj5XaGlsZSByZWFkaW5nIHRoZSBE RUVSIGRyYWZ0LCBJIGhhZCB0aGUgdGhvdWdodCB0aGF0IGl0IG1heSBiZSBhIGdvb2QgaWRlYSB0 byBtYWtlIHVzZSBvZiBDQUEgcmVjb3JkcyBhIHJlY29tbWVuZGF0aW9uIGZvciBlbmNyeXB0ZWQt RE5TIGNlcnRpZmljYXRlcy4mbmJzcDsgSSBjYW4gc2VlIHBvdGVudGlhbCBpc3N1ZXMgd2l0aCBv cGVuIENBIGlzc3VlZCBjZXJ0aWZpY2F0ZXMuPC9kaXY+CjxkaXYgZGlyPSJhdXRvIj48YnI+Cjwv ZGl2Pgo8ZGl2IGRpcj0iYXV0byI+PGJyPgo8L2Rpdj4KPGRpdiBkaXI9ImF1dG8iPlRoYW5rcywm bmJzcDs8L2Rpdj4KPGRpdiBkaXI9ImF1dG8iPkpvaG48L2Rpdj4KPGRpdiBkaXI9ImF1dG8iPjxi cj4KPC9kaXY+CjwvZGl2PgoKCjwvZGl2Pi0tIDxicj4KQWRkIG1haWxpbmcgbGlzdDxicj4KPGEg aHJlZj0ibWFpbHRvOkFkZEBpZXRmLm9yZyI+QWRkQGlldGYub3JnPC9hPjxicj4KPGEgcmVsPSJu b3JlZmVycmVyIiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Fk ZCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hZGQ8L2E+PGJyPgo8L2Js b2NrcXVvdGU+PC9kaXY+PC9kaXY+PC9kaXY+CjwvYm9keT48L2h0bWw+ ----_com.samsung.android.email_829117631977690-- From nobody Thu Nov 19 01:02:34 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F8D3A1242 for ; Thu, 19 Nov 2020 01:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 YdhYT4CBkW4C for ; Thu, 19 Nov 2020 01:02:31 -0800 (PST) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 07CDA3A1238 for ; Thu, 19 Nov 2020 01:02:30 -0800 (PST) Received: by mail-wm1-x32d.google.com with SMTP id p22so6383058wmg.3 for ; Thu, 19 Nov 2020 01:02:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=grltLwmCKdXJErxlwJBdxGKIJ4kArCPkuanVgLAlj3g=; b=pgwKXmgeXu/vvN6pGTvK5wc09y9lCwbAgyaTj9g4amwgowz1PNFYA86FvH0tDf21PW swnpmNAE7zP7pDSfm3IvgpaE00QNb3pMPC/lpM7HI6UkITRxN/BQ70Akf9CdsODo9AtQ YwUpOvt1/6GriPwFnmwPnQVp1owowmzf7gsmD8MMBIVgCd6I2nWBTJOqEMGrLj6v9LFe YZvOCdqGAo7VZrmJU6ZTtYIymjsGLYx6hHmqr/GTCHssESxTF1WaW2n+erEYGMH6k9UY Wq8kdyl04FLt/exTIQM3K/qRL6wILdCphROEDGw3D8daUy46/lEgmOv7nC0nr5FVTd7i vgAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=grltLwmCKdXJErxlwJBdxGKIJ4kArCPkuanVgLAlj3g=; b=HZbjAk17fyB0IHtnupK2S5QbAzStfGrvTBgjLJ14fMhroLSuTVYk+yfPuUywNIIa+p qITXPNGWqFkwDKm+Uw4dRL587Kc1iWO17GuYA4e8nzXJqxGTza59aiZZMFRkHH3Jvc7s zFtE+cYlGRE7r9czb61sd02QuCnZxEppid03KBx/L8Iow4Btlvcv8JmNEzhMwrjl6IlL 4ByylsxWh9L7CEBEuuxTF6g5RW+s2PLJVnae8JQV9hJeLh+hjNffhMn/BF+G5xjKJAXg bknQVJe4L6AP25QIbM4bqfT9Fus0gdcJcJWGnqCdiiGLGCWANDlSJXxXPMiUMcGLfr8o M3jw== X-Gm-Message-State: AOAM533lyPjIrRXvXTOL8Z5do81kFpxzyB8NEhhCkszXv+924XI//Vhd VC1EfTVYcnu4ruGeH/iIOCKci06L8YIOY1EUYiXi5g== X-Google-Smtp-Source: ABdhPJys1g4f+uouNJg+Yc0SxchvOiTeJy9lUjaa+dMWyMgkNKO8mYNLJVhbgSnjbrbzgOK2brnf7yG+eKFWMbwnX+E= X-Received: by 2002:a1c:208f:: with SMTP id g137mr3349311wmg.116.1605776548880; Thu, 19 Nov 2020 01:02:28 -0800 (PST) MIME-Version: 1.0 References: <394A540C-81A8-4F86-8E62-FADC4A820D81@rfc1035.com> <20201116093136.GA21460@nic.fr> <680ed8e1-bdb9-4ed9-aa12-7c0efe2bb1da@www.fastmail.com> In-Reply-To: From: Eric Orth Date: Thu, 19 Nov 2020 04:02:18 -0500 Message-ID: To: Ben Schwartz Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000c966ef05b471fcb1" Archived-At: Subject: Re: [Add] equivalence definition X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 09:02:33 -0000 --000000000000c966ef05b471fcb1 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 17, 2020 at 4:24 PM Ben Schwartz wrote: > On Mon, Nov 16, 2020 at 4:02 PM Ben Schwartz wrote: > ... > >> I posit that any persistent attacker who can answer queries sent to >> server A is indistinguishable from server A. This suggests a possible >> solution to the local network use case: ask the client to regularly >> revalidate server A's intention to upgrade to server B, and stop using >> server B if server A stops recommending it. >> > > I've taken the liberty of turning this into a PR for DEER: > https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/pull/147. I > believe this solves the "85%" problem securely, assuming this security > model. > Wrote a comment in the PR, but more generally: I think there's an important distinction in this security model. An attacker is only indistinguishable from server A if it can answer *all* queries sent to server A. In the case of local forwarders, if only some queries are forwarded (due to e.g. filtering, local-only names, split horizon, etc) to server B, then relying on the ability for 1 name to indicate equivalence or acceptance of upgrade could result in server B receiving those names that previously would have only been sent to server A. This has issues both with user expectations and security. > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000c966ef05b471fcb1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 17, 2020 at 4:24 PM Ben S= chwartz <bemasc=3D40googl= e.com@dmarc.ietf.org> wrote:
On Mon, Nov 16, 2020 = at 4:02 PM Ben Schwartz <bemasc@google.com> wrote:
...
I posit that any persistent attacker who can answe= r queries sent to server A is indistinguishable from server A.=C2=A0 This s= uggests a possible solution to the local network use case: ask the client t= o regularly revalidate server A's intention to upgrade to server B, and= stop using server B if server A stops recommending it.

I've taken the liberty of turning this into a = PR for DEER:=C2=A0https://github.com/tfpauly/draft-= pauly-adaptive-dns-privacy/pull/147.=C2=A0 I believe this solves the &q= uot;85%" problem securely, assuming this security model.

Wrote a comment in the PR, but more ge= nerally:
I think there's an important distinction in this sec= urity model. An attacker is only indistinguishable from server A if it can = answer *all* queries sent to server A.=C2=A0 In the case of local forwarder= s, if only some queries are forwarded (due to e.g. filtering, local-only na= mes, split horizon, etc) to server B, then relying on the ability for 1 nam= e to indicate equivalence or acceptance of upgrade could result in server B= receiving those names that previously would have only been sent to server = A.=C2=A0 This has issues both with user expectations and security.
=C2=A0
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000c966ef05b471fcb1-- From nobody Thu Nov 19 06:34:59 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B98E3A03F2 for ; Thu, 19 Nov 2020 06:34:57 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 MK2DI5EtT4wC for ; Thu, 19 Nov 2020 06:34:55 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2C73A03F1 for ; Thu, 19 Nov 2020 06:34:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E9ECB389E2; Thu, 19 Nov 2020 09:35:52 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FPAf7rRFafaL; Thu, 19 Nov 2020 09:35:51 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 82A41389E1; Thu, 19 Nov 2020 09:35:51 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C3DC4926; Thu, 19 Nov 2020 09:34:51 -0500 (EST) From: Michael Richardson To: Ray Bellis cc: "add\@ietf.org" In-Reply-To: <8c3c0645-91d5-9631-3277-923c58846a91@bellis.me.uk> References: <8c3c0645-91d5-9631-3277-923c58846a91@bellis.me.uk> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Add] DEER and CPE resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 14:34:58 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ray Bellis wrote: > You may find some useful background here. > I did a lot of research into the behaviour of CPE "resolvers" back in > 2008 or so, which led to RFC 5625 and SSAC035. That's a long time ago, even by trailing-edge shippers of openwrt. I wonder if we redo your survey using Atlas probes: I worry that in most cases the probes are self-selected into homes of clueful people though. > Many of the CPE resolvers are just dumb forwarders little better than= an > AGL. Most don't even support DNS over TCP, and they often have > significant other flaws in their DNS compatibility (e.g. no support f= or > EDNS). dnsmasq of 2020 (or even 2015) is much better. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+2gosACgkQgItw+93Q 3WUjoAgAg4yIgjzSni7LlQ3QwLsAZ3z7kkBhGFlTReg+GKUismcliz9P7jRPmEHm KiBZ45vVaFrlpitjzN7hHX5VFPXagxTYMq8dJbc7OWhbAgJE23spGyieTchOJSR1 TXjDRk0nvct8/9yw/VU3hzlCuxyQgtYrGxPQ8LyPUioeO6oFUUSezKw311EgUKbo jlk0Z3paJVbzYZTzlkIPftkS4y/UXLJVifPflCukhQaI0uNnszQ5V0yoOnxkK5Vh a6IP7nenuIeWhLo9ADvGF7WSQQhi1TJPuDTD3Z47GEz/qNfE+6ltz9FYKhQYwrNG coPsJpTwidaMq7vbixgadtflw+VjSw== =c+YJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 19 08:26:47 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB003A08D4 for ; Thu, 19 Nov 2020 08:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ynBGP9tNQW6q for ; Thu, 19 Nov 2020 08:26:45 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 15DE53A08AF for ; Thu, 19 Nov 2020 08:26:45 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id u21so6686846iol.12 for ; Thu, 19 Nov 2020 08:26:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+wy11aSAjawAGFDWbEkH6SEagS1SD2b4x+7irQTxQbs=; b=MmTGDohSXSrCedj4ZOmQaLevL9MoJa6kzl+qYOvgTJmaYet/hZ+W/9rP5LLfIfs2e0 XVdG6WnLE00hlRLI0DECsv/Hev0SoQPv68rqWAr6Bk/Xu51C12Wz2jruhoYC/Tw63C6D QmwXUF2TnvbFTG0vtwV9ums7yZfrHaEdbYZ4xNu3Wgpxl2u+SBOB9I9urquCEPms2Xak 2KmuXRF4vnpaUIayKErYKf79ywDRY8wSqpbPup+np4ybYfdoWPoJqAU95Ehdm3SEgFgr BjghGD8miUEI+67EBWegelsvVzjwdn05dckQmzAEZ0m0DdQzHsExMUo/g/QSVWDwyqjh 82CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+wy11aSAjawAGFDWbEkH6SEagS1SD2b4x+7irQTxQbs=; b=kNcQZfDBSm0iMzWxHNS90FEw6J3z1aaRSp5G3HIubD3iCrnjJ0ApEaFdXQg7X0qkOv mMNiLcEt35WqRXY15jcgCZxlmTZElbiuxuzT+Zt9xKkWTmpfyk50WHjed3Shzyv11Siw 7ovVmcpPiTFi7o3RPzSZNgNzKny46ir+eoCQ2zWQ/+usFg5hVGPx7Nvrha25OyOOhF2e OOGMrFmMbXzusbu2Wjh2zCckPGetS8SXHsJKSKH5dJ4kvQAMq7eQJer79hvyO+67hKul P3/JaHtLIa2cDrf6CEu/hjW+wiZlOvf0Smz/NdpWq+ULgJt07QVUHiOhNrNqRtWdHU5e ImVg== X-Gm-Message-State: AOAM530s09dEPyzE/+ZCvjA6XN5cj2u1g5ii42ma/utbZjndpSds6E4F uGsH+n1Cczv09e/njIrQlxg/jn4uNGH1k4M/4cBz2g== X-Google-Smtp-Source: ABdhPJw3pVSGrkf4wp0j+XXWz3iczoBnlQZ8AcdIOdhS8O4qWyt0BMncNtvB0Oxiivu5P/EdTCHUo2lTrbXvom0TaBk= X-Received: by 2002:a05:6638:451:: with SMTP id r17mr15281135jap.8.1605803203899; Thu, 19 Nov 2020 08:26:43 -0800 (PST) MIME-Version: 1.0 References: <394A540C-81A8-4F86-8E62-FADC4A820D81@rfc1035.com> <20201116093136.GA21460@nic.fr> <680ed8e1-bdb9-4ed9-aa12-7c0efe2bb1da@www.fastmail.com> In-Reply-To: From: Ben Schwartz Date: Thu, 19 Nov 2020 11:26:32 -0500 Message-ID: To: Eric Orth Cc: ADD Mailing list Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000940b9605b4783149" Archived-At: Subject: Re: [Add] equivalence definition X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 16:26:47 -0000 --000000000000940b9605b4783149 Content-Type: multipart/alternative; boundary="0000000000008c989005b47831fe" --0000000000008c989005b47831fe Content-Type: text/plain; charset="UTF-8" On Thu, Nov 19, 2020 at 4:02 AM Eric Orth wrote: > > > On Tue, Nov 17, 2020 at 4:24 PM Ben Schwartz 40google.com@dmarc.ietf.org> wrote: > >> On Mon, Nov 16, 2020 at 4:02 PM Ben Schwartz wrote: >> ... >> >>> I posit that any persistent attacker who can answer queries sent to >>> server A is indistinguishable from server A. This suggests a possible >>> solution to the local network use case: ask the client to regularly >>> revalidate server A's intention to upgrade to server B, and stop using >>> server B if server A stops recommending it. >>> >> >> I've taken the liberty of turning this into a PR for DEER: >> https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/pull/147. I >> believe this solves the "85%" problem securely, assuming this security >> model. >> > > Wrote a comment in the PR, but more generally: > I think there's an important distinction in this security model. An > attacker is only indistinguishable from server A if it can answer *all* > queries sent to server A. > Yes, I meant to describe the behavior of an attacker in the local network, between the client and the Unencrypted Resolver. > In the case of local forwarders, if only some queries are forwarded (due > to e.g. filtering, local-only names, split horizon, etc) to server B, then > relying on the ability for 1 name to indicate equivalence or acceptance of > upgrade could result in server B receiving those names that previously > would have only been sent to server A. This has issues both with user > expectations and security. > I think this is an important point and worthy of discussion. As I noted in the PR, the behavior I'm describing would be similar to Mozilla's canary domain ("use-application-dns.net"). With over two years' deployment experience, I think it's clear that the canary domain approach has been working well, and represents our best path forward. One subtlety about the canary domain is that Mozilla has also implemented fallback-on-NXDOMAIN, which provides seamless support for non-canary-aware split-horizon forwarders. We could employ the same approach here, if we think that the compatibility benefits outweigh the privacy loss. Forwarders that want to prevent queries from leaking upstream just have to block the canary domain. We can provide plenty of lead time to allow those updates to happen before clients are deployed. --0000000000008c989005b47831fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Nov 19, 2020 at 4:02 AM Eric = Orth <ericorth=3D40google= .com@dmarc.ietf.org> wrote:


On Tue, Nov 17, 20= 20 at 4:24 PM Ben Schwartz <bemasc=3D40google.com@dmarc.ietf.org> wrote:
<= div dir=3D"ltr">On Mon, Nov 16, 2020 at 4:02 PM Ben Schwartz <bemasc@google.com> wrot= e:
...
I posit that = any persistent attacker who can answer queries sent to server A is indistin= guishable from server A.=C2=A0 This suggests a possible solution to the loc= al network use case: ask the client to regularly revalidate server A's = intention to upgrade to server B, and stop using server B if server A stops= recommending it.




I think= this is an important point and worthy of discussion.=C2=A0 As I noted in t= he PR, the behavior I'm describing would be similar to Mozilla's ca= nary domain ("use-applicati= on-dns.net").=C2=A0 With over two years' deployment experience= , I think it's clear that the canary domain approach has been working w= ell, and represents our best path forward.

One sub= tlety about the canary domain is that Mozilla has also implemented fallback= -on-NXDOMAIN, which provides seamless support for non-canary-aware split-ho= rizon forwarders.=C2=A0 We could employ the same approach here, if we think= that the compatibility benefits outweigh the privacy loss.

<= /div>
Forwarders that want to prevent queries from leaking upstream jus= t have to block the canary domain.=C2=A0 We can provide plenty of lead time= to allow those updates to happen before clients are deployed.
<= /div> --0000000000008c989005b47831fe-- --000000000000940b9605b4783149 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPmAYJKoZIhvcNAQcCoIIPiTCCD4UCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggzyMIIEtjCCA56gAwIBAgIQeAMYYHb81ngUVR0WyMTzqzANBgkqhkiG9w0BAQsFADBMMSAwHgYD VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE AxMKR2xvYmFsU2lnbjAeFw0yMDA3MjgwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFQxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFz IFIzIFNNSU1FIENBIDIwMjAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvLe9xPU9W dpiHLAvX7kFnaFZPuJLey7LYaMO8P/xSngB9IN73mVc7YiLov12Fekdtn5kL8PjmDBEvTYmWsuQS 6VBo3vdlqqXZ0M9eMkjcKqijrmDRleudEoPDzTumwQ18VB/3I+vbN039HIaRQ5x+NHGiPHVfk6Rx c6KAbYceyeqqfuJEcq23vhTdium/Bf5hHqYUhuJwnBQ+dAUcFndUKMJrth6lHeoifkbw2bv81zxJ I9cvIy516+oUekqiSFGfzAqByv41OrgLV4fLGCDH3yRh1tj7EtV3l2TngqtrDLUs5R+sWIItPa/4 AJXB1Q3nGNl2tNjVpcSn0uJ7aFPbAgMBAAGjggGKMIIBhjAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHzM CmjXouseLHIb0c1dlW+N+/JjMB8GA1UdIwQYMBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MHsGCCsG AQUFBwEBBG8wbTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3Ry MzA7BggrBgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvcm9vdC1y My5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIz LmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5n bG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEANyYcO+9JZYyqQt41 TMwvFWAw3vLoLOQIfIn48/yea/ekOcParTb0mbhsvVSZ6sGn+txYAZb33wIb1f4wK4xQ7+RUYBfI TuTPL7olF9hDpojC2F6Eu8nuEf1XD9qNI8zFd4kfjg4rb+AME0L81WaCL/WhP2kDCnRU4jm6TryB CHhZqtxkIvXGPGHjwJJazJBnX5NayIce4fGuUEJ7HkuCthVZ3Rws0UyHSAXesT/0tXATND4mNr1X El6adiSQy619ybVERnRi5aDe1PTwE+qNiotEEaeujz1a/+yYaaTY+k+qJcVxi7tbyQ0hi0UB3myM A/z2HmGEwO8hx7hDjKmKbDCCA18wggJHoAMCAQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUA MEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWdu MRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEg MB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzAR BgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4 Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuu l9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJ pij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh 6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti +w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEA S0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9u bG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaM ld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88 q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/f hO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBNEwggO5oAMCAQICEAE/JGAv3XK3SRaKvGds QSwwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gQXRsYXMgUjMgU01JTUUgQ0EgMjAyMDAeFw0yMDA5MDgy MzQzNTNaFw0yMTAzMDcyMzQzNTNaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFzY0Bnb29nbGUuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7rjWsiqQSnXGFTvs/2JDygQFtWsgF+Ce W2I/wmwCuWH2eNUBYslyudWmJsUMi7IbeSsKHrvBI2P7k6sk5p6o3uFlomiFaDMqXcn76t5GNGym CmHm5KBWxc3LfyvR4C2/wg9oUwbL2xxXc6QQpWWE4ONn9NMHwNC396Ih5u7tcrH5eF49HbVarP5i TindWAOzz++JA3VC/1lIkqWvOt2BcBtxQDUnYp8sr8UnMF/6UqtCd0aHJnKkvYi4o8Qo5Qf3YgiJ DzADzBTf54o3NAI3hiIVKPvz1l0g78IcR29Bt9jUrE33qGzGB6HoY7Z8quhA/ngW2XjuLkIY1ZKX AwTXBQIDAQABo4IBzzCCAcswHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5jb20wDgYDVR0PAQH/ BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUu687mSaB85ui VgNNFSUhtTljkxEwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYmaHR0cHM6 Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wCQYDVR0TBAIwADCBmgYIKwYBBQUHAQEE gY0wgYowPgYIKwYBBQUHMAGGMmh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL2NhL2dzYXRsYXNy M3NtaW1lY2EyMDIwMEgGCCsGAQUFBzAChjxodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2Nh Y2VydC9nc2F0bGFzcjNzbWltZWNhMjAyMC5jcnQwHwYDVR0jBBgwFoAUfMwKaNei6x4schvRzV2V b4378mMwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9jYS9nc2F0 bGFzcjNzbWltZWNhMjAyMC5jcmwwDQYJKoZIhvcNAQELBQADggEBAG9R1/y5PatVOc8xLrAmGgNO /Q4+lbJuHNwX3aIpOkM72Ot4r6r5/IFOSx1pMpmzvrECyy5YQzUGkHV4atuNq5YPPNMGa+XlaKSg oU2dA6RCD40dtwmrPxrKiGAfHPNvfmRvgnx9qxBKFPbKF/Tn8BwKSZCSvx33TnQRfqLUTcgrAarQ dF9Oc45moJrn4nVF0VTTPI6LVminvjg3tLgF2bny1N6CitQnb1t67vpYjeNpcXNIGQzEDaYI3WnK rVeZMcLSY+Z2dQH8HvVsA95vFCTywgiWKq5KxFqz/GdB6JhDWcIJIKCJVUyqD/Bjx47+e4Ye/FuD NDSYc+613Ozl3TkxggJqMIICZgIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFzIFIzIFNNSU1FIENBIDIwMjACEAE/ JGAv3XK3SRaKvGdsQSwwDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIIk169aAXQYS /x0S/G+cl3mompv8HdbYT5tc93rbOblYMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTIwMTExOTE2MjY0NFowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJ YIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcN AQEHMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQAZLzOn/OWo92Xd1LI6uprYZwzfaaL0 o7UKQ7liUE3+UfbXe6NF15yPAx7s36bNZ96DC9Yx6OvAm5xvQqhTEse8/cs/NlmOPyeo7D4E0Ne+ psy15otTGZrUiduE/zYAE2pzCsP3FUJuh8hRWeX/yI7Wt0+XbKbYOr/EZ9yaNanzYxbGKGwwaFk6 fL6q3VWajcYBjCpn0gpJK+LbWqRQF8Jp2CLxDG394dV9PwW2mKCQza5dMWhSxngSUWY1yAi9S1w1 1x+iSjuxckcSXjHj7lX5AECKr9u/dvrzhZmHrhpCwbHCv/cmLSjd0//SgzkOU/4rjDGOCvzzM4v+ 8ut4e4MK --000000000000940b9605b4783149-- From nobody Thu Nov 19 08:30:31 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DD53A0942 for ; Thu, 19 Nov 2020 08:30:30 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=portfast.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 Hqyy8JfjNYNI for ; Thu, 19 Nov 2020 08:30:28 -0800 (PST) Received: from mail.portfast.net (mail.portfast.net [IPv6:2a03:9800:20:1::2]) (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 595393A0937 for ; Thu, 19 Nov 2020 08:30:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=portfast.net; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=sPaYUhTjWklI54GID8vkJuZr+fg0NjhA6DcuG9Z9HG4=; b=iyxBMfLAV0WD7q7YZGhhSISBdc vKoxjQYV5c7uYvtrGTtkFZ+v/tLQVx5j36NkDnOfxI5hPMvIcwmosk1kPqlM5oR5s6p/zCMpqBJtm L4vFQ80UEqNL9X4tgd1epykkOqZ+H0aM6mEdRt091u7HhjrpGCqNGYh6sDMMbtU5BLT8=; Received: from [216.213.177.102] (port=53439 helo=Rays-MacBook-Pro.local) by mail.portfast.net ([188.246.200.9]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1kfmpE-0001XF-Ow (Exim 4.89) (return-path ); Thu, 19 Nov 2020 16:30:24 +0000 To: Michael Richardson Cc: "add@ietf.org" References: <8c3c0645-91d5-9631-3277-923c58846a91@bellis.me.uk> <7292.1605796491@localhost> From: Ray Bellis Message-ID: <3b8912cb-e39a-4504-7b85-426f1185ed8f@bellis.me.uk> Date: Thu, 19 Nov 2020 16:30:24 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <7292.1605796491@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Add] DEER and CPE resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 16:30:30 -0000 On 19/11/2020 14:34, Michael Richardson wrote: > That's a long time ago, even by trailing-edge shippers of openwrt. Yes, it was a long time ago, but routers don't get replaced very often. In any event, it was the systems running bespoke embedded OS's that were the biggest problem. I didn't test OpenWRT but I expect it would have faired pretty well. > I wonder if we redo your survey using Atlas probes: I worry that in most > cases the probes are self-selected into homes of clueful people though. Without being able to automatically detect the model of CPE it's probably not so useful. The "dig" commands we used are all in the SAC035 paper, though, should anyone want to try to replicate the tests. > dnsmasq of 2020 (or even 2015) is much better. Even in 2008 dnsmasq coped somewhat better than those CPEs running non-Linux kernels. Unlike many other CPE DNS stacks dnsmasq is at least a proper DNS forwarder, rather than a dumb ALG-like UDP proxy. The author also responded quickly to those flaws I did find. Ray From nobody Thu Nov 19 18:57:28 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F423A16FE; Thu, 19 Nov 2020 18:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 ceKGh5lbpPNY; Thu, 19 Nov 2020 18:57:24 -0800 (PST) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (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 93E613A16FB; Thu, 19 Nov 2020 18:57:24 -0800 (PST) Received: from pps.filterd (m0156893.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0AK2i2xZ007735; Thu, 19 Nov 2020 21:57:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=20190412; bh=dkheaGAlInhHHmp3lzBKlGEuWbVsdyBjkx1hHG5yLP0=; b=DyLnlMhy+oiGlSsy+1sL4pVdwt2vuOw/2fANenYgROprdeSU+uioc5Ii/3wcmFQe6D0P 99PYX19VNY/CSRc9lOUrm4iwXD5KKnJWvc3QQHcYb4QhIq8UbjZQ1ugIsGLbskOgqC5T azYwiDIKS7VnrMIcRgV1jhHHuOKT1Y+aWU8RoQ53qxMcQgsBXmIWQktxqa5riGU73gzl rE4B4UPJskNnbQeCPv+te8DNE/ytrjMnRgi7wu/bJ/oJmnNb+GXawyYzjwsThAa8dNif GPGzWcnr+lDN1eM7XZ9gHdHlr6gLOePrBA4zhYqJcGqoZK+mV38cpK1IkiCAQUTrtmdg vg== Received: from pacdcex44.cable.comcast.com (dlppfpt-wc-1p.slb.comcast.com [96.99.226.136]) by mx0a-00143702.pphosted.com with ESMTP id 34wvtxujee-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 19 Nov 2020 21:57:24 -0500 Received: from PACDCEX46.cable.comcast.com (24.40.2.145) by PACDCEX44.cable.comcast.com (24.40.2.143) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 19 Nov 2020 21:57:21 -0500 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX46.cable.comcast.com (24.40.2.145) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 19 Nov 2020 21:57:21 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.174) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 19 Nov 2020 21:57:21 -0500 Received: from BYAPR11MB3111.namprd11.prod.outlook.com (2603:10b6:a03:90::25) by SJ0PR11MB4960.namprd11.prod.outlook.com (2603:10b6:a03:2ac::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.22; Fri, 20 Nov 2020 02:57:19 +0000 Received: from BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::dc3e:675f:6772:c9e]) by BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::dc3e:675f:6772:c9e%6]) with mapi id 15.20.3589.022; Fri, 20 Nov 2020 02:57:19 +0000 From: "Deen, Glenn" To: ADD Mailing list CC: "add-chairs@ietf.org" Thread-Topic: ADD@ IETF109 Session 2 Thread-Index: AQHWvujcCokzSCy+D0W7aHi7MTeFUQ== Date: Fri, 20 Nov 2020 02:57:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2605:e000:141b:121:d921:fba:c2bf:f7f3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a96396c5-ad1c-4bd3-c9a5-08d88cffff1d x-ms-traffictypediagnostic: SJ0PR11MB4960: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jioC8fE0H5T3EyolwKtrxIpcbHjylCtgfwYWqXHeR3Wg+Y94HoojFk8vvzKC++2Zs/QFXikQeSB3pKfAveIbObiNUkBIjtV22VAvJ643bqk6xJBnbDbMnWjbSMTcdLWWTfHqTXfz1u7aQ4bKsPMs3PCUMOCmCDHTsnc1lHGM1uH0ONbQjH6dnWY84YyIA1vN3SYoIzBI4pQ9cmTxWHnMOdHNvWNbXnz2eOOEybXqxdx+YqJNwN9jfHU988sZn9uo/f6+Lqp8WZkVmhOIJF/7uXAwbY62YVTPsY4Q/SqJLbJf+2ZJuV7neP3dSnK+1QHCNfAdwjEzu89pBSjUCXQ/NA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3111.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(136003)(376002)(396003)(39860400002)(366004)(6916009)(71200400001)(8676002)(6486002)(64756008)(66556008)(66446008)(5660300002)(36756003)(450100002)(4326008)(76116006)(66476007)(66946007)(86362001)(2906002)(83380400001)(478600001)(6512007)(2616005)(9326002)(8936002)(33656002)(4744005)(316002)(186003)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: c+Frum0/MLXlvsBY/X+HPISxf92PPCAhvKjhP0rE5u2d7RisnhRS4lD1AcTOzPDDTwGTdgnfY6KynUOK9OGbUlx0HQ20G8DVxPtsNxTCGYBDljfP2+30KmOil+SkjlAsO5cB9OcZDhCcmwOPWl6bt/jdVZtWkm/QTfTPDK6FdTH5V1/PqyatPKPjEilWpvkv1JdOKeNasR9BnYsmLYcNgosjllclkgJ9rWgOs6OAt/+KIz2eFfBuUOjX8TLyqGhshcEOlt/30BSG5/wSBoY/qIGivFS7bjo1+aDDZFDlOnmdarYhHPdmtz1h0QN/C7rEYmM9aic20OB2M+r/RV1GJQ5qxiuv9ZabcDKDTB2BoU/SvgdUhg46gCBbZiEKrF7eBohElZI+3sKbWyCz/BctH06nup81/hwQzAhBOqgmtmUwemqDRse1Az5K9SJRYz4KPk1xxLj8YiSX02vs2xB0HLPppA0WsEk6tWfIGbKyl74Dt0BaNj7zRaUKNOBVm8ArjDaIt1B9gyPa/Vj7Go69UEuCqRqsbFray/4PZfIvDybcjslf1xGZ1LTZW4QNsC2JLsFMargj6T1OoGAwipnwFnFTyT6fnXkgEuy3/XUQRIJMPo9JHRoP8bKzNc1h0QwDmw/sPf6OFseWPNDQ5YUvTrxIRDYF8dvHMUmr2BW0N783WEWRUDO6LgG7m1OEtnACkBs/bRBVOB50NZ+D2GsTxLAtLVWj+TYFhzUyPcWH6TBOuupcydCrHQL/MMBjENNBUA/VmAp0fxWMx9oQN6otN92cjhXe52+doddjjSNrjmDTQ24Ep2nsOJdCBBA3lFuD/LBf98NB7ZO6S4KR3VV/N55vTyS6Gd4lpZV3lk2pjgcIsSd/eAnMdzrB7NlGdjxBtHSwQV6poLvPudz0hHk5+kTfB6m+xARsUyXlK/ypW7yjHv0oIG8UUYlx7IuZwhohXNQRfFbh5yugrmGBA0tjXw== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GxWY7hVgvRKaOqOiBykZ/422cG8YMhWBaTdsJV4d91ILPJlvYiCWEQvbY1vX6ZdBUMlKutVwGuSIdWBOwYl9918zF3U944aIBw4PWYMAxr/ezqU4dD4WIC8nR3lMwV+mjc85X528En90auSyrlXP3YB7qOyemVPt0PtfwwmvcNlBkExeMZYRqq+CiOoGUfYLWpnvsHR2w5pfnr5djFnWSoxeHLdUxP1xAL7DQFPwiw/j+Y1qji9H3OwtPc6HAT4lo0gdJZ4Y8c6LUVCgmF8ovEs3MfnkHqU5g5AIN2P1kcfzlUMIQ19g0R8j59mHdofgZY5t3FTuIrDA7zdHj9iVhQ== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Jk5p2tBkowyy25kL1i652n7b89mDtXaj9qij8dQdMtQ=; b=fmxvcPuwRm8oDdhhjbrMTwMO8yAlYOBqMHf+xEJkLvn5GNHXODPRcAf2pqYp0mJFgsq3kQ4GAld1N5aCb13qKZ2iDREpFWHE6uX+ygc6gFe13x8hBQrfyDV1csZTYZh/SnSjJ3/Vc0cxwsNsRCnLsmmHB0xFGC74KpouFOsoXQ4SPBr44bjXXL4VXiUS/TnOJzrK1evZJ5mpOIR6s/p8wYi3hGo2sH360yDXXOPJyqlYOCP2kKXcgmoiTwvMNou4mdS9UFtabVrZIEv3kSWz0UsjQif8wfSZB7RuqCOzdP9aFFkfogBYIIkjPhByb3O2MhP7Nvrt25r9VCgG+bjcQg== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: BYAPR11MB3111.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: a96396c5-ad1c-4bd3-c9a5-08d88cffff1d x-ms-exchange-crosstenant-originalarrivaltime: 20 Nov 2020 02:57:19.6397 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: t/jZT4aNNBHURzb1HgsoX+ieD2rA75DqQQ0snZgfZFX6VjDbUYAtOhL0wrxCMRew3SdGtZABqEuA9xGG228kQ9PajOrirEBf6Rbd7/r6lTw= x-ms-exchange-transport-crosstenantheadersstamped: SJ0PR11MB4960 x-originatororg: comcast.com Content-Type: multipart/alternative; boundary="_000_A80A12C8BA9C4777963C211539F89986comcastcom_" MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWZ X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-19_14:2020-11-19, 2020-11-19 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [Add] ADD@ IETF109 Session 2 X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 02:57:26 -0000 --_000_A80A12C8BA9C4777963C211539F89986comcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRXZlcnlvbmUsDQoNCkEgcmVtaW5kZXIgdGhhdCB3ZSBoYXZlIG91ciBBREQgU2Vzc2lvbiAy IGluIGEgY291cGxlIGhvdXJzLiAgICBXZeKAmWxsIHBpY2sgdXAgdGhlIGRpc2N1c3Npb24gb24g RXF1aXZhbGVudCBSZXNvbHZlcnMsICBhbmQgdGhlbiBpZiB0aW1lIHBlcm1pdHMgaGF2ZSBhIGRp c2N1c3Npb24gb24gSVAgQWRkcmVzc2VzIGluIENlcnRpZmljYXRlcy4gICAgICBGaW5hbGx5LCB3 ZeKAmWxsIGhhdmUgc2hvcnQgZGlzY3Vzc2lvbiBvbiBzaG91bGQgd2UgcGxhbiBmb3IgYW4gSW50 ZXJpbSBtZWV0aW5nIGluIGxhdGUgSmFudWFyeSBvciBlYXJseSBGZWJydWFyeSBhaGVhZCBvZiBJ RVRGMTEwLg0KDQpIZXJlJ3MgdGhlIHRpbWUgc2xvdCBpbiB2YXJpb3VzIHpvbmVzLg0KDQojIyMg U2Vzc2lvbiAyOiBGcmlkYXksIE5vdmVtYmVyIDIwLCAyMDIwIChVVEMrNykNClRpbWUgaW4gZGlm ZmVyZW50IHpvbmVzOg0KKiBJQ1Q6IDEyOjAwLTE0OjAwIChVVEMrNykgSUVURiBBZ2VuZGEgVFog YW5kIEJhbmdrb2sgbWVldGluZyAibG9jYXRpb24iIHRpbWUNCiogSVNUOiAxMDozMC0xMjozMCAo VVRDKzUuNSkNCiogQ0VUOiAwNjowMC0wODowMCAoVVRDKzEpDQoqIFVUQzogMDU6MDAtMDc6MDAg KFVUQyswKQ0KKiBFU1Q6IDAwOjAwLTAyOjAwIChVVEMtNSkgICpOb3RlOiBUaGlzIGlzIE1pZG5p Z2h0IFRodXJzZGF5IGludG8gRnJpZGF5IGluIEVTVCoNCiogUFNUOiAyMTowMC0yMzowMCAoVVRD LTgpICAqTm90ZTogVGhpcyBpcyBUaHVyc2RheSBOb3ZlbWJlciAxOSBpbiBQU1QqDQoNClJlZ2Fy ZHMNCkdsZW5uIERlZW4NCg0K --_000_A80A12C8BA9C4777963C211539F89986comcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: <711D70FD72E03444847F74C69335CB0C@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiBcKEJvZHkgQ1NcKSI7DQoJcGFub3NlLTE6MiAyIDYgMyA1 IDQgNSAyIDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJQVCBNb25vIjsNCglwYW5v c2UtMToyIDYgNSA5IDIgMiA1IDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkhlbHZldGljYTsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1h bDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFwOmJyZWFr LXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+SGkg RXZlcnlvbmUsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPkEgcmVtaW5kZXIgdGhhdCB3 ZSBoYXZlIG91ciBBREQgU2Vzc2lvbiAyIGluIGEgY291cGxlIGhvdXJzLiZuYnNwOyZuYnNwOyZu YnNwOyBXZeKAmWxsIHBpY2sgdXAgdGhlIGRpc2N1c3Npb24gb24gRXF1aXZhbGVudCBSZXNvbHZl cnMsJm5ic3A7IGFuZCB0aGVuIGlmIHRpbWUgcGVybWl0cyBoYXZlIGEgZGlzY3Vzc2lvbiBvbiBJ UCBBZGRyZXNzZXMgaW4gQ2VydGlmaWNhdGVzLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KIEZpbmFsbHksIHdl4oCZbGwgaGF2ZSBzaG9ydCBkaXNjdXNzaW9uIG9uIHNob3VsZCB3ZSBw bGFuIGZvciBhbiBJbnRlcmltIG1lZXRpbmcgaW4gbGF0ZSBKYW51YXJ5IG9yIGVhcmx5IEZlYnJ1 YXJ5IGFoZWFkIG9mIElFVEYxMTAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0 aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPkhlcmUn cyB0aGUgdGltZSBzbG90IGluIHZhcmlvdXMgem9uZXMuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjti b3JkZXI6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjguMHB0IDguMHB0IDguMHB0IDguMHB0 O2JhY2tncm91bmQ6I0ZGRkRGNSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9y ZGVyOm5vbmU7cGFkZGluZzowaW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+IyMjIFNlc3Npb24gMjog RnJpZGF5LCBOb3ZlbWJlciAyMCwgMjAyMCAoVVRDJiM0Mzs3KTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tn cm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBp biI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBN b25vJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaW1lIGluIGRpZmZlcmVudCB6b25lczo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3 LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7 cGFkZGluZzowaW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+KiBJQ1Q6IDEyOjAwLTE0OjAwIChVVEMm IzQzOzcpIElFVEYgQWdlbmRhIFRaIGFuZCBCYW5na29rIG1lZXRpbmcgJnF1b3Q7bG9jYXRpb24m cXVvdDsgdGltZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJy ZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4qIElT VDogMTA6MzAtMTI6MzAgKFVUQyYjNDM7NS41KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZG RkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7 O2NvbG9yOmJsYWNrIj4qIENFVDogMDY6MDAtMDg6MDAgKFVUQyYjNDM7MSk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3Ljlw dDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFk ZGluZzowaW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+KiBVVEM6IDA1OjAwLTA3OjAwIChVVEMmIzQz OzApPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxs O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDs7Y29sb3I6YmxhY2siPiogRVNUOiAwMDow MC0wMjowMCAoVVRDLTUpJm5ic3A7ICpOb3RlOiBUaGlzIGlzIE1pZG5pZ2h0IFRodXJzZGF5IGlu dG8gRnJpZGF5IGluIEVTVCo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1i cmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFj ayI+KiBQU1Q6IDIxOjAwLTIzOjAwIChVVEMtOCkmbmJzcDsgKk5vdGU6IFRoaXMgaXMgVGh1cnNk YXkgTm92ZW1iZXIgMTkgaW4gUFNUKjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+UmVnYXJkczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+R2xlbm4gRGVlbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A80A12C8BA9C4777963C211539F89986comcastcom_-- From nobody Thu Nov 19 19:15:56 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7414D3A1727; Thu, 19 Nov 2020 19:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 KU4pl6M9Z0_7; Thu, 19 Nov 2020 19:15:50 -0800 (PST) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (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 5BEC33A171D; Thu, 19 Nov 2020 19:15:50 -0800 (PST) Received: from pps.filterd (m0156892.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0AK38qND016740; Thu, 19 Nov 2020 22:15:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=20190412; bh=ZB8jDb8QxCo1+xbAqmhefQqtfFxhyPIhsNNTx269elQ=; b=HYX5rIQCjeYZeWXIqDGY6wkN/SXQGYcc4ZyIewgU4f+Bb0MeAH0oKHsJiWyPq77Gla73 1m0PJgRK/HY/7l39Qepo8XP3ekIj9f2GE6WpEl/w8sGKu4w2UvkkIH9AsCbq/qnYcCav S/B1RX9rRwu53kglvvDixzhr1A7/c3tKY0Fdpqih33L2FCdTUzH57v7I/CAYx9gb2ke7 QhGidfrKP8SNjx9NJ8c0YJ/1jXLmNV/xdH4NWmjfBMp0v1xMPhh/2/LwmK3fVRys7vul yu9OKMvDghOpdUMep+fiSVzV/ft3NBrAOcpdtJXfhTD3vEuw0bf56HQMJtDLxx2jiy9b KA== Received: from pacdcex53.cable.comcast.com (dlppfpt-wc-1p.slb.comcast.com [96.99.226.136]) by mx0a-00143702.pphosted.com with ESMTP id 34wwtbu31q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 19 Nov 2020 22:15:49 -0500 Received: from PACDCEX55.cable.comcast.com (24.40.2.154) by PACDCEX53.cable.comcast.com (24.40.2.152) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 19 Nov 2020 22:15:48 -0500 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX55.cable.comcast.com (24.40.2.154) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 19 Nov 2020 22:15:48 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.49) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 19 Nov 2020 22:15:48 -0500 Received: from BYAPR11MB3111.namprd11.prod.outlook.com (2603:10b6:a03:90::25) by BYAPR11MB3621.namprd11.prod.outlook.com (2603:10b6:a03:fc::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.25; Fri, 20 Nov 2020 03:15:44 +0000 Received: from BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::dc3e:675f:6772:c9e]) by BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::dc3e:675f:6772:c9e%6]) with mapi id 15.20.3589.022; Fri, 20 Nov 2020 03:15:44 +0000 From: "Deen, Glenn" To: ADD Mailing list CC: "add-chairs@ietf.org" Thread-Topic: Scribes needed for ADD Session 2 Thread-Index: AQHWvutu6YSQxyCu0U+iHrAuSclc0g== Date: Fri, 20 Nov 2020 03:15:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2605:e000:141b:121:d921:fba:c2bf:f7f3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5b8d8f30-249e-4b0f-4d2a-08d88d029156 x-ms-traffictypediagnostic: BYAPR11MB3621: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NOV4vi9WEjvVn8g+MtGFSPffYxJDYHep+DYtEqtyqgBE+GfxhqOo1n9YBjkJOE9ISU70Fq1JC99ZOxmrxsH8l+xc6eiyPSn/odcoXST5iR3Yfnzta/57VLy6L+ulPmGx35TMF38FI5RY83Ik2uvPyI/WbAaOYHpbJRADCJLYwA9hn5FUCzL0FSAq6DjIz8PMYVjszzwkxNZOpckuMpQAa/2ICm5452fFYHXLLpiWX/ZbriCDmkSEysEeTzuRy+Px64tKNn6bHKkBrSANXIBtIz5trVq9DUYntniqccQX2o7t94Ns0G8yaoO8shnamgapjt65Idn5atzhbZ5gl2bHwg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3111.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(39860400002)(366004)(136003)(396003)(346002)(558084003)(66946007)(36756003)(66476007)(5660300002)(66556008)(66446008)(4326008)(450100002)(71200400001)(6916009)(86362001)(478600001)(186003)(9326002)(33656002)(64756008)(8676002)(6512007)(8936002)(2906002)(2616005)(6506007)(76116006)(6486002)(316002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: c/O3CzV+9PFSVKciISdxQ2WiJwDmvu5QMrxZt2drKmqbGobq781gQz+sCRLPs0oCB1ZvpyKU6riCvv4Xk9tMe43cDiZ4/GnyYln7iPNPhkbWztD+nFuLM7uBh+0ArA90kbBiqveCoVrXwtsDS7t2LiA7XYWIExcKqtNCyHrxoTcX45Q/PPXaqksNzl1pYwRDy9lDWpJxHg9AevxLRkQWkLz/pQ2gVX8OFBF4AU1V8im2w/LTuaKGa8w7RfKTyMvWaYMccLdVvy9mNOu/QfW80CMpDDgiY/+uXfmRvz3mcTV0+MuQY5/O3ZfmB+9jWKQN6rOYtqB1ku50RDgBJfC0wCjvzVUHVfQ+Z3j2wDw8UXeYPFlRuSLN1d2geyJ868cD0DDYb3Ohu6COC5ZmPxCKNxSFCua7rlGY3cD+hVYpS2dQDRKwRIabWjVmelP6zxP9B9MDTHmBE177WU/mGksUhDczxjfHWUHtGsq468yrhl0ylF+lCMn+gRAjPac3GBUa0EAh7TptuOg4v7SVjjB0GRCpQrwe9siutlqf25Y0k6c5OoAk3vwddnViqgXZDFeHmt9fKtaycgMmQG3V1KTUM5YbFdC1A/uYCE9/rNG62WUWnsQzWvhzr+E0XPqcSY4Vkpqdmwc+HyOMsRGlUFETawv4KOv3NfqaVwxksDkkiZXy5vLoh+tgr3FEf+HfljB/EARMQ8MCRxCGyDQZjxiF3sizG1ClkF+/7gIQuWVrvSQ3ZFFex5dROKg1J1mDyERW+BRP+9rzVntXVTogDk/nKQKASonEj350LohGXZPCBstWvy6uBYoZX6UATWaQsBRqcNjqTrg6/YtIVmXpMMjvb5rzP5mb7X6bRiDfm0ZrCZhMaFRZHHRQtpdSyxiNsIj1UVHFI8cjoXx0d0WxJHJG8VMPQ8Ot9Zxlt9ikPhj1sT8IuDFdv1lgIqtWzejKCOztjjefSH23iz/JpLOhBFGYWg== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nTQra4yRHPUBWRpSYBUJY9sDL3MzwpYTw6p1ts6S5r7Je3nVD0Pm5bzU23Hg0BJEzP17gwt/lWE7wDsQCX39LN27JoLO5KSKMZ1phzgkc111Ueen5XymVMWFJ3ihf5HLsNbglm4RbsGRXekT+Ll/0/Ru8Knrsf/SgI8868msOYjVUCtwS4HtVe7FiHyo4YUKI/KNhQPcUQ++bIbVa+00TeaO/x2rrcxCAWnCyH9VpWhzUaOF4zIyxWvniw82VbacevhnQxwhlhyuvjAY9IjL9MPz/Ue0kQsHiwa7faPDMNu7loTD31EVbkQyNvo3cYVM5pDhtvWVSBmoJmNMLiHtVg== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5MFQlzN9aK5kTIqNNwADtbo0gc1W9fxrwFWePP6jfB8=; b=KfJVlpYRojzZb0oTdfR4NjYms4DBgRHf8Ad6odaJu0LMJUPgdwiPIekOrRSZaTlvJGy9uc1m9WWKcTpGh/EZ6reT94Y/i96tId5VLuD2VRfVmlsctNNZczFIGWZenbRLuGRBo9PgEAN3I0d58ZLlOKYQamLHvZm51srnbv6XxMjddCKOdH8OXwJSkpftpWej4FTTiD1AIairzicN84wEstb/ugF+2IeWrG/EWV2LV2XiyuDg40JVWkA8SjLosCDh/9JKlLfkTeCEpWFWOp48XxUxeBWhCdWpLq8PKKbeu+ACyfstV6/pZw1sbTDyRS621D8b4ttZuUc4MBpDT6a5dQ== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: BYAPR11MB3111.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 5b8d8f30-249e-4b0f-4d2a-08d88d029156 x-ms-exchange-crosstenant-originalarrivaltime: 20 Nov 2020 03:15:43.8929 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: 0Jgg/CJiSeRAnqde/vweaW4diCj0a9mgtDXhu7SdLgpR8YSq9srrQgGWS0wHWU2Fgh4qLiNgPjaR1QWYamIw3c2NHo0J9zY3lCgv3OW5W9Q= x-ms-exchange-transport-crosstenantheadersstamped: BYAPR11MB3621 x-originatororg: comcast.com Content-Type: multipart/alternative; boundary="_000_DFB3E152F358435493343A6F89B8DC6Dcomcastcom_" MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWB X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-19_14:2020-11-19, 2020-11-19 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [Add] Scribes needed for ADD Session 2 X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 03:15:55 -0000 --_000_DFB3E152F358435493343A6F89B8DC6Dcomcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KV2Ugc3RpbGwgbmVlZCBvbmUgb3IgbW9yZSBzY3JpYmVzIHRvIGhlbHAgd2l0aCBub3Rl cywgcGxlYXNlIGNvbnNpZGVyIGhlbHBpbmcgb3V0LiBJdOKAmXMgZWFzeSB0byBkbyBhbmQgaWYg eW914oCZcmUgaW4gYSBsb2NhdGlvbiB3aGVyZSBpdOKAmXMgbGF0ZSBhdCBuaWdodCDigJMgaXQg d2lsbCBoZWxwIGtlZXAgeW91IGF3YWtlIQ0KDQpQbGVhc2UgcmVwbHkgdG8gQWRkLUNoYWlyc0BJ RVRGLk9SRzxtYWlsdG86QWRkLUNoYWlyc0BJRVRGLk9SRz4gaWYgeW914oCZcmUgd2lsbGluZyB0 byBoZWxwLg0KDQpUaGFua3MNCkdsZW5uDQo= --_000_DFB3E152F358435493343A6F89B8DC6Dcomcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: <896027B3CE4CF44E984FF4B9DD75EA80@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiBcKEJvZHkgQ1NcKSI7DQoJcGFub3NlLTE6MiAyIDYgMyA1 IDQgNSAyIDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCWNvbG9yOndp bmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5IaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNh Ij5XZSBzdGlsbCBuZWVkIG9uZSBvciBtb3JlIHNjcmliZXMgdG8gaGVscCB3aXRoIG5vdGVzLCBw bGVhc2UgY29uc2lkZXIgaGVscGluZyBvdXQuIEl04oCZcyBlYXN5IHRvIGRvIGFuZCBpZiB5b3Xi gJlyZSBpbiBhIGxvY2F0aW9uIHdoZXJlIGl04oCZcyBsYXRlIGF0IG5pZ2h0IOKAkyBpdCB3aWxs IGhlbHAga2VlcCB5b3UgYXdha2UhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0 aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPlBsZWFz ZSByZXBseSB0bw0KPGEgaHJlZj0ibWFpbHRvOkFkZC1DaGFpcnNASUVURi5PUkciPkFkZC1DaGFp cnNASUVURi5PUkc8L2E+IGlmIHlvdeKAmXJlIHdpbGxpbmcgdG8gaGVscC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkhlbHZldGljYSI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6SGVs dmV0aWNhIj5HbGVubjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_DFB3E152F358435493343A6F89B8DC6Dcomcastcom_-- From nobody Tue Nov 24 06:04:01 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E893A0E2C for ; Tue, 24 Nov 2020 06:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sinodun.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 Nbimi60rrMtH for ; Tue, 24 Nov 2020 06:03:58 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (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 251AA3A0E24 for ; Tue, 24 Nov 2020 06:03:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sinodun.com ; s=mythic-beasts-k1; h=Date:To:Subject:From; bh=+15Z6veQRkGt6XUxq0ORDuDhsW/cQx089xpc1QSSVsY=; b=PNckONk7+5+rs0I9/7SSB/6YHO rtF0a4KVDeJ1x6w+tUDkVVS8aGL9Qk0gHHL1SZNtknV08BBriwjijFMYA+RYeOsWGJv3LqCy68NP7 glB17AsG7nXKeFXCLhdsansZZ0PnqcCROgfC13wJSFuXsMIYnzuLWLA4H30zUBGmqDAm1lYUiH4Fe TWqKAdfI0613KOvkYEEIZnNVZzMM0xByxGQDCSRq45FI2eaYhtErE2c/5ThjkAx+ULpfcoAUokKDi /GDnjDshkR0i956FclaOhYlwyvnIYsFDikDOkhiDWNMqJOFQRSDtwQ6EXGChHKqj3NurpEZoctsNA hQLRXMeg==; Received: from [62.232.251.194] (port=29620 helo=[172.27.240.2]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1khYvA-0000Za-Oa for add@ietf.org; Tue, 24 Nov 2020 14:03:56 +0000 From: Sara Dickinson Content-Type: multipart/alternative; boundary="Apple-Mail=_17C27FE1-604B-4F27-9200-994078049F03" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Message-Id: <628224D6-92B7-446F-B251-71D886A92757@sinodun.com> References: <0B6FD06E-8050-49EE-93A1-7C9D1CFB3691@sinodun.com> To: add@ietf.org Date: Tue, 24 Nov 2020 14:03:50 +0000 X-Mailer: Apple Mail (2.3445.104.17) X-BlackCat-Spam-Score: 4 Archived-At: Subject: [Add] Call for Papers: NDSS Workshop on DNS Privacy 2021 X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 14:04:01 -0000 --Apple-Mail=_17C27FE1-604B-4F27-9200-994078049F03 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 With permission (and this time the correct link!) =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94 Hi All,=20 Please consider submitting to or attending the NDSS DNS Privacy Workshop = 2021: Measuring deployment and effectiveness of encrypted DNS Call for papers: https://dnsprivacy.org/wiki/x/C4DkAg = We welcome submissions in the form of research papers, short papers, or = draft presentations concerning all aspects of the threats, the = protocols, and future design spaces of DNS privacy or the privacy of = adjacent protocols. Usability, traceability, measurement and analytical = evaluations are particularly encouraged. Location and Important Dates =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94 Online virtual conference. * Submissions due - 21st December * Acceptances sent out - mid-January * Presentation materials due - 15th Feb * Workshop - TBD, one of 21-24th of February Allison, Sara and Shivan (DNS Privacy Workshop chairs). --Apple-Mail=_17C27FE1-604B-4F27-9200-994078049F03 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
With permission (and this time the correct link!)
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94


Hi All, 

Please consider submitting to or = attending the NDSS DNS Privacy Workshop 2021: Measuring deployment and = effectiveness of encrypted DNS

Call for papers:  https://dnsprivacy.org/wiki/x/C4DkAg

We welcome submissions = in the form of research papers, short papers, or draft presentations = concerning all aspects of the threats, the protocols, and future design = spaces of DNS privacy or the privacy of adjacent protocols. =  Usability, traceability, measurement and analytical evaluations = are particularly encouraged.


Location and Important Dates
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

Online virtual conference.

* = Submissions due - 21st December
* = Acceptances sent out - mid-January
* = Presentation materials due - 15th Feb
* Workshop - TBD, one of 21-24th of February


Allison, Sara and Shivan (DNS Privacy Workshop = chairs).

= --Apple-Mail=_17C27FE1-604B-4F27-9200-994078049F03-- From nobody Wed Nov 25 11:43:29 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A4E3A1BE9 for ; Wed, 25 Nov 2020 11:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 60o-HSVbZAVk for ; Wed, 25 Nov 2020 11:43:22 -0800 (PST) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 C602F3A1BEC for ; Wed, 25 Nov 2020 11:43:22 -0800 (PST) Received: by mail-qk1-x72a.google.com with SMTP id y197so5834270qkb.7 for ; Wed, 25 Nov 2020 11:43:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Wgj/msq8PIsb18CRNLAV38PPunJzFLk1uB2iZgiuWSA=; b=ZhNo14I7D0Ppv1tM7RssNlT2cN+owkqyGLldRc/0ovCAuGoC6LJXT75em9AvQqZjk3 U5AArW3QLj/KAE287oN6HI1Vx2X/VBDFLeKwmjtpaTLMYITJMEY6ADGVvzOjVyIbscKy FPJvy+OPDU2AdpwrXqE/D2mPXb/k83M/qqj4Bv0Ake3FJ+DFIz0n+wN9xR/bUL8uQ0D+ 2nb4mTQBt42hPN+WMKrYkAeRKTUGxVK+38C79zoW7FFdUxPXMvwelMq3rLFTFZjC0u9q Db6PA5bk1Wy+pdROnA1vqNPqM4s8WdOpLtFlvZKHiicEZZdTqlttiiB59eePc3e++LOi l7nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Wgj/msq8PIsb18CRNLAV38PPunJzFLk1uB2iZgiuWSA=; b=QsRwexsqR2/f/ldn8eeTTBhYiw7qbOCw8ZAwaNkxc3Buj6Ocn1VLgJXH3oWlyqoGub MtWVaLBvfPrgLglF6Y1BtlcYBP1QgHTH32242MRPLMmz1Cnihj4XQshUnr9B3qXQaGmj KqgAKRogWRTVWSXXubegUyT8ZfBvM5Q9+z9oFJN5q6on9eN/Yh5cer7R9bvUgbK12fSj B5iBZQ8PABCvz2OxyuUtdeCqrE+DQ0v/+kpfDC8lrVLwUK9ANGqJ5/NOjXrjf3XsaJx+ y+zXG7qNAsS2q2tDNHud7SSxlGYlfjrHqjxvDNA44fbdl6y1jctEt+Jtm6T3fCG3d9Qd 6vAQ== X-Gm-Message-State: AOAM532/3y516W+I/sEQYA2CuH1rZFxduLhnQwnqrvkBtP3bplAtwglo ujGTuvgWXuG28NlYjpo4px1iFgCRgXrde0zTRXyp4sRd1pc= X-Google-Smtp-Source: ABdhPJyrzWJ88zY1e15aITlihtlyHdXc5Da3JxgVr5Jdc8ZHDvbYk5/ujh7rgEqvXFDfgCR4lnXSldQLT1oB02Q96vI= X-Received: by 2002:a37:4a88:: with SMTP id x130mr479241qka.69.1606333401634; Wed, 25 Nov 2020 11:43:21 -0800 (PST) MIME-Version: 1.0 From: Daniel Migault Date: Wed, 25 Nov 2020 14:43:10 -0500 Message-ID: To: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000cb9b4205b4f3a35f" Archived-At: Subject: [Add] comments / question regarding draft-cook-doh-discovery-trial X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 19:43:24 -0000 --000000000000cb9b4205b4f3a35f Content-Type: text/plain; charset="UTF-8" Hi, I am commenting quite late on the document, but I have a suggestion and would be happy to hear your feed backs. Overall I like the mechanism, but I would like to avoid the use of SUDN as it prevents the use of DNSSEC. If the resolver is being advertised by its IP address, I would rather rather derive the query from that IP. A FQDN based on .in-addr.arpa (.ip6.arpa could fulfill such condition which provides the following advantages: * it does not require the creation of another SUDN. * it does not require to handle a special case for the resolution and instead proceed to standard and unchanged DNS resolution which makes it work with any currently deployed DNS software. * the mechanism works for resolver, and authoritative server proving DoH. * DNSSEC can be used to protect against spoofed attacks including NXDOMAIN responses. * DNSSEC can be used to delegate securely to a third party DoH resolver by providing the certificate used in the TLS session. When used with private IP addresses [rfc6303], the DNSSEC key used to sign the forward and reverse zone needs to be provisioned or learned with TOFU mechanisms - which remains better than none. With these benefits, the implementation on CPE is not much difficult than responding dohresolver.arpa. One difference is that the data associated with the IP address is hosted on the authoritative server, while in the current proposal, it is the entity receiving the data (authoritative or resolver). In both cases, the association is the IP address value. In most CPE deployment, this does not represent a huge change as the CPE hosts the internal data as well as plays as a resolver. There is only NAT that I see causing potential issues. Yours, Daniel -- Daniel Migault Ericsson --000000000000cb9b4205b4f3a35f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I am commenting quite late on the=C2=A0documen= t, but I have a suggestion and would be happy to hear your=C2=A0feed backs.= Overall I like the mechanism, but I would like to avoid the use of SUDN as= it prevents the use of DNSSEC.

If the resolver is being advertised= by its IP address, I would rather rather derive the query from that IP. A = FQDN based on <ip>.in-addr.arpa (<ip>.ip6.arpa could fulfill su= ch condition which provides the following advantages:
* it does not requ= ire the creation of another SUDN.
* it does not require to handle a spec= ial case for the resolution and instead proceed to standard and unchanged D= NS resolution which makes it work with any currently deployed DNS software.=
* the mechanism=C2=A0works for resolver, and authoritative server provi= ng DoH.
* DNSSEC can be used to protect against spoofed attacks includin= g NXDOMAIN responses.
* DNSSEC can be used to delegate securely to a thi= rd party DoH resolver by providing the certificate used in the TLS session.=

When used with private IP addresses [rfc6303], the DNSSEC key used= to sign the forward and reverse zone needs to be provisioned or learned wi= th TOFU mechanisms - which remains better than none.=C2=A0
With these be= nefits, the implementation on CPE is not much difficult than responding doh= resolver.arpa.

One difference is that the data associated with the I= P address is hosted on the authoritative server, while in the current propo= sal, it is the entity receiving the data (authoritative or resolver). In bo= th cases, the association is the IP address value. In most CPE deployment, = this does not represent a huge change as the CPE hosts the internal data as= well as plays as a resolver. There is only NAT that I see causing potentia= l issues.

Yours,
Daniel

--
Daniel Migault
Ericsson
--000000000000cb9b4205b4f3a35f-- From nobody Wed Nov 25 14:02:22 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B99163A1EEA for ; Wed, 25 Nov 2020 14:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 S4LEVkxJW8Nj for ; Wed, 25 Nov 2020 14:02:20 -0800 (PST) Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (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 7C1BA3A1EEC for ; Wed, 25 Nov 2020 14:02:20 -0800 (PST) Received: by mail-vk1-xa2d.google.com with SMTP id s135so40846vkh.6 for ; Wed, 25 Nov 2020 14:02:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=3hECXZe2DfcF/CLCYxtpiyM2AzRNl6zoCAaC+3csJXk=; b=fNDObe4ek3xxyvmY1pXNJcqCCQbSMJf2FMzxUtVaxvqM+oBIEGZ3E9WYxtn/feZmbq nItzUjBe8+Z94GchLeHkOKn7KN2XvqD42c+jPSbmwNoloJGW8Dfi9PcXCRxewUIX2j2S +rWi7HW6EHmvaaaVj7hmpcsnOEjVIFw+o4BSghx9YVSB/diSpOl28QxoaRMGMyZqGybT TmEnEwGa9yDZ3OsuqauTjeEATodHpzWLTt5MKQriiAxgBe1wgamOP6jzn7XG7t0KmjWY cSs6p6CABdbyogQQbSUpsqqMj3bWH872QTSZo5h9SHwZ1ZJcL7vgOfuUWpBwfy7gkUOO c+mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=3hECXZe2DfcF/CLCYxtpiyM2AzRNl6zoCAaC+3csJXk=; b=D4+veY4ZCx/Qeh0YNh3J6PyrJ5gOZjikKgaM7pBBqNYRDUpp3UW5bZ3x2MyxnGdJxn 6Jn1oIdFhgW0S5Qii6gPXLx0+7er2zJQUppkbmlkm97BrUqcduRGmuflR/KI6hppivh5 FLecdehR3ariEjf9q7jhNwkPvCUA694NI3DXWVKjTNfYr1NWbzDmTrDAlhFH7P1V34LF vbpUeABZvMiRTTLTB3WqfVv02Zz9sGr1+X2ZHqxEx18ckpbxzpGpbvssY6KUEhG9DTZp n447DUkjKKqgkvAyxe4SLjnfdQLl9NshVGzcSGLHXK1yuuNINPyu1OilC31+1cx4xvEf 4L0w== X-Gm-Message-State: AOAM533X8QyNkek4AvZGHvG58AP1Htmn23EQGC26h8BP9zDdqPmF3D1F +oHokKsED3rwYj0ij5p0CibLn/hJP0ps5XnMTiw9yaFQXHo= X-Google-Smtp-Source: ABdhPJxqW4/qTTnpdV6VJh5DlezPy4z5CKWRVFotYatQBLmjXA9wKcEgWtuVAO36e1Sd/AhXTprC4FzEcgfzEXeOtD8= X-Received: by 2002:a1f:5e0e:: with SMTP id s14mr168061vkb.19.1606341739178; Wed, 25 Nov 2020 14:02:19 -0800 (PST) MIME-Version: 1.0 From: Daniel Migault Date: Wed, 25 Nov 2020 17:02:08 -0500 Message-ID: To: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000c06ecd05b4f59405" Archived-At: Subject: [Add] discussion on draft-btw-add-home X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 22:02:22 -0000 --000000000000c06ecd05b4f59405 Content-Type: text/plain; charset="UTF-8" Hi, I understand the ADN designating the FQDN of the DNS server. I am wondering if the Encr DNS Types field may not be a bit limited, and if it might not be preferred to request a request of type SVCB. Additionally, though it may depend on the size of the SVCB response, I am also wondering if sending the raw SVCB response could be possible. Yours, Daniel -- Daniel Migault Ericsson --000000000000c06ecd05b4f59405 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

I understand=C2=A0the AD= N designating the FQDN of the DNS server. I am wondering if the=C2=A0Encr DNS Types field may not= be a bit limited,=C2=A0and if it might not be preferred to request a reque= st of type SVCB.=C2=A0

Additionally, though it may depend on the size of the SVC= B response, I am also wondering if sending the raw SVCB response could be p= ossible.

Yours,=C2=A0
Daniel=C2=A0=C2=A0

--
Daniel Migault
Ericsson
--000000000000c06ecd05b4f59405-- From nobody Wed Nov 25 14:10:08 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CF93A1F61 for ; Wed, 25 Nov 2020 14:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 EFZe3Z1Dl34h for ; Wed, 25 Nov 2020 14:09:55 -0800 (PST) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 4551B3A1F0E for ; Wed, 25 Nov 2020 14:09:55 -0800 (PST) Received: by mail-vs1-xe29.google.com with SMTP id m62so2027840vsd.3 for ; Wed, 25 Nov 2020 14:09:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=1J1cowzsWyoNES3BB+JLlPTHDjxNvyi/bH8Ikc7x9S0=; b=OopDvcKa5gEghxpTgkkmozPg5OkPR3U7QXVatNdvs/7vJPiPkGmStA53uuoEOFgfTE miR+D1JSCKODXqutG9UUUUmLMe3mW6FKt0YH29rdVNi2Hx4j1UrFGinVJHMnRf721Y41 lpv8/34IwTHpAwxq1LdcWkfdhCwhLtaZlYm4DsDxiEMcpigBgR3E2McvTAkLeT8qe28Y jCtpalpxY2crnvyGMZqUsWVPBVkrzHzAbvoicTj+1aK3IxtX/zCf5tivp+RZ7W4k8WZQ JIx5ovyt6jyxejDpwnf9R3nT+s/3fEC4XryGljThYhFLeeIEBK8fIyMv9b+7qFhOVzU9 Zgcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1J1cowzsWyoNES3BB+JLlPTHDjxNvyi/bH8Ikc7x9S0=; b=BuAPpVPbw6ddLpSA/HgMcqesZrkvsel7QDZPavubxr/DaTVXiRqdxkhP1w9KGOoAA1 IpP3AMMSH+FABb6uRUPKjuQlXShsOuMufEHTQEtEktLA9WH2j9RShS7oq9xyyP7IRQlO /zLjuTydH2EyCvq5BZu7pUuELP71qKZoNsWv73oX67h8FGMVaRgNUaVdJDeGBkH0EVW5 i01p736bSk4pjFvs3jPBmXFz1pfumvXybNVmNdGHZOjnaE/8W6pMQ30s8zC3zEq8jBC1 7HeQMXc98vkpoLm5rlcQyWOPRH5qekwtpK2DuQVwzYa3eZ2ZSLLhhAsUStKywC7Jw+4A 85lA== X-Gm-Message-State: AOAM531SNlppveEn3MVmd16kiwQWeNv90K84QYd3nqqIwbxNjBxsH7di 27RvmUMxDrdd6AkK6Ov3ELO3fTPdSJDJDjvaekomrUrL8UI= X-Google-Smtp-Source: ABdhPJyeko7Bm323L4d24KNNaWlGM8gALTs1WH/VmjHh5HvR3QZ2AKr2QuCj+2Xy0tUH/3JcDPvTQKqX++gBjbtwofU= X-Received: by 2002:a05:6102:31bb:: with SMTP id d27mr78927vsh.56.1606342193839; Wed, 25 Nov 2020 14:09:53 -0800 (PST) MIME-Version: 1.0 From: Daniel Migault Date: Wed, 25 Nov 2020 17:09:43 -0500 Message-ID: To: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000da01e505b4f5af40" Archived-At: Subject: [Add] draft-schwartz-svcb-dns-01 X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 22:10:07 -0000 --000000000000da01e505b4f5af40 Content-Type: text/plain; charset="UTF-8" Hi, Please find my comments below for draft-schwartz-svcb-dns-01 Yours, Daniel Service Binding Mapping for DNS Servers draft-schwartz-svcb-dns-01 [...] 1. Introduction The SVCB record type [SVCB] provides clients with information about how to reach alternative endpoints for a service, which may have improved performance or privacy properties. It is unclear to me if "alternative" means "various flavors of DNS resolvers" or if it assumes the previous knowledge of one flavor of the resolver. I do not believe the latest is appropriated. The input of a SVCB query is a FQDN, and that FQDN is not necessarily related to a Do53 resolver for example. It could typically an entry point used to discover all different flavors of DNS resolvers. Assuming a previous knowledge of one resolver seems to preclude some assumption on the FQDN, which seems independent from the description of SVCB fro DNS. The service is identified by a "scheme" indicating the service type, a hostname, and optionally other information such as a port number. A DNS server is often identified only by its IP address (e.g. in DHCP), but in some contexts it can also be identified by a hostname (e.g. "NS" records, manual resolver configuration). I like the paragraph, but I believe it might help the reader to add that DNS servers can be authoritative or resolver which are quite common term. I am wondering however, if there are any reasons for not mentioning them. Schwartz Expires 11 February 2021 [Page 2] Internet-Draft SVCB for DNS August 2020 Use of the SVCB record type requires a mapping document for each service type, indicating how a client for that service can interpret the contents of the SVCB SvcParams. This document provides the mapping for the "dns" service type, allowing DNS servers to offer alternative endpoints and transports, including encrypted transports like DNS over TLS and DNS over HTTPS. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Name form Names are formed using Port-Prefix Naming ([SVCB] Section 2.3). For example, a DNS server with the name "dns1.example.com", listening (unusually) on non-default port number 5353, would be represented as "_5353._dns.dns1.example.com.". While this seems conform to the SVCB spec ;-) I would have envisioned the port number prefix as designating the service rather that actual port on which the service is run. Typically in Do53 would be designated as _53._dns and if that service is run on port 5353 I would expected the number being provide by the port SvcParameter. One specific reason for doing so is that the unconventional port cannot be guessed without previous knowledge. I believe that some specific convention should considers that _dns may designate the DNS service including all flavors. 4. Applicable existing SvcParamKeys 4.1. port This key is used to indicate the target port for connection. If omitted, the client SHALL use the default port for each transport protocol: 853 for DNS over TLS and 443 for DNS over HTTPS. I have the impression some text is needed to define how the transport is determined. I favor that port is being specified in this field as opposed to in the prefix. I also believe that the port number should not be defined at two distinct places. It seems that the default values depends on other SvcParameters - alpn or absence of it. This key is automatically mandatory if present. I might be missing some context here, but the latest sentence is a bit hard for me to understand. The condition " if present" seems contradicting the term "mandatory". I cannot figure out also what automatically mandatory means. 4.2. alpn and no-default-alpn These keys indicate the set of supported protocols. The default protocol is "dot", indicating support for DNS over TLS [DOT]. If the protocol set contains any HTTP versions (e.g. "h2", "h3"), then the record indicates support for DNS over HTTPS [DOH], and the "dohpath" key MUST be present (Section 5.1). All keys specified for use with the HTTPS record are also permissible, and apply to the resulting HTTP connection. I believe the text may specify the absence of alpn means DNS over UDP. I am unsure whether no-default-alpn means that alpn key is omitted or not, but if that is the case, it does not seem necessary to introduce its designation. Instead it might be clear enough to mention the alpn default value considers DNS over UDP. It also worth mentioning that alpn needs to be parsed before port and potential dohpath. If the protocol set contains protocols with different default ports, and no port key is specified, then protocols are contacted separately on their default ports. Note that in this configuration, ALPN negotiation does not defend against cross-protocol downgrade attacks. Schwartz Expires 11 February 2021 [Page 3] Internet-Draft SVCB for DNS August 2020 These keys are automatically mandatory if present. 4.3. Other applicable SvcParamKeys These SvcParamKeys apply to the "dns" scheme without modification: * echconfig * ipv4hint * ipv6hint not sure we need this section as the document is limited on the DNS transport. I am however wondering if we should distinguish between authoritative and resolver. [...] 7. Relationship to DNS URIs The "dns:" URI scheme [DNSURI] describes a way to represent DNS queries as URIs. This scheme optionally includes an authority, comprised of a host and port number (with a default of 53). DNS URIs normally omit the authority, or specify an IP address, but a hostname is allowed, in which case it is suitable for use with this mapping. Schwartz Expires 11 February 2021 [Page 4] Internet-Draft SVCB for DNS August 2020 8. Examples * A resolver at "resolver.example" that supports - DNS over TLS on "resolver.example", port 853 and 8530, with "resolver.example" as the Authentication Domain Name, - DNS over HTTPS at "https://resolver.example/dns-query{?dns}", and - an experimental protocol on "fooexp.resolver.example:5353": $ORIGIN example. _dns.resolver 7200 IN SVCB 1 resolver ( alpn=h2,h3 echconfig=... dohpath=/dns-query{?dns} ) _dns.resolver 7200 IN SVCB 2 resolver ( port=8530 echconfig=... ) _dns.resolver 7200 IN SVCB 3 fooexp.resolver ( port=5353 echconfig=... alpn=foo no-default-alpn foo-info=... ) * A nameserver at "ns.example" whose service configuration is published on a different domain: $ORIGIN example. _dns.ns 7200 IN SVCB 0 _dns.ns.nic I am wondering if ther is any room for searching specifically doh server by requesting: _443._dns.resolver 7200 IN SVCB 1 resolver ( alpn=h2,h3 echconfig=... dohpath=/dns-query{?dns} ) If that is not the case, it seems we should clarify this. The same case occurs with DoT, Do53. The advantage would be that it enables to narrow down the search and prevents the search of non supported transports. The downside is that it requires some synchronization between SVCB RRsets and when multiple supports are supported by one client multiple queries may be performed. It also may require to define some preference across SVCB RRsets over multiple domains. 9. Security Considerations 9.1. Adversary on the query path This section considers an adversary who can add or remove responses to the SVCB query. Clients MUST authenticate the server to its name during secure transport establishment. This name is the hostname used to construct the original SVCB query, and cannot be influenced by the SVCB record contents. I understand that after the SVCB exchange, the DNS client sets a TLS session with the DNS server. I think this is only valid when TLS is supported and Do53 woudl not fit in this category. It sounds to me difficult to have a requirement that says, when a https server supports https the session must be authenticated. I am tempted to say that the https server should not serve non secure sessions. On the other hand, one can also envisioned the case where a given IP/FQDN is shared by DoH and Do53, which makes such assumption difficult. Unless I am missing something, it sounds to me the MUST statement is difficult to enforce. I think it is good to specify what name must be present in the certificate. Though what is unclear to me is why the name should be the one of the query as opposed as the one in the RDATA. I understand the text as saying that connecting to fooexp.resolver.example, the certificate should have resolver.example. If that is correct, and unless I am missing something, I would be more inclined to authenticate fooexp.resolver.example. One case I see is an ISP delegating to a DNS resolver provider - like akamai. It should rather let the user authenticate akamai than the ISP hostname. Other scenario could ignore the hostname and use a footprint or the entire certificate. Of course this would require DNSSEC. It seems such recommendation is limited to the case when DNSSEC is not used and when the SVCB name is provisioned in a trusted manner. If an attacker is likely to update the SCVB content, he might potentially have provided the false entry to initiate the SVCB query, in which case there may not be any need to update the SVCB parameters. I believe the primary recommendation should be to use DNSSEC and then consider the very specific use case where DNSSEC cannot be used with a trusted SVCB entry. Accordingly, this draft does not mandate the use of DNSSEC. This draft also does not specify how clients authenticate the name (e.g. selection of roots of trust), which might vary according to the context. Although this adversary cannot alter the authentication name of the server, it does have control of the port number and "dohpath" value. As a result, the adversary can direct DNS queries for $HOSTNAME to any port on $HOSTNAME, and any path on "https://$HOSTNAME", even if $HOSTNAME is not actually a DNS server. If the DNS client uses shared TLS or HTTP state, the client could be correctly authenticated (e.g. using a TLS client certificate or HTTP cookie). Schwartz Expires 11 February 2021 [Page 5] Internet-Draft SVCB for DNS August 2020 This behavior creates a number of possible attacks for certain server configurations. For example, if "https://$HOSTNAME/upload" accepts any POST request as a file upload, the adversary could forge a SVCB record containing "dohpath=/upload", causing the client to upload every query, resulting in unexpected storage costs. As a mitigation, a client of this SVCB mapping MUST NOT provide client authentication for DNS queries, except to servers that it specifically knows are not vulnerable to such attacks. Also, if an alternative service endpoint sends an invalid response to a DNS query, the client SHOULD NOT send more queries to that endpoint. The attack is limited to DoH and DoT is not concerned. This attack is targeting the https server, but in general the motivation for the client to authenticate the server is to protect its privacy. It seems this should be added or clarified. -- Daniel Migault Ericsson --000000000000da01e505b4f5af40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Please find my comments below= for=C2=A0draft-schwartz-svcb-dns-01

Yours,=C2=A0<= br>Daniel
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Service Binding Mapping for DNS Servers
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-= schwartz-svcb-dns-01
[...]

1.=C2=A0 Introduction

=C2=A0 = =C2=A0The SVCB record type [SVCB] provides clients with information about=C2=A0 =C2=A0how to reach alternative endpoints for a service, which may = have
=C2=A0 =C2=A0improved performance or privacy properties. =C2=A0
=
<mglt>
It is unclear to me if "alternative"
means= "various flavors of DNS resolvers"
or if it assumes the previ= ous knowledge
of one flavor of the resolver. I do not
believe the lat= est is appropriated.

The input of a SVCB query is a FQDN, and
tha= t FQDN is not necessarily related to
a Do53 resolver for example. It cou= ld
typically an entry point used to
discover all different flavors of= DNS
resolvers. Assuming a previous knowledge
of one resolver seems t= o preclude some
assumption on the FQDN, which seems
independent from = the description of SVCB
fro DNS. =C2=A0 =C2=A0 =C2=A0
</mglt>
The service is
=C2=A0 =C2=A0identified by a "scheme" ind= icating the service type, a hostname, and
=C2=A0 =C2=A0optionally other = information such as a port number.=C2=A0 A DNS server is
=C2=A0 =C2=A0of= ten identified only by its IP address (e.g. in DHCP), but in some
=C2=A0= =C2=A0contexts it can also be identified by a hostname (e.g. =C2=A0"N= S" records,
=C2=A0 =C2=A0manual resolver configuration).

<= ;mglt>
I like the paragraph, but I believe it
might help the reade= r to add that DNS
servers can be authoritative or resolver
which are = quite common term. I am
wondering however, if there are any
reasons f= or not mentioning them.

</mglt>

Schwartz =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires 11 February 2021 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 2]

Internet-Dr= aft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SVCB for DNS =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 August 2020
=

=C2=A0 =C2=A0Use of the SVCB record type requires a mapping documen= t for each
=C2=A0 =C2=A0service type, indicating how a client for that s= ervice can interpret
=C2=A0 =C2=A0the contents of the SVCB SvcParams.=C2= =A0 This document provides the
=C2=A0 =C2=A0mapping for the "dns&qu= ot; service type, allowing DNS servers to offer
=C2=A0 =C2=A0alternative= endpoints and transports, including encrypted transports
=C2=A0 =C2=A0l= ike DNS over TLS and DNS over HTTPS.

2.=C2=A0 Conventions and Defini= tions

=C2=A0 =C2=A0The key words "MUST", "MUST NOT&qu= ot;, "REQUIRED", "SHALL", "SHALL NOT",
=C2= =A0 =C2=A0"SHOULD", "SHOULD NOT", "RECOMMENDED&quo= t;, "NOT RECOMMENDED", "MAY", and
=C2=A0 =C2=A0"= ;OPTIONAL" in this document are to be interpreted as described in BCP<= br>=C2=A0 =C2=A014 [RFC2119] [RFC8174] when, and only when, they appear in = all
=C2=A0 =C2=A0capitals, as shown here.

3.=C2=A0 Name form
<= br>=C2=A0 =C2=A0Names are formed using Port-Prefix Naming ([SVCB] Section 2= .3).=C2=A0 For
=C2=A0 =C2=A0example, a DNS server with the name "dns1.example.com&q= uot;, listening
=C2=A0 =C2=A0(unusually) on non-default port number 5353= , would be represented as
=C2=A0 =C2=A0"_5353._dns.dns1.example.com.".
=
<mglt>
While this seems conform to the SVCB
spec ;-) I woul= d have envisioned the
port number prefix as designating the
service r= ather that actual port on which
the service is run. Typically in Do53would be designated as _53._dns and if
that service is run on port 5353= I would
expected the number being provide by the
port SvcParameter.<= br>
One specific reason for doing so is that
the unconventional port = cannot be
guessed without previous knowledge.

I believe that some= specific convention
should considers that _dns may designate
the DNS= service including all flavors.

</mglt>

4.=C2=A0 Applic= able existing SvcParamKeys

4.1. =C2=A0port

=C2=A0 =C2=A0This = key is used to indicate the target port for connection.=C2=A0 If
=C2=A0 = =C2=A0omitted, the client SHALL use the default port for each transport
= =C2=A0 =C2=A0protocol: 853 for DNS over TLS and 443 for DNS over HTTPS.
=
<mglt>
I have the impression some text is needed to define how= the transport is determined.
I favor that port is being specified inthis field as opposed to in the prefix.
I also believe that the port nu= mber
should not be defined at two distinct
places.

It seems th= at the default values depends
on other SvcParameters - alpn or absenceof it. =C2=A0
</mglt>

=C2=A0 =C2=A0This key is automatica= lly mandatory if present.

<mglt>
I might be missing some co= ntext here,
but the latest sentence is a bit hard
for me to understan= d.

The condition " if present" seems
contradicting the = term "mandatory". I
cannot figure out also what
automatical= ly mandatory means.

</mglt>

4.2. =C2=A0alpn and no-defa= ult-alpn

=C2=A0 =C2=A0These keys indicate the set of supported proto= cols.=C2=A0 The default
=C2=A0 =C2=A0protocol is "dot", indica= ting support for DNS over TLS [DOT].

=C2=A0 =C2=A0If the protocol se= t contains any HTTP versions (e.g. "h2", "h3"),
=C2= =A0 =C2=A0then the record indicates support for DNS over HTTPS [DOH], and t= he
=C2=A0 =C2=A0"dohpath" key MUST be present (Section 5.1).= =C2=A0 All keys specified for
=C2=A0 =C2=A0use with the HTTPS record are= also permissible, and apply to the
=C2=A0 =C2=A0resulting HTTP connecti= on.

<mglt>
I believe the text may specify the
absence of= alpn means DNS over UDP. I am
unsure whether no-default-alpn means
t= hat alpn key is omitted or not, but if
that is the case, it does not see= m
necessary to introduce its designation.
Instead it might be clear e= nough to
mention the alpn default value considers
DNS over UDP.
It also worth mentioning that alpn needs
to be parsed before port and = potential
dohpath.
</mglt>

=C2=A0 =C2=A0If the protocol = set contains protocols with different default ports,
=C2=A0 =C2=A0and no= port key is specified, then protocols are contacted separately
=C2=A0 = =C2=A0on their default ports.=C2=A0 Note that in this configuration, ALPN=C2=A0 =C2=A0negotiation does not defend against cross-protocol downgrade= attacks.




Schwartz =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Expires 11 February 2021 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 3]

Internet-Draft =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SVCB for DNS =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 August 2020


=C2=A0 =C2=A0= These keys are automatically mandatory if present.

4.3.=C2=A0 Other = applicable SvcParamKeys

=C2=A0 =C2=A0These SvcParamKeys apply to the= "dns" scheme without modification:

=C2=A0 =C2=A0* =C2=A0e= chconfig

=C2=A0 =C2=A0* =C2=A0ipv4hint

=C2=A0 =C2=A0* =C2=A0i= pv6hint

<mglt>
not sure we need this section as the
docu= ment is limited on the DNS
transport.

I am however wondering if w= e should
distinguish between authoritative and
resolver. =C2=A0
</mglt>

[...]

7.=C2=A0 Relationship to DNS URIs
=C2=A0 =C2=A0The "dns:" URI scheme [DNSURI] describes a way to = represent DNS
=C2=A0 =C2=A0queries as URIs.=C2=A0 This scheme optionally= includes an authority,
=C2=A0 =C2=A0comprised of a host and port number= (with a default of 53).=C2=A0 DNS URIs
=C2=A0 =C2=A0normally omit the a= uthority, or specify an IP address, but a hostname
=C2=A0 =C2=A0is allow= ed, in which case it is suitable for use with this mapping.



=
Schwartz =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires= 11 February 2021 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[P= age 4]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0SVCB for DNS =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 August 2020


8.=C2=A0 Examples

=C2=A0 =C2=A0* = =C2=A0A resolver at "resolver.example" that supports

=C2= =A0 =C2=A0 =C2=A0 - =C2=A0DNS over TLS on "resolver.example", por= t 853 and 8530, with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"resolver.ex= ample" as the Authentication Domain Name,

=C2=A0 =C2=A0 =C2=A0 = - =C2=A0DNS over HTTPS at "https://resolver.example/dns-query{?dns}",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and

=C2=A0 =C2=A0 =C2= =A0 - =C2=A0an experimental protocol on "fooexp.resolver.example:5353&= quot;:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0$ORIGIN example.
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0_dns.resolver 7200 IN SVCB 1 resolver (
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0alpn=3Dh2,h3 echconfig=3D... dohpath= =3D/dns-query{?dns} )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_dns.resolver 72= 00 IN SVCB 2 resolver (
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0port=3D= 8530 echconfig=3D... )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_dns.resolver 7= 200 IN SVCB 3 fooexp.resolver ( port=3D5353
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0echconfig=3D... alpn=3Dfoo no-default-alpn foo-info=3D... )
=C2=A0 =C2=A0* =C2=A0A nameserver at "ns.example" whose serv= ice configuration is
=C2=A0 =C2=A0 =C2=A0 published on a different domai= n:

=C2=A0 =C2=A0 =C2=A0 $ORIGIN example.
=C2=A0 =C2=A0 =C2=A0 _dn= s.ns 7200 IN SVCB 0 _dns.ns.nic


<mglt>
I am wondering i= f ther is any room for
searching specifically doh server by
requestin= g:

_443._dns.resolver 7200 IN SVCB 1 resolver (
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0alpn=3Dh2,h3 echconfig=3D... dohpath=3D/dns-query{?= dns} )

If that is not the case, it seems we
should clarify this.<= br>The same case occurs with DoT, Do53.

The advantage would be that = it enables
to narrow down the search and prevents
the search of non s= upported transports.

The downside is that it requires some
synchr= onization between SVCB RRsets and
when multiple supports are supported b= y
one client multiple queries may be
performed. It also may require t= o define
some preference across SVCB RRsets over
multiple domains.
</mglt>

9.=C2=A0 Security Considerations

9.1.=C2= =A0 Adversary on the query path

=C2=A0 =C2=A0This section considers = an adversary who can add or remove responses
=C2=A0 =C2=A0to the SVCB qu= ery.

=C2=A0 =C2=A0Clients MUST authenticate the server to its name d= uring secure
=C2=A0 =C2=A0transport establishment.=C2=A0 This name is th= e hostname used to construct
=C2=A0 =C2=A0the original SVCB query, and c= annot be influenced by the SVCB record
=C2=A0 =C2=A0contents. =C2=A0
= <mglt>
I understand that after the SVCB
exchange, the DNS clien= t sets a TLS
session with the DNS server. I think
this is only valid = when TLS is
supported and Do53 woudl not fit in this
category.
It = sounds to me difficult to have a
requirement that says, when a https
= server supports https the session must
be authenticated. I am tempted to= say
that the https server should not serve
non secure sessions. On t= he other hand,
one can also envisioned the case where
a given IP/FQDN= is shared by DoH and
Do53, which makes such assumption
difficult.Unless I am missing something, it sounds
to me the MUST statement is di= fficult to enforce.

I think it is good to specify what name
must = be present in the certificate.
Though what is unclear to me is why thename should be the one of the query as
opposed as the one in the RDATA= .

I understand the text as saying that
connecting to fooexp.resol= ver.example, the
certificate should have
resolver.example. If that is= correct,
and unless I am missing something, I
would be more inclined= to authenticate
fooexp.resolver.example.
One case I see is an ISP de= legating to a
DNS resolver provider - like akamai. It
should rather l= et the user authenticate
akamai than the ISP hostname. Other
scenario= could ignore the hostname and
use a footprint or the entire
certific= ate.
Of course this would require DNSSEC.

It seems such recommend= ation is limited
to the case when DNSSEC is not used and
when the SVC= B name is provisioned in a
trusted manner.
If an attacker is likelyto update the SCVB content, he might
potentially have provided the fal= se
entry to initiate the SVCB query, in
which case there may not be a= ny need to
update the SVCB parameters.

I believe the primary reco= mmendation should be
to use DNSSEC and then consider the very
specifi= c use case where DNSSEC cannot be
used with a trusted SVCB entry. =C2=A0=
</mglt>

=C2=A0 =C2=A0Accordingly, this draft does not mand= ate the use of
=C2=A0 =C2=A0DNSSEC.=C2=A0 This draft also does not speci= fy how clients authenticate
=C2=A0 =C2=A0the name (e.g. selection of roo= ts of trust), which might vary
=C2=A0 =C2=A0according to the context.
=C2=A0 =C2=A0Although this adversary cannot alter the authentication n= ame of the
=C2=A0 =C2=A0server, it does have control of the port number = and "dohpath" value.
=C2=A0 =C2=A0As a result, the adversary c= an direct DNS queries for $HOSTNAME to
=C2=A0 =C2=A0any port on $HOSTNAM= E, and any path on "https://$HOSTNAME", even if
=C2=A0 =C2=A0$= HOSTNAME is not actually a DNS server.=C2=A0 If the DNS client uses
=C2= =A0 =C2=A0shared TLS or HTTP state, the client could be correctly authentic= ated
=C2=A0 =C2=A0(e.g. using a TLS client certificate or HTTP cookie).<= br>


Schwartz =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Expires 11 February 2021 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0[Page 5]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0SVCB for DNS =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 August 2020


=C2=A0 =C2=A0This behavior = creates a number of possible attacks for certain server
=C2=A0 =C2=A0con= figurations.=C2=A0 For example, if "https://$HOSTNAME/upload" acc= epts
=C2=A0 =C2=A0any POST request as a file upload, the adversary could= forge a SVCB
=C2=A0 =C2=A0record containing "dohpath=3D/upload&quo= t;, causing the client to upload
=C2=A0 =C2=A0every query, resulting in = unexpected storage costs.

=C2=A0 =C2=A0As a mitigation, a client of = this SVCB mapping MUST NOT provide
=C2=A0 =C2=A0client authentication fo= r DNS queries, except to servers that it
=C2=A0 =C2=A0specifically knows= are not vulnerable to such attacks.=C2=A0 Also, if an
=C2=A0 =C2=A0alte= rnative service endpoint sends an invalid response to a DNS
=C2=A0 =C2= =A0query, the client SHOULD NOT send more queries to that endpoint.

= <mglt>
The attack is limited to DoH and DoT is
not concerned.
This attack is targeting the https
server, but in general the moti= vation
for the client to authenticate the
server is to protect its pr= ivacy. It
seems this should be added or clarified.
</mglt>

=
--
Daniel Migault
E= ricsson
--000000000000da01e505b4f5af40-- From nobody Mon Nov 30 11:57:52 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6CE3A10DC for ; Mon, 30 Nov 2020 11:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 XGllkytkWYDv for ; Mon, 30 Nov 2020 11:57:47 -0800 (PST) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 9A7A83A10DD for ; Mon, 30 Nov 2020 11:57:47 -0800 (PST) Received: by mail-il1-x12e.google.com with SMTP id z14so12522801ilm.10 for ; Mon, 30 Nov 2020 11:57:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w3+9WxVDKWRzkEqh7GVR8O1/oH0WNeRsLAFEr+DPJ30=; b=Y7Kk8r9XsqVoeX5s5nE23hr+/osfz+CIROm/dJRJfWHQTBIyU0Fh2+8l3L393Uc7I5 wLLYuQkYi2asgktHu4BwNN6XPslyYluTlOaBP92p5DMgI66gu7jUDl4ud9UZ+1PvEqjU TCZLwazXM6YzsLGZVBcVFOWKykpBFtzF4FBdut/Mt3i+FwfLTMHiwDIR44XBzppQY6Y2 QOcUEqKb5u/AvY4Q4c468GrVTpybUq6/jYpgSNu9w/qLAzAV7cgk/GwbiXIgh+0BIVU3 d3IVIs33EjWcX/1nBIWBJiMnhnk9BxNYxtsbb3ekEjlR0FP0PQsWMFxU/hLVJaLJfWR4 WTYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w3+9WxVDKWRzkEqh7GVR8O1/oH0WNeRsLAFEr+DPJ30=; b=E9IfUPhuQ6YtZt8AAzJVOZ1Wa20YK+UmQ8wnDvTFOeTvxSICkn492WQmjjxCVFNfI1 wySWUDN8awQLgmKdflh6Oae/G/jkmElMCUKTP9nZilWRFr14cNkue0IKOmyws/0oLAwK oU/zTzS2/hlwwnPOGNqm04BlI5RuDu7bZz7BClsmWJVrAV+oz/F/ncoKN6EOyZI1UZU7 T+lSc321i9g1QakDSMcjSjTmxAPCZAruLXqBsAVfXda6DisVQXAkkSns0WVlig/4/dE0 UDqC7Vv0pTF+k68oFYNRJzagVH8oIG0Q42i25lGTfZkA3OaEqQhzlZHARdNdbdy1nJGz 3+2g== X-Gm-Message-State: AOAM531WYeK/wNSSDfvujCLSlBGVEsX67PIoyEu0WScEVFGCT1ODASuJ E2sEuM1BnZcxt6Fou7KnluqiDKT80K2iouvEQfEQhQ== X-Google-Smtp-Source: ABdhPJyk+2s4XKqxY8b5v2TB0HBjQPmJTKkL42HNR2ikUGobORcx2i1lc6wMKhrj2FbMmGratLX+UiNqGw5ScBAoRVo= X-Received: by 2002:a05:6e02:104b:: with SMTP id p11mr20817407ilj.241.1606766266475; Mon, 30 Nov 2020 11:57:46 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ben Schwartz Date: Mon, 30 Nov 2020 14:57:34 -0500 Message-ID: To: Daniel Migault Cc: ADD Mailing list Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000094ef8b05b5586c1c" Archived-At: Subject: Re: [Add] draft-schwartz-svcb-dns-01 X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2020 19:57:51 -0000 --00000000000094ef8b05b5586c1c Content-Type: multipart/alternative; boundary="0000000000008d4aac05b5586ca4" --0000000000008d4aac05b5586ca4 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 25, 2020 at 5:10 PM Daniel Migault wrote: > Hi, > > Please find my comments below for draft-schwartz-svcb-dns-01 > Thanks for the detailed review. Yours, > Daniel > Service Binding Mapping for DNS Servers > draft-schwartz-svcb-dns-01 > [...] > > 1. Introduction > > The SVCB record type [SVCB] provides clients with information about > how to reach alternative endpoints for a service, which may have > improved performance or privacy properties. > > > It is unclear to me if "alternative" > means "various flavors of DNS resolvers" > or if it assumes the previous knowledge > of one flavor of the resolver. I do not > believe the latest is appropriated. > This is a general summary of SVCB. When using SVCB, there is a single logical "service" that can be accessed via different "endpoints". I'm not sure what you mean by "flavor", but SVCB assumes that the service's behavior does not greatly depend on which endpoint you use to access it. The input of a SVCB query is a FQDN, and > that FQDN is not necessarily related to > a Do53 resolver for example. It could > typically an entry point used to > discover all different flavors of DNS > resolvers. Assuming a previous knowledge > of one resolver seems to preclude some > assumption on the FQDN, which seems > independent from the description of SVCB > fro DNS. > > Sorry, I'm still not understanding, possibly because I do not understand the idea of a "flavor". The draft assumes a DNS server (or "service") identified by a domain name, with Do53 service available via A and AAAA records for that name (if a Do53 service exists, which seems likely to be common but is not required). The service is > identified by a "scheme" indicating the service type, a hostname, and > optionally other information such as a port number. A DNS server is > often identified only by its IP address (e.g. in DHCP), but in some > contexts it can also be identified by a hostname (e.g. "NS" records, > manual resolver configuration). > > > I like the paragraph, but I believe it > might help the reader to add that DNS > servers can be authoritative or resolver > which are quite common term. I am > wondering however, if there are any > reasons for not mentioning them. > > > This is a deliberate omission: this draft is concerned only with DNS as a protocol, not with the types of queries and responses that are encoded. In principle, this SVCB mapping can be applied independently of whether the server is authoritative for any names, or supports recursion. > Names are formed using Port-Prefix Naming ([SVCB] Section 2.3). For > example, a DNS server with the name "dns1.example.com", listening > (unusually) on non-default port number 5353, would be represented as > "_5353._dns.dns1.example.com.". > > > While this seems conform to the SVCB > spec ;-) I would have envisioned the > port number prefix as designating the > service rather that actual port on which > the service is run. Typically in Do53 > would be designated as _53._dns and if > that service is run on port 5353 I would > expected the number being provide by the > port SvcParameter. > The port SvcParam is also supported, but its meaning is different. The port prefix identifies the service. The port SvcParam provides the location of the alternative endpoint. One specific reason for doing so is that > the unconventional port cannot be > guessed without previous knowledge. > If the client has not been specifically informed that the service's identity contains an unconventional port, it will assume the default port (53), and query for SVCB records at _dns.$SERVER_NAME (no port prefix). Each SVCB record returned may contain a port SvcParamKey indicating where to find that alternative service endpoint. I believe that some specific convention > should considers that _dns may designate > the DNS service including all flavors. > As above, I don't understand what is meant by a "flavor". > This key is used to indicate the target port for connection. If > omitted, the client SHALL use the default port for each transport > protocol: 853 for DNS over TLS and 443 for DNS over HTTPS. > > > I have the impression some text is needed to define how the transport is > determined. > I favor that port is being specified in > this field as opposed to in the prefix. > I also believe that the port number > should not be defined at two distinct > places. > These two port numbers have separate meanings: the prefix is an "input" identifying the service, and the SvcParam is an "output" that locates the endpoint. It seems that the default values depends > on other SvcParameters - alpn or absence > of it. > Correct: in this draft, there is no single default value for "port". Instead, in the absence of a specified port, each transport uses its own default port. This enables a single SVCB record to represent both DNS over TLS on port 853 and DNS over HTTPS on port 443, as in the draft's first example: _dns.resolver 7200 IN SVCB 1 resolver alpn=h2,h3 echconfig=... dohpath=/dns-query{?dns} (This example enables DNS over TLS on port 853 implicitly.) We could change default behavior for "port", but it would likely make typical usages more verbose. This key is automatically mandatory if present. > > > I might be missing some context here, > but the latest sentence is a bit hard > for me to understand. > > The condition " if present" seems > contradicting the term "mandatory". I > cannot figure out also what > automatically mandatory means. > > > Yes, "automatically mandatory" is a specific term from the SVCB draft: https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-02#section-7. I've added a cross-reference for clarity: https://github.com/bemasc/svcb-dns/commit/535df722c9404413020af34d3d0e7209e3a206c1 > > 4.2. alpn and no-default-alpn > > These keys indicate the set of supported protocols. The default > protocol is "dot", indicating support for DNS over TLS [DOT]. > > If the protocol set contains any HTTP versions (e.g. "h2", "h3"), > then the record indicates support for DNS over HTTPS [DOH], and the > "dohpath" key MUST be present (Section 5.1). All keys specified for > use with the HTTPS record are also permissible, and apply to the > resulting HTTP connection. > > > I believe the text may specify the > absence of alpn means DNS over UDP. > If the "alpn" key is absent, the default is "dot". > I am > unsure whether no-default-alpn means > that alpn key is omitted or not, but if > that is the case, it does not seem > necessary to introduce its designation. > The default ALPN is "dot", so "no-default-alpn" means "DNS over TLS is not supported". If the "alpn" key is then omitted, the record is useless/null: it indicates no supported protocols at the alternative endpoint, so no client will ever attempt to make use of that record. > Instead it might be clear enough to > mention the alpn default value considers > DNS over UDP. > This draft does not currently offer any way to describe a DNS over UDP alternative endpoint. It also worth mentioning that alpn needs > to be parsed before port and potential > dohpath. > > I expect that a client would parse a record completely before attempting to make use of it, so I'm not concerned with this dependency. 4.3. Other applicable SvcParamKeys > > These SvcParamKeys apply to the "dns" scheme without modification: > > * echconfig > > * ipv4hint > > * ipv6hint > > > not sure we need this section as the > document is limited on the DNS > transport. > Yes, this is perhaps redundant. We could instead adjust the wording in the SVCB draft to indicate that these keys are assumed to be broadly applicable. However, I don't think it hurts to remind the reader of other keys that they can use in this context. I am however wondering if we should > distinguish between authoritative and > resolver. > This draft is not intended to be specific to one server role or the other. This is noted in Section 6. > I am wondering if ther is any room for > searching specifically doh server by > requesting: > > _443._dns.resolver 7200 IN SVCB 1 resolver ( > alpn=h2,h3 echconfig=... dohpath=/dns-query{?dns} ) > > If that is not the case, it seems we > should clarify this. > The same case occurs with DoT, Do53. > > The advantage would be that it enables > to narrow down the search and prevents > the search of non supported transports. > This is an interesting idea, but the SVCB framework does not support this approach. With SVCB, the client sends a request that describes a logical service, and receives an RRSet of alternative endpoints covering all the service's supported protocols. The downside is that it requires some > synchronization between SVCB RRsets and > when multiple supports are supported by > one client multiple queries may be > performed. It also may require to define > some preference across SVCB RRsets over > multiple domains. > Personally, I expect that servers will typically implement only a small number of protocols (at most ~4), and clients will often support more than one, so transferring the entire configuration in a single RRSet seems likely to be more efficient overall than issuing multiple queries. > > 9. Security Considerations > > 9.1. Adversary on the query path > > This section considers an adversary who can add or remove responses > to the SVCB query. > > Clients MUST authenticate the server to its name during secure > transport establishment. This name is the hostname used to construct > the original SVCB query, and cannot be influenced by the SVCB record > contents. > > I understand that after the SVCB > exchange, the DNS client sets a TLS > session with the DNS server. I think > this is only valid when TLS is > supported and Do53 woudl not fit in this > category. > Yes. This draft does not provide a way to describe a Do53 alternative endpoint. It sounds to me difficult to have a > requirement that says, when a https > server supports https the session must > be authenticated. > I'm not sure I understand. Authenticated transport is a requirement for HTTPS. > I am tempted to say > that the https server should not serve > non secure sessions. On the other hand, > one can also envisioned the case where > a given IP/FQDN is shared by DoH and > Do53, which makes such assumption > difficult. > Unless I am missing something, it sounds > to me the MUST statement is difficult to enforce. > This section is only meant to tell clients to perform SSL certificate validation in the usual way. > I think it is good to specify what name > must be present in the certificate. > Though what is unclear to me is why the > name should be the one of the query as > opposed as the one in the RDATA. > The RDATA is potentially untrusted. In the absence of DNSSEC, an intermediary could rewrite the RDATA to contain any name. I understand the text as saying that > connecting to fooexp.resolver.example, the > certificate should have > resolver.example. > Correct. > If that is correct, > and unless I am missing something, I > would be more inclined to authenticate > fooexp.resolver.example. > One case I see is an ISP delegating to a > DNS resolver provider - like akamai. It > should rather let the user authenticate > akamai than the ISP hostname. Other > scenario could ignore the hostname and > use a footprint or the entire > certificate. > Of course this would require DNSSEC. > > It seems such recommendation is limited > to the case when DNSSEC is not used and > when the SVCB name is provisioned in a > trusted manner. > Yes. However, the service provider does not know that the name was provisioned insecurely, and it does not know that the client is validating DNSSEC, so it has to include the service name in its certificate. Since all service providers will place the service name in the certificate, clients should check for this name, regardless of whether they validate DNSSEC. > If an attacker is likely > to update the SCVB content, he might > potentially have provided the false > entry to initiate the SVCB query, in > which case there may not be any need to > update the SVCB parameters. > > I believe the primary recommendation should be > to use DNSSEC and then consider the very > specific use case where DNSSEC cannot be > used with a trusted SVCB entry. > > This draft's approach to authentication is inherited from SVCB, which similarly does not rely on DNSSEC. In both cases, I think the current drafts are taking the best approach. In many or most of the anticipated applications, DNSSEC is not widely deployed, and we do not need it in order to deploy SVCB securely. Although this adversary cannot alter the authentication name of the > server, it does have control of the port number and "dohpath" value. > As a result, the adversary can direct DNS queries for $HOSTNAME to > any port on $HOSTNAME, and any path on "https://$HOSTNAME", even if > $HOSTNAME is not actually a DNS server. If the DNS client uses > shared TLS or HTTP state, the client could be correctly authenticated > (e.g. using a TLS client certificate or HTTP cookie). > > This behavior creates a number of possible attacks for certain server > configurations. For example, if "https://$HOSTNAME/upload" accepts > any POST request as a file upload, the adversary could forge a SVCB > record containing "dohpath=/upload", causing the client to upload > every query, resulting in unexpected storage costs. > > As a mitigation, a client of this SVCB mapping MUST NOT provide > client authentication for DNS queries, except to servers that it > specifically knows are not vulnerable to such attacks. Also, if an > alternative service endpoint sends an invalid response to a DNS > query, the client SHOULD NOT send more queries to that endpoint. > > > The attack is limited to DoH and DoT is > not concerned. > Correct. This attack is targeting the https > server, but in general the motivation > for the client to authenticate the > server is to protect its privacy. It > seems this should be added or clarified. > > OK, I've added an explanation of why this is privacy-relevant and strengthened the recommendation: https://github.com/bemasc/svcb-dns/commit/e311a4e94edd67e17724e693ad2038396fba8b4f --0000000000008d4aac05b5586ca4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable




=C2=A0 =C2=A0Nam= es are formed using Port-Prefix Naming ([SVCB] Section 2.3).=C2=A0 For
= =C2=A0 =C2=A0example, a DNS server with the name "dns1.example.com", listening=C2=A0 =C2=A0(unusually) on non-default port number 5353, would be represe= nted as
=C2=A0 =C2=A0"_5353._dns.dns1.example.com.".

<mglt>While this seems conform to the SVCB
spec ;-) I would have envisioned = the
port number prefix as designating the
service rather that actual = port on which
the service is run. Typically in Do53
would be designat= ed as _53._dns and if
that service is run on port 5353 I would
expect= ed the number being provide by the
port SvcParameter.

The port SvcParam is also support= ed, but its meaning is different.=C2=A0 The port prefix identifies the serv= ice.=C2=A0 The port SvcParam provides the location of the alternative endpo= int.

=
One specific reason for doing so is thatthe unconventional port cannot be
guessed without previous knowledge.

If the client ha= s not been specifically informed that the service's identity contains a= n unconventional port, it will assume the default port (53), and query for = SVCB records at _dns.$SERVER_NAME (no port prefix).=C2=A0 Each SVCB record = returned may contain a port SvcParamKey indicating where to find that alter= native service endpoint.

I believe that some spe= cific convention
should considers that _dns may designate
the DNS ser= vice including all flavors.
As above, I don't understand what is meant by a "flav= or".
=C2=A0
=C2=A0 =C2=A0This key is used to ind= icate the target port for connection.=C2=A0 If
=C2=A0 =C2=A0omitted, the= client SHALL use the default port for each transport
=C2=A0 =C2=A0proto= col: 853 for DNS over TLS and 443 for DNS over HTTPS.

<mglt>I have the impression some text is needed to define how the transport is = determined.
I favor that port is being specified in
this field as opp= osed to in the prefix.
I also believe that the port number
should not= be defined at two distinct
places.

These two port numbers have separate meanings: the = prefix is an "input" identifying the service, and the SvcParam is= an "output" that locates the endpoint.

It seems that the default values depends
on other SvcParameters - alpn= or absence
of it. =C2=A0
<= br>
Correct: in this draft, there is no single default value for = "port".=C2=A0 Instead, in the absence of a specified port, each t= ransport uses its own default port.=C2=A0 This enables a single SVCB record= to represent both DNS over TLS on port 853 and DNS over HTTPS on port 443,= as in the draft's first example:

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0_dns.resolver 7200 IN SVCB 1 resolver alpn=3Dh2,h3 = echconfig=3D... dohpath=3D/dns-query{?dns}

(Th= is example enables DNS over TLS on port 853 implicitly.)

We could change default behavior for "port", but it would = likely make typical usages more verbose.=C2=A0

= =C2=A0 =C2=A0This key is automatically mandatory if present.

<mgl= t>
I might be missing some context here,
but the latest sentence i= s a bit hard
for me to understand.

The condition " if presen= t" seems
contradicting the term "mandatory". I
cannot = figure out also what
automatically mandatory means.

</mglt>=

Yes, "aut= omatically mandatory" is a specific term from the SVCB draft:=C2=A0https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-02#section-7= .=C2=A0 I've added a cross-reference for clarity:=C2=A0https://github.com/bemasc/svcb-dns/commit/535df722c9404413020af34d3d0e7= 209e3a206c1
=C2=A0

4.2. =C2=A0alpn and no-def= ault-alpn

=C2=A0 =C2=A0These keys indicate the set of supported prot= ocols.=C2=A0 The default
=C2=A0 =C2=A0protocol is "dot", indic= ating support for DNS over TLS [DOT].

=C2=A0 =C2=A0If the protocol s= et contains any HTTP versions (e.g. "h2", "h3"),
=C2= =A0 =C2=A0then the record indicates support for DNS over HTTPS [DOH], and t= he
=C2=A0 =C2=A0"dohpath" key MUST be present (Section 5.1).= =C2=A0 All keys specified for
=C2=A0 =C2=A0use with the HTTPS record are= also permissible, and apply to the
=C2=A0 =C2=A0resulting HTTP connecti= on.

<mglt>
I believe the text may specify the
absence of= alpn means DNS over UDP.

If the "alpn" key is absent, the default is "dot"= ;.
=C2=A0
=
I am
unsure whether no-default-alpn mea= ns
that alpn key is omitted or not, but if
that is the case, it does = not seem
necessary to introduce its designation.

The default ALPN is "dot", s= o "no-default-alpn" means "DNS over TLS is not supported&quo= t;.=C2=A0 If the "alpn" key is then omitted, the record is useles= s/null: it indicates no supported protocols at the alternative endpoint, so= no client will ever attempt to make use of that record.
=C2=A0
Instead it might be clear enough to
mention the alpn default = value considers
DNS over UDP.

This draft does not currently offer any way to describe a= DNS over UDP alternative endpoint.

It also wo= rth mentioning that alpn needs
to be parsed before port and potentialdohpath.
</mglt>
I expect that a client would parse a record completely before a= ttempting to make use of it, so I'm not concerned with this dependency.=

4.3.=C2=A0 Other applicable SvcParamKeys
=C2=A0 =C2=A0These SvcParamKeys apply to the "dns" scheme withou= t modification:

=C2=A0 =C2=A0* =C2=A0echconfig

=C2=A0 =C2=A0*= =C2=A0ipv4hint

=C2=A0 =C2=A0* =C2=A0ipv6hint

<mglt>not sure we need this section as the
document is limited on the DNS
= transport.

Yes,= this is perhaps redundant.=C2=A0 We could instead adjust the wording in th= e SVCB draft to indicate that these keys are assumed to be broadly applicab= le.=C2=A0 However, I don't think it hurts to remind the reader of other= keys that they can use in this context.

I am ho= wever wondering if we should
distinguish between authoritative and
re= solver. =C2=A0

= This draft is not intended to be specific to one server role or the other.= =C2=A0 This is noted in Section 6.

<mglt><= br>I am wondering if ther is any room for
searching specifically doh ser= ver by
requesting:

_443._dns.resolver 7200 IN SVCB 1 resolver (=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0alpn=3Dh2,h3 echconfig=3D... doh= path=3D/dns-query{?dns} )

If that is not the case, it seems we
sh= ould clarify this.
The same case occurs with DoT, Do53.

The advan= tage would be that it enables
to narrow down the search and prevents
= the search of non supported transports.

This is an interesting idea, but the SVCB framewor= k does not support this approach.=C2=A0 With SVCB, the client sends a reque= st that=C2=A0describes a logical service, and receives an RRSet of alternat= ive endpoints covering all the service's supported protocols.

The downside is that it requires some
synchronization = between SVCB RRsets and
when multiple supports are supported by
one c= lient multiple queries may be
performed. It also may require to definesome preference across SVCB RRsets over
multiple domains.

Personally, I expect that s= ervers will typically implement only a small number of protocols (at most ~= 4), and clients will often support more than one, so transferring the entir= e configuration in a single RRSet seems likely to be more efficient overall= than issuing multiple queries.

</mglt>
9.=C2=A0 Security Considerations

9.1.=C2=A0 Adversary on the qu= ery path

=C2=A0 =C2=A0This section considers an adversary who can ad= d or remove responses
=C2=A0 =C2=A0to the SVCB query.

=C2=A0 =C2= =A0Clients MUST authenticate the server to its name during secure
=C2=A0= =C2=A0transport establishment.=C2=A0 This name is the hostname used to con= struct
=C2=A0 =C2=A0the original SVCB query, and cannot be influenced by= the SVCB record
=C2=A0 =C2=A0contents. =C2=A0
<mglt>
I unde= rstand that after the SVCB
exchange, the DNS client sets a TLS
sessio= n with the DNS server. I think
this is only valid when TLS is
support= ed and Do53 woudl not fit in this
category.
<= /blockquote>

Yes.=C2=A0 This draft does not provide a wa= y to describe a Do53 alternative endpoint.

It so= unds to me difficult to have a
requirement that says, when a https
se= rver supports https the session must
be authenticated.
=

I'm not sure I understand.=C2=A0= Authenticated transport is a requirement for HTTPS.
=C2=A0
=
I am tempted to say
that the https server should not serve
no= n secure sessions. On the other hand,
one can also envisioned the case w= here
a given IP/FQDN is shared by DoH and
Do53, which makes such assu= mption
difficult.
Unless I am missing something, it sounds
to me t= he MUST statement is difficult to enforce.

This section is only meant to tell clients to p= erform SSL certificate validation in the usual way.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
I think it is good to specify what name
must be present in the cer= tificate.
Though what is unclear to me is why the
name should be the = one of the query as
opposed as the one in the RDATA.

The RDATA is potentially untrusted= .=C2=A0 In the=C2=A0absence of DNSSEC, an intermediary could rewrite the RD= ATA to contain any name.

I understand the text a= s saying that
connecting to fooexp.resolver.example, the
certificate = should have
resolver.example.
<= br>
Correct.
=C2=A0
If that is correct,and unless I am missing something, I
would be more inclined to authenti= cate
fooexp.resolver.example.
One case I see is an ISP delegating to = a
DNS resolver provider - like akamai. It
should rather let the user = authenticate
akamai than the ISP hostname. Other
scenario could ignor= e the hostname and
use a footprint or the entire
certificate.
Of c= ourse this would require DNSSEC.

It seems such recommendation is lim= ited
to the case when DNSSEC is not used and
when the SVCB name is pr= ovisioned in a
trusted manner.
<= div>
Yes.=C2=A0 However, the service provider does not know t= hat the name was provisioned insecurely, and it does not know that the clie= nt is validating DNSSEC, so it has to include the service name in its certi= ficate.=C2=A0 Since all service providers will place the service name in th= e certificate, clients should check for this name, regardless of whether th= ey validate DNSSEC.
=C2=A0
If an attacker is likelyto update the SCVB content, he might
potentially have provided the fal= se
entry to initiate the SVCB query, in
which case there may not be a= ny need to
update the SVCB parameters.

I believe the primary reco= mmendation should be
to use DNSSEC and then consider the very
specifi= c use case where DNSSEC cannot be
used with a trusted SVCB entry. =C2=A0=
</mglt>

This draft's approach to authentication is inherited from SVCB, whic= h similarly does not rely on DNSSEC.=C2=A0 In both cases, I think the curre= nt drafts are taking the best approach.=C2=A0 In many or most of the antici= pated applications, DNSSEC is not widely deployed, and we do not need it in= order to deploy SVCB securely.

=C2=A0 =C2=A0Alt= hough this adversary cannot alter the authentication name of the
=C2=A0 = =C2=A0server, it does have control of the port number and "dohpath&quo= t; value.
=C2=A0 =C2=A0As a result, the adversary can direct DNS queries= for $HOSTNAME to
=C2=A0 =C2=A0any port on $HOSTNAME, and any path on &q= uot;https://$HOSTNAME", even if
=C2=A0 =C2=A0$HOSTNAME is not actua= lly a DNS server.=C2=A0 If the DNS client uses
=C2=A0 =C2=A0shared TLS o= r HTTP state, the client could be correctly authenticated
=C2=A0 =C2=A0(= e.g. using a TLS client certificate or HTTP cookie).

=C2=A0 =C2=A0Th= is behavior creates a number of possible attacks for certain server
=C2= =A0 =C2=A0configurations.=C2=A0 For example, if "https://$HOSTNAME/upl= oad" accepts
=C2=A0 =C2=A0any POST request as a file upload, the ad= versary could forge a SVCB
=C2=A0 =C2=A0record containing "dohpath= =3D/upload", causing the client to upload
=C2=A0 =C2=A0every query,= resulting in unexpected storage costs.

=C2=A0 =C2=A0As a mitigation= , a client of this SVCB mapping MUST NOT provide
=C2=A0 =C2=A0client aut= hentication for DNS queries, except to servers that it
=C2=A0 =C2=A0spec= ifically knows are not vulnerable to such attacks.=C2=A0 Also, if an
=C2= =A0 =C2=A0alternative service endpoint sends an invalid response to a DNS=C2=A0 =C2=A0query, the client SHOULD NOT send more queries to that endpo= int.

<mglt>
The attack is limited to DoH and DoT is
not = concerned.

Corr= ect.=C2=A0

This attack is targeting the httpsserver, but in general the motivation
for the client to authenticate th= e
server is to protect its privacy. It
seems this should be added or = clarified.
</mglt>

OK, I've added an explanation of why this is privacy-relevant = and strengthened the recommendation:=C2=A0https://githu= b.com/bemasc/svcb-dns/commit/e311a4e94edd67e17724e693ad2038396fba8b4f
--0000000000008d4aac05b5586ca4-- --00000000000094ef8b05b5586c1c Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPmAYJKoZIhvcNAQcCoIIPiTCCD4UCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggzyMIIEtjCCA56gAwIBAgIQeAMYYHb81ngUVR0WyMTzqzANBgkqhkiG9w0BAQsFADBMMSAwHgYD VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE AxMKR2xvYmFsU2lnbjAeFw0yMDA3MjgwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFQxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFz IFIzIFNNSU1FIENBIDIwMjAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvLe9xPU9W dpiHLAvX7kFnaFZPuJLey7LYaMO8P/xSngB9IN73mVc7YiLov12Fekdtn5kL8PjmDBEvTYmWsuQS 6VBo3vdlqqXZ0M9eMkjcKqijrmDRleudEoPDzTumwQ18VB/3I+vbN039HIaRQ5x+NHGiPHVfk6Rx c6KAbYceyeqqfuJEcq23vhTdium/Bf5hHqYUhuJwnBQ+dAUcFndUKMJrth6lHeoifkbw2bv81zxJ I9cvIy516+oUekqiSFGfzAqByv41OrgLV4fLGCDH3yRh1tj7EtV3l2TngqtrDLUs5R+sWIItPa/4 AJXB1Q3nGNl2tNjVpcSn0uJ7aFPbAgMBAAGjggGKMIIBhjAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHzM CmjXouseLHIb0c1dlW+N+/JjMB8GA1UdIwQYMBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MHsGCCsG AQUFBwEBBG8wbTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3Ry MzA7BggrBgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvcm9vdC1y My5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIz LmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5n bG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEANyYcO+9JZYyqQt41 TMwvFWAw3vLoLOQIfIn48/yea/ekOcParTb0mbhsvVSZ6sGn+txYAZb33wIb1f4wK4xQ7+RUYBfI TuTPL7olF9hDpojC2F6Eu8nuEf1XD9qNI8zFd4kfjg4rb+AME0L81WaCL/WhP2kDCnRU4jm6TryB CHhZqtxkIvXGPGHjwJJazJBnX5NayIce4fGuUEJ7HkuCthVZ3Rws0UyHSAXesT/0tXATND4mNr1X El6adiSQy619ybVERnRi5aDe1PTwE+qNiotEEaeujz1a/+yYaaTY+k+qJcVxi7tbyQ0hi0UB3myM A/z2HmGEwO8hx7hDjKmKbDCCA18wggJHoAMCAQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUA MEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWdu MRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEg MB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzAR BgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4 Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuu l9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJ pij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh 6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti +w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEA S0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9u bG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaM ld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88 q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/f hO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBNEwggO5oAMCAQICEAE/JGAv3XK3SRaKvGds QSwwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gQXRsYXMgUjMgU01JTUUgQ0EgMjAyMDAeFw0yMDA5MDgy MzQzNTNaFw0yMTAzMDcyMzQzNTNaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFzY0Bnb29nbGUuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7rjWsiqQSnXGFTvs/2JDygQFtWsgF+Ce W2I/wmwCuWH2eNUBYslyudWmJsUMi7IbeSsKHrvBI2P7k6sk5p6o3uFlomiFaDMqXcn76t5GNGym CmHm5KBWxc3LfyvR4C2/wg9oUwbL2xxXc6QQpWWE4ONn9NMHwNC396Ih5u7tcrH5eF49HbVarP5i TindWAOzz++JA3VC/1lIkqWvOt2BcBtxQDUnYp8sr8UnMF/6UqtCd0aHJnKkvYi4o8Qo5Qf3YgiJ DzADzBTf54o3NAI3hiIVKPvz1l0g78IcR29Bt9jUrE33qGzGB6HoY7Z8quhA/ngW2XjuLkIY1ZKX AwTXBQIDAQABo4IBzzCCAcswHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5jb20wDgYDVR0PAQH/ BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUu687mSaB85ui VgNNFSUhtTljkxEwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYmaHR0cHM6 Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wCQYDVR0TBAIwADCBmgYIKwYBBQUHAQEE gY0wgYowPgYIKwYBBQUHMAGGMmh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL2NhL2dzYXRsYXNy M3NtaW1lY2EyMDIwMEgGCCsGAQUFBzAChjxodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2Nh Y2VydC9nc2F0bGFzcjNzbWltZWNhMjAyMC5jcnQwHwYDVR0jBBgwFoAUfMwKaNei6x4schvRzV2V b4378mMwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9jYS9nc2F0 bGFzcjNzbWltZWNhMjAyMC5jcmwwDQYJKoZIhvcNAQELBQADggEBAG9R1/y5PatVOc8xLrAmGgNO /Q4+lbJuHNwX3aIpOkM72Ot4r6r5/IFOSx1pMpmzvrECyy5YQzUGkHV4atuNq5YPPNMGa+XlaKSg oU2dA6RCD40dtwmrPxrKiGAfHPNvfmRvgnx9qxBKFPbKF/Tn8BwKSZCSvx33TnQRfqLUTcgrAarQ dF9Oc45moJrn4nVF0VTTPI6LVminvjg3tLgF2bny1N6CitQnb1t67vpYjeNpcXNIGQzEDaYI3WnK rVeZMcLSY+Z2dQH8HvVsA95vFCTywgiWKq5KxFqz/GdB6JhDWcIJIKCJVUyqD/Bjx47+e4Ye/FuD NDSYc+613Ozl3TkxggJqMIICZgIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFzIFIzIFNNSU1FIENBIDIwMjACEAE/ JGAv3XK3SRaKvGdsQSwwDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIL+LWJmubixY JHUoD9201Lth0YE+SCq2gdfF707mwEBgMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTIwMTEzMDE5NTc0N1owaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJ YIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcN AQEHMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQByu4PJPQYkYZgA579eYaF04a0cLkMY qmlh4xXsliLPbUndV0CsXl7e8JU6W1bpE1BZsonE54OpEUXockWb53HRnCgeRiEjdu3L1cFAwGbx 3qS5rHUYV8plApI0dWPkVeJPZkNZ9Qe/oMbsT+IlEOsBykUvFmDNn+dvhRfBJTsUqCd4qHb13/gb kv64nau8pSEl+7vqS8xl5tpCkJobgcVwog/HkAksYH0cxPCT68FgOwzo7XtnM/+Qojp6qbyacdO4 MxRzBiY2Fcu8MXy8NNgO7eJCoBiSJxViYwtkyXRn8ZLRUtOzpHa/3rImnoNTNZ80v0/Z13dBFTan IjVJrLry --00000000000094ef8b05b5586c1c--