Re: [dns-privacy] Paul Wouters' Discuss on draft-ietf-dprive-unilateral-probing-12: (with DISCUSS and COMMENT)

"Rob Wilton (rwilton)" <rwilton@cisco.com> Tue, 19 September 2023 13:01 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A125C151067; Tue, 19 Sep 2023 06:01:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.363
X-Spam-Level:
X-Spam-Status: No, score=-13.363 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b="ES3bz/mX"; dkim=pass (1024-bit key) header.d=cisco.com header.b="BzFoNeg9"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id st4amDPW6aQf; Tue, 19 Sep 2023 06:01:00 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.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 2515EC14CE4B; Tue, 19 Sep 2023 06:01:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16500; q=dns/txt; s=iport; t=1695128460; x=1696338060; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=oLm8yPrUv5xSq14jeT2gV5UX1tyhwTH5Nyg9ULCQGpM=; b=ES3bz/mXmaki9d7Hd5EOWcTvJBct32XbqbuHqfDirWR0aXnWz4EUph0D NrRf+uVVwit2std5Q/VelrCv2DhkAXyQWT3O7Ilm2SNFzMeCC9wYuirfG U69dNvcCjygR81nOVRnYcvOlg01cDP23KQ6CC+dTAxUch+zFHAStl8JxA I=;
X-CSE-ConnectionGUID: IafpxhJaTeu9E5qAGGVp4Q==
X-CSE-MsgGUID: qdAtgZVIQcWE5N8ArYkEPA==
X-IPAS-Result: A0A5AADsmgllmJRdJa1aHAEBAQEBAQcBARIBAQQEAQFAJYEWBwEBCwGBZCoodwJZKhJHhFKDTAOETl+IYwOBE4pJhV6MQRSBEQNWDwEBAQ0BATsJBAEBghOCdAIWJxIFhigCJjQJDgECAgIBAQEBAwIDAQEBAQEBAQIBAQUBAQECAQcEFAEBAQEBAQEBHhkFDhAnhWgNhkcBAQEBAxIRBA0MAQEJARkHCgMBCwQCAQgRBAEBAwImAgICHxEVCAgCBAENBQgTB4JcAYIqAzEDARAGo2YBgUACiih6fzOBAYIJAQEGBAWBCgFDQa4HDYJJCYEaLgGHah4BUIEAhAEJhCwIHxuBSUSBFUOCMDg+giAYKgEBA4EoARIBBwIag1k5gi+JSoJ1ggUVLgcygQwMCSxZg1iBFIh+CSGBCAhegWo9Ag1VCwtdgRGCRAICETkUR3EbAwcDgQQQKwcELxsHBgkWLCUGUQQtJAkTEj4EgWeBUQqBBj8RDhGCRSICBzY2GUuCXQkVDDVOdhArBBQYgRMEagUaFR42ERIZDQMIdh0CESM8AwUDBDYKFQ0LIQUUQwNHBkwLAwIcBQMDBIE2BQ8eAhAaBg4pAwMZUAIQFAM+AwMGAx0DRB1AAwttPTUUGwUEPSlZBaBLA24rgUIIYwUBAQ5VBA0VDQwIECABDlEYASoXBAwDBwkFAQEoBgEEBAINLZIZJAqDEgFHmGiTdkdvCoQLjACPE4YoF4QBgVaLGIZtg0qNV2KYLSCNQYN1kS0EGIR9AgQCBAUCDgEBBoFjOmtwcBU7gjMBAQExCRYzGQ+EGYoHDA0JFnQBAoF1VIUUimV2AjkCBwEKAQEDCYtJAQE
IronPort-PHdr: A9a23:bxzdchDO/CycmJExIALJUyQVoxdPi9zP1kY98JErjfdJaqu8usikN 03E7vIrh1jMDs3X6PNB3vLfqLuoGXcB7pCIrG0YfdRSWgUEh8Qbk01oAMOMBUDhav+/Ryc7B 89FElRi+iLzKlBbTf73fEaauXiu9XgXExT7OxByI7HvBY/Wk8Ox/+uz4JbUJQ5PgWn1bbZ7N h7jtQzKrYFWmd57N68rwx3Vo31FM+hX3jZuIlSe3l7ws8yx55VktS9Xvpoc
IronPort-Data: A9a23:yBW/YK056I3A0W6PbvbD5Tpxkn2cJEfYwER7XKvMYLTBsI5bpzUAz zMYDzuBOPreNzP3Kd8nYNiwoBwA7JLVmNJlSlA63Hw8FHgiRegpqji6wuYcGwvIc6UvmWo+t 512huHodZ1yFjmE4E71btANlFEkvYmQXL3wFeXYDS54QA5gWU8JhAlq8wIDqtYAbeORXUXV4 7sen+WFYAX+g28tYzpOg06+gEoHUMra6WtwUmMWPZinjHeG/1EJAZQWI72GLneQauG4ycbjG o4vZJnglo/o109F5uGNy94XQWVWKlLmBjViv1INM0SUbreukQRpukozHKJ0hU66EFxllfgpo DlGncTYpQvEosQglcxFOyS0HR2SMoVn8bHfMXiduPCe0hzrLmLF7NpQFB0PaNhwFuZfWQmi9 NQCIzwLKxuEne/zmej9Qeh3jcNlJ87uVG8dkig/lneCUrB3GtaaH/WiCdxwhF/cguhUAvfae 80fQTFudx/HJRZIPz/7Dbpnwbfz3CekK2YwRFS9vKYe/2fh8i1I24fAbfyFU8a7RuhttxPNz o7B1z2pXk5FXDCF8hKJ9GnpnvXOgyrwSaoTGaG2sPlwjzW7ynQJCQMbEFC7qPijkWa/Vs5Rb UsO9UIGobI7+lDuT9ThUVi0uGSFoBNZRtxRF+Qm5RuEzu/M+QGTB24LZj9MdNJgs9U5LRQr2 0SGt9LkGTIpt6eaIU9x7Z+Opj+0fCMSN2JHPHVCRgoe6N6lq4Y25v7Scjp9OI+8gMXlGRP5/ z2X/QVjnpw8ovATi5zuqDgrnAmQjpTOSwc04CDeUWSk8h51aeaZi2qAtASzARFocdvxc7WRg JQXs5PBs71WXPlhgATIEbpdRuj4jxqQGGSE2QYHInU3y9i6F5eekW14+jpyIgJiNdwJPGazJ kTSoghWopRUORNGjJObgarvV6zGLoC5RbwJs8w4iPIVM/CdkyfcrUlTiba4hTyFraTVufhX1 W2nWcitF20GLq9s0SC7QewQuZdymHFjnT2KFcuqnk/8uVZ7WJJzYepUWLdpRr5hhJ5oXC2Jm zqiH5LQkk4GALGWjtf/qNBOfDjm0kTX9biv+5AIKYZv0yJtGXoqDLfK0Kg9dol+95m5Zc+Wl kxRrnRwkQKl7VWecF3iQik6NNvHA80lxVplZnNEALpd8yV5CWpZxP1BJ8JfkHhO3LEL8MOYu NFeJ5zcWKgTF2qZk9nfBLGkxLFfmN2QrVvmFwKuYSM0eNhrQAmhxzMuVlKHGPUmZsZvifYDn g==
IronPort-HdrOrdr: A9a23:iGcY4a9RxZGWa2ysApZuk+Gddr1zdoMgy1knxilNoENuA6+lfp GV/MjziyWUtN9IYgBQpTnhAsW9qXO1z+8N3WBjB8bTYOCAghrnEGgC1/qs/9SEIVydygcz79 YcT0ETMqyWMbE+t7eF3ODaKadg/DDkytHVuQ629R4EJm8aDtAF0+46MHflLqQcfng/OXNNLu vn2iMxnUvaRZ14VLXcOlA1G8L4i5ngkpXgbRQaBxghxjWvoFqTgoLSIlyz5DtbdylA74sD3A H+/jAR4J/Nj9iLjjvnk0PD5ZVfn9XsjvFZAtaXt8QTIjLwzi61eYVIQdS5zXMIidDqzGxvvM jHoh8mMcg2wWjWZHuJrRzk3BSl+Coy6kXl1USTjRLY0I7ErXMBeo98bLBiA1zkAnkbzZdBOW VwrjukXq9sfFf9deLGloD1vl9R5xGJSDEZ4J0uZjRkIPkjgflq3MwiFIc/KuZcIMo8g7pXSt VGHYXS4u1bfkidaG2ctm5zwMa0VnB2BRueRFMe0/blmQS+sUoJh3fw/vZv1Uso5dY4Ud1J9u 7EOqNnmPVHSdIXd7t0AKMETdGsAmLATBrQOCbKSG6XWJ0vKjbIsdr68b817OaldNgBy4Yzgo 3IVBdduXQpc0zjBMWS1NlA8wzLQm+6QTPxo/suqqRRq/n5Xv7mICeDQFchn4+ppOgeGNTSX7 KpNJdfE5bYXCLT8EZyrnvDsrVpWA4juZcuy6MGsnq107b2FrE=
X-Talos-CUID: 9a23:VeaFlG85cM6nnVmQDomVv28dFNg1cl/U8HrNcmLlEE9GZ4ONFWbFrQ==
X-Talos-MUID: 9a23:McvmuQv14vOHDtncZs2nnT1LKMha3YWXA38gzLNWktO1NgFIEmLI
X-IronPort-Anti-Spam-Filtered: true
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Sep 2023 13:00:58 +0000
Received: from rcdn-opgw-4.cisco.com (rcdn-opgw-4.cisco.com [72.163.7.165]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 38JD0w8R008939 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 19 Sep 2023 13:00:58 GMT
X-CSE-ConnectionGUID: damPfWUfQdSkgq6ePEe4BA==
X-CSE-MsgGUID: KKemrDghRAuFMrw4d7gb5g==
Authentication-Results: rcdn-opgw-4.cisco.com; dkim=pass (signature verified) header.i=@cisco.com; spf=Pass smtp.mailfrom=rwilton@cisco.com; dmarc=pass (p=quarantine dis=none) d=cisco.com
X-IronPort-AV: E=Sophos;i="6.02,159,1688428800"; d="scan'208";a="2475047"
Received: from mail-mw2nam12lp2042.outbound.protection.outlook.com (HELO NAM12-MW2-obe.outbound.protection.outlook.com) ([104.47.66.42]) by rcdn-opgw-4.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Sep 2023 13:00:57 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hRJLyIjZTVPV3O7dUWfZs+fSQDUpl07orHgHnJb3hDcNeBJGCxq7kXTJGM48oxuX0W9xkKR9A1jTWjWiORhpIcbsk6lFkp9TF1wj3/QEp6wCLtASZU5BEphFX3t1rzHs/fyPHFfGkbeEVbwARXv9rSTp01EyYJDzEzujhNmgu6QXb+iNZ6VthhN7CjXCOZ1JbvOyPiAb4423impwbzd3RoZQj8x/0kMBgy+I9/Pdlo2Zh9PvTGT5dQXQFvgc6KirJik+hiRMX1pehLPqePhKIYgj+Mc/vjOOVphNQUD4xURlaIuH2i1QlxA+im3HCJIXqQfGPK1ItcL+4u7SokjqjQ==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=oLm8yPrUv5xSq14jeT2gV5UX1tyhwTH5Nyg9ULCQGpM=; b=GcnfT+xoU8X3o9XIqVBjNRNvroO+sDMokm0EqDeUbLUspuEB6S3Op+Amw9pTbz8ga7QbLKAqci9W8nge+qHer8gs64qpJqreYMZpkqh3GKx3wXg1rCJtTcTqW/CT6DNCWNkpKF4Fmz/nJ3zvRfrCzykCnZNP/e11TZ4Ztag3y9AQn1U3Gzks+DX2J1JPARSDPHnYUHNGgZ5MtwtpWy3YWTDZQQ+V8TxPJwIxb090GB/xUgHlF0s83H6uppU2w1R5i1UjZXkeKghccYwE6SQNCxGzbfJ5BWiUNc8L6Um5e5nMsUBmbP9IoIPW/XoCu2gqcMMGvYqwsvMBzH+pSS+vMA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oLm8yPrUv5xSq14jeT2gV5UX1tyhwTH5Nyg9ULCQGpM=; b=BzFoNeg9XtvfmgBATI3FtbKDLXwZ6bzJ71Wo8FpL8Mh7CWRlZB9rlbYNOg6L43m0O2QAqH/IUliY6f7qPvpfFY2Iygqhi55PqFL0P9UjbnJ1wK32b17dLGFq5Mq7f7GXokIypE4S9uMJwmzjXv2m0ZY+Z8Cb1kVGVmRsxdn8C9s=
Received: from BY5PR11MB4196.namprd11.prod.outlook.com (2603:10b6:a03:1ce::13) by PH7PR11MB8504.namprd11.prod.outlook.com (2603:10b6:510:2fe::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6792.24; Tue, 19 Sep 2023 13:00:47 +0000
Received: from BY5PR11MB4196.namprd11.prod.outlook.com ([fe80::b2b2:e22e:3d6c:14de]) by BY5PR11MB4196.namprd11.prod.outlook.com ([fe80::b2b2:e22e:3d6c:14de%7]) with mapi id 15.20.6792.026; Tue, 19 Sep 2023 13:00:47 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Paul Wouters <paul.wouters@aiven.io>, The IESG <iesg@ietf.org>
CC: "draft-ietf-dprive-unilateral-probing@ietf.org" <draft-ietf-dprive-unilateral-probing@ietf.org>, "dprive-chairs@ietf.org" <dprive-chairs@ietf.org>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>, "brian@innovationslab.net" <brian@innovationslab.net>, "tjw.ietf@gmail.com" <tjw.ietf@gmail.com>
Thread-Topic: Paul Wouters' Discuss on draft-ietf-dprive-unilateral-probing-12: (with DISCUSS and COMMENT)
Thread-Index: AQHZ6qU6kEGBrHkexEug92UMeY3M6LAiGAhA
Date: Tue, 19 Sep 2023 13:00:46 +0000
Message-ID: <BY5PR11MB419692DC13F81876A33931EEB5FAA@BY5PR11MB4196.namprd11.prod.outlook.com>
References: <169509232457.44560.14598703024351975328@ietfa.amsl.com>
In-Reply-To: <169509232457.44560.14598703024351975328@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BY5PR11MB4196:EE_|PH7PR11MB8504:EE_
x-ms-office365-filtering-correlation-id: a4cba842-6b62-44c1-8bf3-08dbb91070af
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: +U30+avjT2+xm7s9dwWPrShTbDR32tfHOFklOsbD1c0d/wXZrGOC6giGGnxAoh0r5EAVJJpNMaTfHhbLpN0bNbu9oiYJ4+I1cB0JL+a0JaQ4mzBpQFgggroGJhzC5b9oVVk9AGPBWOr+AoiZ+aya+CKOql3HZ2ya46QVtCus4uFxh02PXz73TsTxPXEWSB6OTnP3fnqasR6tAo3qdycj0M54mTXNqUKrMgCZUixyO5KywFu+dvRrOMzba9BKVCreWACK17TLPCsl/b3ZF62FxRsglh6fS3wegw8XDPOzDI88EFo/hBCAgeMZVR8eAckj3fy5NCc+xungOH4NT1zDT9QiLiwwP33K93uQDu30+ntYL6IZBDNccUVOjCM7r+vAfTLjqaXhAyRzqQ/364GZFM6bvqphdSVloYsgbAHEMBWQ08Y0muEfsc0KIBeGvyx66tmUuet3lU1vfiuzcNzVYng9DYROHl4LLz7Lrgz+5/zUpGF/o2aH4HfwAP+bUGpKh50a2hmG2GjHqvUcOHr8qr7XIdhfQJRYidBiOjjF3gx4aq883cBzMForgF1KUq7Jxrsj4nRllcHcCk6T0BMJPsl7VSJXWL4Lj9Vkf/5B+A3C/9bN4XCF0o9aCSCJEfszc2Sx+W6bgGjWkZoq2NnCjO0wzk3J8Fm5eHZy6k6gRKSpn/aaG9fR+aatlrT+oQDe
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4196.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(6019001)(39860400002)(346002)(366004)(136003)(396003)(376002)(1800799009)(451199024)(186009)(5660300002)(66574015)(41300700001)(64756008)(8676002)(8936002)(4326008)(54906003)(76116006)(66476007)(110136005)(66946007)(66446008)(66556008)(52536014)(55016003)(316002)(122000001)(30864003)(38070700005)(38100700002)(83380400001)(2906002)(66899024)(478600001)(966005)(33656002)(6506007)(53546011)(7696005)(86362001)(71200400001)(9686003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: l8wCjPDSG6Y8l/WL8KCng3JeGG7LrV4FiiNIngWbxM8z/PEf5lULgqmgNOh9Q7OdDe2jbh+eloL4Moel79W9j1RjyJ2caiPyjdCYNoHTiA++R7yHjHsM/LimIEPD+Ew7eXHivjZ7hOEqIXCJU3MGxTrktjy7nt4GlBs0ExjYMiev0AyAj8CQgNkvf7JTZh8V0D4pV1RPfgPM1Hb22omp4vVr1OFW1M2nrSqZvUHUV31CQowTSyF3MKR228mZCBZ5ipDrp14vGznH8eDo2on4paR5DNIM2UohD+M/vgGAa9NVLzyVOCUSj/110rJIYQYswfXKSDRcChNtaOXIswoqhGPNebZJKRUmv5WBGU5UD1G0WwiIXsxTJv1UV3uBDegIHAQaUZMrAiG86CM440QVr8+Rg+ga/dVXVWhF1hpYkuP4rDNhhaXmmCCRBUj6nCkEwSXirE6SZZNW6sgulITMF6RvEHZkHBUbBJQdVw/k8nofBUQnDo2e8iltRKHbrsgGW4RcCQ1KXJGq7UAO9qkX1uqro/eP2HpSNZ9We0J2KK7ZNGTUmcP5DyW7lbz6fWGHH/NFez2kUM3FEJ67ogq+BrLQkqy9IGwnmmThUAFohe920GOF9y1B0p159HSSkYWT0rKY4pAhMYcAWsDaCCi1PSCaazPQobzhC+q801AGY2i+l1PkVaIJbSvf3qhIdLpSIPfYfw9iOyef4tdkdQuAt8xl2kvOlEH2RsRYFEnUwtsu1+FZjxMP8sv0o7hZqlAQrbIs5NMjnnIcY2Lka8DY1FAZldYnbGlU1h6fUnHe/PzC5RIq+3nu6n5wQhrVfEB0ZfmG66UbqyldF1LKCVAJu8et7ZDGsp1unY25PjESRBJ8Wt03R+TTKXZhuunSmVOE+h7vsnhSsorp0/A3pQSSszx41xIf6D+su3+Y2Md3bdeYk1SH1kCYn2zpGVCnmTqZHid41D+aaoY94VXhE3xTxwH3f5pn4+SarAsmdpiEKyVV3mHITbg8aBwNCtDh+prf/v4B4o1LbR+zZ3iBHma+WCwmxSXx460hWM/6QIV4WwOERcHBm41s6T0kacuspNhJX2U0US672vey/b1TtvWFssNnc7ILmz+BA/sIYRetR9sLWSsG+eDwogxV/sh2f2oE861h+vgouvDZ+LIWBquERAQaBJo0QTUWzFt8eqSE9US84qSz2hCyTmaFzZqeVqe8TQ8+O+LRUWsJxE7RClFv08WyzWh9c9rCI43c3Ae06VrvKwyonSKSMJrHN3DVlZ99bBsshiiMVLrLQWYprh/b7xZS9pttW7dTE1EApgKilmcYzNA0tDdR+HORweOAZZIlkyLyXGOB1/Yd/uR4epLWe6CgODUehR/b/+tQBjcFa3aVrOf4BtqMG2K5JmG7v7gEKNzE0hsDQwz16Gv0msfd4XXk2Op7ZlNpyp6xPHDFlu06eiDtWXxYgTxmfLOTN90bC+F4jkkgj5wN6Qyauu4v8DA8ZuGvRHl7Hmx0mCel8ICXAUvlOor3ZULqE++d+vDHYofM2pl6NeYN4jgLdQcegsg6Q0Xc7b8wkupJHHXkx/jk5VoB601rp4vAYcG1Sn/aD01emx1LaK7v7n9BDAKFweI7hEaIZ/T2ih0wpT1pWoa6UHJE/16QGUFAaPD5fs4K
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: cisco.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4196.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a4cba842-6b62-44c1-8bf3-08dbb91070af
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Sep 2023 13:00:46.3967 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: FswIgj2rUPU74ZhKzsMkYPKLnGy2vmIlhzP5mLAG9EsfffkVTNmnFOCCoZDByHthcqBMWoaYp66Tt1o+OkVCvw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB8504
X-Outbound-SMTP-Client: 72.163.7.165, rcdn-opgw-4.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/ZsEOx-_w11nlYC-AfUkiOalPvtw>
Subject: Re: [dns-privacy] Paul Wouters' Discuss on draft-ietf-dprive-unilateral-probing-12: (with DISCUSS and COMMENT)
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Addition of privacy to the DNS protocol <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Sep 2023 13:01:05 -0000

Hi Paul,

One question/comment on one of your discuss comments inline below ...

> -----Original Message-----
> From: iesg <iesg-bounces@ietf.org> On Behalf Of Paul Wouters via Datatracker
> Sent: 19 September 2023 03:59
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-dprive-unilateral-probing@ietf.org; dprive-chairs@ietf.org; dns-
> privacy@ietf.org; brian@innovationslab.net; tjw.ietf@gmail.com;
> brian@innovationslab.net
> Subject: Paul Wouters' Discuss on draft-ietf-dprive-unilateral-probing-12: (with
> DISCUSS and COMMENT)
> 
> Paul Wouters has entered the following ballot position for
> draft-ietf-dprive-unilateral-probing-12: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-
> ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-unilateral-probing/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> # SEC AD comments for draft-ietf-dprive-unilateral-probing-12
> CC @paulwouters
> 
> * comment syntax:
>   - https://github.com/mnot/ietf-comments/blob/main/format.md
> 
> * "Handling Ballot Positions":
>   - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> 
> ## DISCUSS
> 
> ### Leaking probes
> 
>         either or both of DoT and DoQ concurrently. The recursive resolver
>         remembers what opportunistic encrypted transport protocols have
>         worked recently based on a (clientIP, serverIP, protocol) tuple.
> 
> This makes little sense to me. If the passive attackers sees the outgoing
> port 53 cleartext query, it doesn't even matter if DoT or DoQ is then
> established in parallel. The privacy is already lost. I strongly believe
> that DoT/DoQ should be tried first without unencrypted DNS, and only when
> that doesn't work in a very short time (eg 3s? 5s?) send out the unencrypted
> query.
[Rob Wilton (rwilton)] 

This makes sense, but do we know what proportion of authoritative servers will have DoT/DoQ enabled?  E.g., is this something that the latest version of common DNS server software enables by default, or does it require extract proactive configuration?

I can imagine that if lots of users hit a 3-5s delays for their queries then that could be really annoying.

This is also potentially something that could be changed in the future.  I.e., default to also sending in the clear now, but with a plan to subsequently change the default behaviour a couple of years down the line.  I.e., a phased migration.

Regards,
Rob


> 
> ### DNS cache handling
> 
> It does say anything about what it expects should happen with the
> cached DNS data through a restart. Note that dropping the cache
> and restarting, especially on mobile devices, will lead to easy
> fingerprinting for passive attackets in recognising users when
> their browser tabs reload (eg if queries to apollo.ns.cloudflare and
> katelyn.ns.cloudflare.com. happen, even when encrypted, it could be
> a sign of the mobile device trying to reach the ACLU. If that same IP
> is trying to reach ken.ns.cloudflare.com. or jill.ns.cloudflare.com,
> it could be that ietf.org is being looked up. The two of these combined
> would most likely mean the device on or behind this IP address is dkg)
> 
> While I understand that DNS cache handling over restarts is kind of out
> of scope for this document, if this document is being read as "how to run
> a DNS resolver with maximum privacy on your mobile device" then without
> this advise, the whole unilateral probing gives us nothing. (note: in
> Fedora I had this exact issue, where some people insisted on purging
> DNS cache on interface change, and I insisted on keeping DNS cache, so
> the NetworkManager got an option to tweak this behaviour). DNS cache
> handling for DNS resolvers on non-mobile devices, eg those on static
> IPs shared by many independent clients, might not need to consider this.
> 
> ### Section 4.6.2 Pseudocode
> 
> Either I don't understand the pseudo code, or it is wrong:
> 
>         Otherwise:
>         * Remove Q from Do53-queries[X]
> 
>         If R is successful:
>         * If Q is in Do53-queries[X]:
>           [...]
> 
> Since Q was just removed from Do53-queries, isn't this condition now always
> false ?
> 
> Also, what is "R is successful" ? because that seems to happen before
> "R is further processed".  Wouldn't processing be needed to determine
> if R is successful?
> 
>         But if R is unsuccessful (e.g. timeout or connection closed):
> 
> But the whole state starts with: "When a response R for query Q arrives" ???
> 
> ### Section 4 / Section 7 : Security advise
> 
> Should it not clearly state the resolver MUST enable query
> minimalization? Otherwise, sending queries to the root would leak all
> privacy even if the TLD supports DoT/DoQ. Or the same one level lower
> if the TLD doesn't support this yet.
> 
> Possibly it should RECOMMEND (or even REQUIRE) using RFC 8806 to prevent
> leaking root queries.
> 
> (I noticed later this was mentioned in the Security Considerations, but
>  I think it would be good to promote those into Section 4 as SHOULDs)
> 
> ### Zone owner recommendations ?
> 
> Should zone owners get a recommendation for using out-domain nameservers
> to reduce leaking at the root and TLD? Eg if nohats.ca uses ns1.example.com
> and ns1.example.com supports DoT/DoQ, but the root and .com do not, then
> queries for nohats.ca are not leaked to the root or .com. While when using
> in-domain nameservers, the target domain is leaked.
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> ## Comments
> 
> 
> ### Section 3:
> 
>         An authoritative server implementing DoT or DoQ MUST
>         authoritatively serve the same zones over all supported
>         transports. If both DoT and DoQ are offered, a nameserver's
>         reply to a particular query MUST be the same on both transports
>         (with the possible exception of how the TC bit is set)
> 
> I think there might be more differences, eg EDNS0 options related
> to packet sizes.  I think what is meant to be said is:
> 
>         An authoritative server implementing DoT or DoQ MUST
>         populate the repsonse from the same authoritative zone
>         data and the unencryped DNS transports. As encrypted
>         transports have their own characteristic response size
>         that might be different from the unencrypted DNS transports,
>         response sizes and response size related options (eg EDNS0)
>         and flags (eg TC bit) might vary based on the transport.
> 
> ### Section 3.1
> 
> As Éric Vyncke also commented, a third option could be to ensure
> that the load balancer knows/probes which ports/services are
> available on the servers being load-balanced, and only sends queries
> for those ports to the authoritative servers responding to that same port.
> 
> ### Section 3.2
> 
>         The simplest deployment would simply provide a self-issued,
>         regularly-updated X.509 certificate.
> 
> Why does it need to be regularly-updated? The even more simplest solution
> would simply generate a certificate once only and use that forever.
> Although perhaps it should be made abundantly clear that any DoT or DoQ
> TLS ciphersuite MUST be one with Ephemeral DH. (so passive attackers cannot
> be given a list of known certs private keys for instant decryption)
> 
> 
> ### Section 4.2
> 
> ICMP port closed message should be "ICMP port destination unreachable" ?
> 
> ### Section 4.3
> 
> A damping value of 1 day seems very long. What discussion lead to this
> value instead of say, 1 hour ? Is a factor 24 that important?
> 
> ### Section 4.4: MTI
> 
>         To follow this guidance, a recursive resolver MUST implement at
>         least one of either DoT or DoQ in its capacity as a client of
>         authoritative nameservers. A recursive resolver SHOULD implement
>         the client side of DoT. A recursive resolver SHOULD implement
>         the client side of DoQ.
> 
> That's a pretty odd way of saying:
> 
>         To follow this guidance, a recursive resolver MUST implement
>         at least one of DoT or DoQ but SHOULD implement both,
>         in its capacity as a client of authoritative nameservers.
> 
> (I think the "in its capacity as [...]" can also safely be removed.
> 
> ### Section 4.4: localhost
> 
>         SHOULD also accept queries from its clients over some encrypted
> transport.
> 
> Maybe add: unless it only accept queries from localhost
> 
> 
> ### Section 4.6.1
> 
> As stated in my DISCUSS, I still think a 3-5 second delay for unencrypted DNS
> packets is required, or the gain of unilateral probing becomes next to
> nothing (at least unless the entire world uses cloudflare as auth servers)
> 
> ### Section 4.6.3:
> 
>         If the recursive resolver has a preferred encrypted transport,
>         but only a different transport is in the established state,
>         it MAY also initiate a new connection to X over its preferred
>         transport while concurrently sending the query over the
>         established transport E.
> 
> I am confused by "preferred encrypted transport" and "established transport".
> Is this trying to talk about only encrypted transports and less and more
> preferred ones? Or does this include unencrypted transports? If the latter
> is included, 1) see my above comments on delays on do53, and 2) a UDP 53
> transport is not "established", only TCP 53 is. In which case, "but what
> about UDP then" ?
> 
> ### Section 6.1:
> 
> Would it make sense to recommend an SNI using the IP address in presentation
> format as the SNI host_name? eg I assume that would be the same as the
> SNI for a request to https://192.0.2.1/   ?
> 
> I'm not sure if it is well supported these days to omit an SNI in TLS
> libraries or not.
> 
> ### Section 7
> 
> See my DISCUSS on leaking do53 and localroot / query minimalization
> 
> It does list the leaking happy eyeballs. I still believe as mentioned
> earlier, that at least a brief attempt should be made to avoid leaking
> over port 53 immediately for every new nameserver contacted.
> 
> Ahh, I see now that local root and query minimalization are mentioned.
> I think these deserve to be more than just Security Considerations,
> and be part of the rough specification of unilateral probing as this
> document defines.
> 
> ### ection 8
> 
>         and the system would need to be able to differentiate queries
>         for recursive answers from queries for authoritative answers.
> 
> Isn't that just core DNS functionality (eg the Recursion Desired (RD)
> flag and the query ID) ? I don't think this is an operational consideration
> for unilateral probing.
> 
> ### NITS:
> 
> awkward sentence: The simplest deployment would simply [...]
> 
> with two A records -> with two address records
> 
>         This document uses the notation E-foo to refer to the
>         foo parameter for the encrypted transport E. For example
>         DoT-persistence [...]
> 
> This took me a few reads before I understood this. I recommend:
> 
>         This document uses the notation <transport>-foo to refer to the
>         foo parameter for the encrypted transport <transport>. For example
>         DoT-persistence [...]
> 
>