Received: by ietfa.amsl.com (Postfix) id 1971BC14F6EE; Fri, 19 Jul 2024 11:47:43 -0700 (PDT) Delivered-To: ietfarch-httpbisa-archive-bis2juki@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17AA8C14F6E4 for ; Fri, 19 Jul 2024 11:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 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, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MAILING_LIST_MULTI=-1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, URI_NOVOWEL=0.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=w3.org header.b="EPmnW1LL"; dkim=pass (2048-bit key) header.d=w3.org header.b="FgrgoxUS"; dkim=pass (2048-bit key) header.d=meta.com header.b="G+oy2Kgo" 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 WjmJzYBNjP3K for ; Fri, 19 Jul 2024 11:47:38 -0700 (PDT) Received: from mab.w3.org (mab.w3.org [IPv6:2600:1f18:7d7a:2700:d091:4b25:8566:8113]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52637C14F617 for ; Fri, 19 Jul 2024 11:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Subject:MIME-Version:Content-Type:In-Reply-To:References:Message-ID: Date:CC:To:From:Reply-To; bh=4esm7m6sfkueno2qYKUoyKrIIwWnh3a1R1gNdlsBTs4=; b= EPmnW1LLkByMZt5EE6Q1IrkFqRiFMn6PSMvTlT83FgoLFY5IFprMPym0SNJ+FmrbG6a8obkfx8rC9 xE47Cuqi8txL2GdBib/Bmztpf5BjQ73ANmiyaOtpiRTsweLxIx0HoOsSYOEoJI0oFiE3Dq/8MFslM t8/nlxD99Vir8+xWX3lCqzmTn4tAnIp57iZxpGpzRW5GHoA0VcNMTPXEb9ZyPYYfzknpeidFRBRxm TpqnKQkxZfnlXIa0CxoQefosZevqrhwWg12h9lNLLXQzAyDedLcYAIIvSN8zFRNwsFtuehBzvibMV Efj3rK3Lrh27Mf9QL0g8ZzKO9DmxCILojw==; Received: from lists by mab.w3.org with local (Exim 4.96) (envelope-from ) id 1sUscm-00BRCH-0y for ietf-http-wg-dist@listhub.w3.org; Fri, 19 Jul 2024 18:46:36 +0000 Resent-Date: Fri, 19 Jul 2024 18:46:36 +0000 Resent-Message-Id: Received: from ip-10-0-0-144.ec2.internal ([10.0.0.144] helo=pan.w3.org) by mab.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1sUsci-00BRBL-2L for ietf-http-wg@listhub.w3.internal; Fri, 19 Jul 2024 18:46:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=MIME-Version:Content-Type:In-Reply-To:References:Message-ID:Date: Subject:CC:To:From:Reply-To; bh=4esm7m6sfkueno2qYKUoyKrIIwWnh3a1R1gNdlsBTs4=; t=1721414792; x=1722278792; b=FgrgoxUSOfNdE0FNytlklMMGD1gXpGgviueZsM/pt0zuDiN RU4UXktgX15z6mYPN6ern85dDqXsCqyEs9pjLIQ/fT3k0zeErcpNopQcf5cnfK1x5LE7BqM/bNOqT QMMPk+pg+jYGhiwo2AQ1G8NJYfv5L++sGVSMFLhFeVFPfjky/DWrlDljUBiBVmyhX67s7tF5rSteG 5tC9xQ5QI8MUysn+eg7R32RZoLxAxKeYqIQ2xrxy3Fw80DI2i7X+LCPFaPnQf+q3UWJoa2DFOMqVP Pbwj/zxrp9BgwthdnCkf9p3gaq/DdTZKB6nJimytWo0VnOa/9ppalPUlzJiu70mQ==; Received-SPF: pass (pan.w3.org: domain of meta.com designates 67.231.153.30 as permitted sender) client-ip=67.231.153.30; envelope-from=prvs=29302ad992=bemasc@meta.com; helo=mx0a-00082601.pphosted.com; Received: from mx0b-00082601.pphosted.com ([67.231.153.30] helo=mx0a-00082601.pphosted.com) by pan.w3.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1sUsch-00AZiC-2j for ietf-http-wg@w3.org; Fri, 19 Jul 2024 18:46:32 +0000 Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.18.1.2/8.18.1.2) with ESMTP id 46JHlDc9031280; Fri, 19 Jul 2024 11:46:26 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meta.com; h=from :to:cc:subject:date:message-id:references:in-reply-to :content-type:mime-version; s=s2048-2021-q4; bh=4esm7m6sfkueno2q YKUoyKrIIwWnh3a1R1gNdlsBTs4=; b=G+oy2Kgo765PhqKPVOfGp+EA0N48Sc7D ICubEBbnKgVZTMh6ctW0QLTXHxGzU2cBVUmRFrRfu52mxDMA6rZKQWemqZJAddqw RjFqglDGsJDIpsZ6gKXsrDmxDfT5pMDybM2IttJ+XLQOCYLwD7LQm52a5ghcVPgY JnqRGZp+14jHJYu7rw/wGXQplH4OVbnib1tl9/OVRn6iGh20eQ3nr/IQ9TDdbXS1 OPgbKdIZxmLSa8dTJ541ygayali/pe7p2MPs59a+RW+KTeiwkfAJn2byxzGiJtGz e7Wbv513U9gJkq9AHnDTp0cFtyG9WRm70r10CSbmHjKCEY8ZHqQLHg== Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2048.outbound.protection.outlook.com [104.47.70.48]) by m0089730.ppops.net (PPS) with ESMTPS id 40f1p0arvv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Jul 2024 11:46:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=IJ81HWj3SRYn3tlP8byFOjxFkyHSE/Nyn/Q72XBNLy1NpzUrAx2v34pX1zCPrMoHKNptcnOAvcpj0aWysESRmVT1grmfPMh1NiWEwlKF4Hdz0fHBibCP1uB2t3eqgq+3ODwUiRmT1RZHTb7mXZUZqfjTBk7TaL9RE2sT8oZdLQbmhkqJnVvg47PsoWaZrpdYmyJZF6p3Blm6B/U3SteyM6ykf2OlZmfv6qoaT0J9uD6F31MPIJ5FQ6lxpxzApOsaflj1vz6n6TOh0FMueO3YIMTgtFCmn5ACI+8tp71NtwgJmLq18DVjwfQCA54Gx8+vIenHMDc2o1CvnlXbCuka2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=X9ZyMQSeef0XxuHNxXfcUAfhiz2cJ51P6JqR3j4Spzg=; b=J3kUiEtq93PZeXZN4mP18FR0/A6hwcytNPoktSH0yOqgyywJ+29YtSFTkuF8eYPuF0ON4fVhRQWBveL1ZEOcdfbFarg0nA4dT4lJfWflW6SD4P+dr7MLD11mFtm8ak0Twf8waaP596cMxbz4DUD3lS+CupMPPwSLqXACoV/w4mVw7dUBT6ivay4NjxH3MnZBqPjA1pMNhGwZYeYyfldmCH1xUOiB13HxVzJmqMhbBt0d8KpAlkes28iYx+nukoS91D7Yh8umHjHdjVwA/Jp7O+xcrfQh2AwjSyUpZEoYixzIBFhjKmhxSQBXG82/ZLLhkNhXcdNk9r3b20xvUCuvaw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=meta.com; dmarc=pass action=none header.from=meta.com; dkim=pass header.d=meta.com; arc=none Received: from SA1PR15MB4370.namprd15.prod.outlook.com (2603:10b6:806:191::8) by PH7PR15MB6476.namprd15.prod.outlook.com (2603:10b6:510:2ff::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7762.29; Fri, 19 Jul 2024 18:46:09 +0000 Received: from SA1PR15MB4370.namprd15.prod.outlook.com ([fe80::b6dd:72cc:243a:babb]) by SA1PR15MB4370.namprd15.prod.outlook.com ([fe80::b6dd:72cc:243a:babb%7]) with mapi id 15.20.7784.016; Fri, 19 Jul 2024 18:46:09 +0000 From: Ben Schwartz To: Josh Cohen , Watson Ladd CC: David Schinazi , "int-area@ietf.org" , "ietf-http-wg@w3.org" Thread-Topic: [Int-area] New version of WPADNG Thread-Index: AQHa0Zg2JDYzjQEQdUKPk4eTrPLs07Hu8iMAgAypYACAAAlrgIAALlkAgAAG3ICAAK+wgIAANIaAgAGzHoE= Date: Fri, 19 Jul 2024 18:46:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SA1PR15MB4370:EE_|PH7PR15MB6476:EE_ x-ms-office365-filtering-correlation-id: 40e97fda-e640-4f15-c4a0-08dca8230e66 x-fb-source: Internal x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700018; x-microsoft-antispam-message-info: =?utf-8?B?dU03SGE4N0FoMkxuUXpFTlpJWTVTWWZXd3Z5ZCtxemlGZ1hGR2xNSFhEUGRL?= =?utf-8?B?dUE5VDhUR3RTK3I0cEkzTXhZSUI2RGFZTFVmS3NUNlZ6UHBNaXM3L09KK0R1?= =?utf-8?B?aUZrMHY1WmpaY2JBTWV5NUIxa3YzS0UyR2F5WndjOHIyemVJemFtcE54Tmxh?= =?utf-8?B?amdoR2hmYzZWbTRXdDVJVGJnMXNxZTMrR0FzZ0JTSEsvb1RpSjFVc1V4bUpC?= =?utf-8?B?aTFNNndSNUYyYmZMK1V3RXA1bGgxYU5DdHlUL2dpUGg4OG80RExqUzdTdXlv?= =?utf-8?B?cmxJV0NwRHZiT3hybVVJeEJUNklBN0hwYnVrbzVlVHV4VThPb2k5L3RNWVc2?= =?utf-8?B?N1Z1K1hjRmxGdjgvUzBpRSthQkFmbWJuOU5iRXVVaWNOK0RBOHJ2TmNKZkI2?= =?utf-8?B?aHUySE5FODJaVmo3dldTNDhnYzY2eVdUcG45RHpaR1Z3bnp5RmZiNktsSHhn?= =?utf-8?B?c3pIVlhWeDdQVE9VRU9pSHU4ZThqdnhQMHQzeUNNYkpKeDNsOGFERzh3L1h6?= =?utf-8?B?dUtjMk01eVhpRjhpQ0JTT0NGUUlWYk0xYTlEUm1pNDZZSmhGU0QxVS9wbHVn?= =?utf-8?B?ajZINlZFS0dLQ0lpNW1TeERCbXVXQ0p1bHV6MzY1YVRzZ3pCYWIyL3pyMUo5?= =?utf-8?B?N2lDa2Z5bTdhdUg1QSs2Z09IWll4RG5UK3hwUFQ3cDFqeGpUOHB6L2VnSjls?= =?utf-8?B?YUVYQmQrMDJTTEZkaHBjTWF2ODJHV3dZbHd5R3RkKzhLR3RLU1V1UldEWVds?= =?utf-8?B?ell2Nm1xSFNhODdScDFBcWtQOG9GSjRLY2xOVWxRWmd4aHJ6OVdMMHdSUFcx?= =?utf-8?B?U2dycG1lOWl4ZCtRQ25lbXBOMlpZaEJ0SUw5dGw5K2t6VDN3V1ArVXNQRlls?= =?utf-8?B?Wkt3NDh2V0o5Q2RTaW9jUU96ZnhSVzFyN0tFbWNpR3BSK2FXWnI0aEkwc2gw?= =?utf-8?B?KzNZdW1QTEZ2aDBxUjFGaCtHVUd0YUVGWGkrdVMwaUtxQ3BXaklOdm9QQkFv?= =?utf-8?B?VjFNV1pkZGJ1d2NrM1A5L1Y1ZnhWNVJHYVNZaTl5S1FyVDVqVFBsTkxHZlJY?= =?utf-8?B?UVhIVC9ScHRwbXVyM2k1enAwQWgxMVdGK3JMRUhwZFRLN1FHZ0JaeE1sc011?= =?utf-8?B?RnliY2FQTE9CZUc1eU9RVUY3Uk1MVnQxaFRFdmxlaGY1cVhGeFU1WDF4RUZS?= =?utf-8?B?OTh5c01PR2JiRkJzamZyam9nZG5zcjY1eVhkKzBvK1p1bXFtaGhEUWN1VVhH?= =?utf-8?B?eXlkczNpbEtvWWx4Nm5vLzY1cG1yR3JydElJY3hrbjFEYVdWM1JVK0xlRkNw?= =?utf-8?B?eGZFckVuVW14RnE4Ny9zSnZnUlllS0hNZkQyTFdrZTNRcVV0eXQrN2JvSkhU?= =?utf-8?B?OVlEMElqckUxZEttNUZENjU3L003WWszTitiMnpVSjhVVUtvYlFGTDBtdWpp?= =?utf-8?B?VEdKOGdXQXhGU01TK2J0K0Y3UzZXaGtSa2FMeHFXR2ZUWUh4UkpaT0Z6c3hP?= =?utf-8?B?V3BaNmpvdzgvK0pxZFVnK0dDcHgxL3I3YmxBcTdKUVU1MmNDUHVsY1Bsd1Rm?= =?utf-8?B?RFZwMnMzTVYvNzlYVmNDRENNZURNSW1jNG1zSko4L21vdnhCWU5NV01ad2xT?= =?utf-8?B?UnNHeDBXNWs2TnhuZVpTaVNSbndDQ1ozYWQyaXAxWjlvTWMzdzh2dWxYNldN?= =?utf-8?B?RTdOY2RXdDRPdzJIQVhoQ0VDVWdzOVg3NUVnUDd4ZmdIY1BDS1dtMFRSVWNv?= =?utf-8?B?Z3FsZklFS2Y1SnU1dHVlMUdEdElCMytyY200OUtUVFRzQUV0ZzdKS1hGVTVK?= =?utf-8?Q?a6PGH6FIrq8x+i3zfDfgtnHapYtKcYSFvheoM=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA1PR15MB4370.namprd15.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?cndFMnNtM0MvY3pXaHlPb1BTQW1Va0lqSmZPeDBJVk13QjRsZWpBVFFMVHpU?= =?utf-8?B?QitoVDdhQkpMVHJUVlR6UFFqWHRMY2xZS01QZldTcnQ5SkFFWmg5eGNrL1lL?= =?utf-8?B?ait4bWkycHVqa3BXUDhOUFk5TWs5WVk1blM4TjRvOGh1ZjUxSFhOeU9SeXB2?= =?utf-8?B?eWdjVUladkF2N2dtVGowRjZ5bFZkVWplTnBmQ2hBbFJVYk5SSGF0NEhLdXlB?= =?utf-8?B?UkMyWnFlbWFpbllaSlk2RDQrbzVEb0Y1M0RxUlZCZnkyRlhKUkFzc0VOWG5Z?= =?utf-8?B?L3FyVkZ2cVZUelByOGZsK2U2M2hIZDlTSmtRTk1uTC93U0J6aENBNHJnQW41?= =?utf-8?B?U1VsRGpVcWJTMzNTS1RFOU4wV3lReDFldlgxSGQ2RXhBaGJDMFZ1aUM2ZnNm?= =?utf-8?B?NW5qVDdrd2ZxZW90NE1rSDRFb2F5eVRjTnE0dGoya0N3c09pK2liNVJ6UWlo?= =?utf-8?B?Skl6MUFYT1NBMHZIUDVJTUJiQlJJanNMWmpOSUhXeXppMVpRTlJ0NEcycXMw?= =?utf-8?B?aUJYZkdMaXBPVHBhbEd0UkRXV0xMb3NzcVE1a096ZE5jOWZha3lacVJKWW45?= =?utf-8?B?ZGZKbVZrTVorRWFIakQ3a3NXaVJvNjJzemRNc01Id2lhNFR4ZkN0Tk9PUUFJ?= =?utf-8?B?OWZXbVJkVE9zWFJXWFIrNHFMaGdPOWtKMUdIc0RLLzkxVmVveVJrWUY0alhC?= =?utf-8?B?Y2dEaG5QYXgvUVhnUW5tRnVCYkQwRnIvZ0dYejVkc1RRWEJLRjEyUVVocE1G?= =?utf-8?B?VzhwZGMzaUkzN1hEcUp1YUV6ZnZSNWFLVXQ1N2xreXN3ZWlHc2VsYUdrbGlH?= =?utf-8?B?QzFUTC8zaFk2b08vTnI5ekZzVFpZVkpoQ0k4V1J0ZDBaL0RCR2NlbG5KL3p5?= =?utf-8?B?MEFzNWdINVJsN0NHZkN2N2xtUXZTNGdHRjR5U2E5bUxUSzJQNCtUaE1IOW43?= =?utf-8?B?ellFdjVJcS9YQ3diWjN1VklRZzlZSTd2OFJUMzZmSDBDb05WckN1cDZ1SUU1?= =?utf-8?B?cm1CQ2xUeGR2SWorNitlUkZQMTZCS3hyVzZmbC9mTkVTcjVtOWZsNm55WWpi?= =?utf-8?B?ald2YVJKVU1MN3dTWXpqU3ZkRmkrc25TMXVXZjgwbjEvYXZ2MWU4SEtGQWU5?= =?utf-8?B?L0o1M2UrbVJjZW1FKzVRanpLTncxeE5GWTkzaGJPeEYzdUJId0l3NUVHSC8v?= =?utf-8?B?YlY0a01vRWVkSjJsYmN4VVl1NUtYVUxZS3BYanpzUWs3SGZhUDYwV3BJZ2FZ?= =?utf-8?B?T050VVlJUndlaFFUdE1BS2NtVEJHa0dKSEF0L2VhdGpoTWNpNTVEVVh2bnQ4?= =?utf-8?B?c2Jzc0lCeXZVelNXbjM2S3RadmF1Tk5ETXd4NDV4VGRFa1o1UTVhM2Z2QzdJ?= =?utf-8?B?cWZ0cGhJZVIyV0lObWVUbTdqcWw4UWpxZzZMbHhMbGREbHFkdXQvcEFYdEZv?= =?utf-8?B?bTQ2MDY2MzdpaFdWNUFyeE9NUGxITkVlTDV1NVZYQmdNVU5nYWtpZXA4UWRv?= =?utf-8?B?MDhPaC9ud2hQdm93V2NlRnVUZmx0MEIzYVRHMjZyNWcxTUNaSHJ2Y0kvb1Zv?= =?utf-8?B?bXl4QWdmY3NCY3FEamxPb1BzYmUwdlRTMEVqakMzaEJZQTlrR2FucDV2a1Y4?= =?utf-8?B?NmtKNjhZYzR0bi9NUmYwcTR0em1EQ0ZhSHhrMDVwR1A2dk9ETXdZZTRPaldY?= =?utf-8?B?SEpsc1RhR3pUai9ocjhWLytuYVJ3SEFiVnVaeFVSKzFkZWU1NlZReEEva1d5?= =?utf-8?B?RFdDNFJ3czJkRHorKzBzeDBUSnJjeDQwbGVUQUsybmxvQ2NDVWF5eTA3WGJ3?= =?utf-8?B?aWMra1M2cElRSjFVZmFITHVXWGJBWndycmRFb0VleUdHazF0RHpPTDVkSlVp?= =?utf-8?B?alRKOVVFOTJJUjM5U29YS0ZJNzBNN1dCYk5sVEp0KzFQVkVWZjVnK3JBaCsv?= =?utf-8?B?SWdxZ0tvUDM5QllaejVuSmZnTmJiaHU2cG1pVVlEblJuQU9iT1RscDI3Mkl4?= =?utf-8?B?cmU5aS80aDY5alFNV1RWUlBHRUZEVUlqVnpIVzZ1TDl0SUVnN3FqcDBWQVpn?= =?utf-8?B?dk92Qkg5TXhTS0wyZnJuVFRYeE40cExTcmJLUkNYeVc3dEd1SnNOUUNBbjEv?= =?utf-8?Q?LTJQ=3D?= Content-Type: multipart/alternative; boundary="_000_SA1PR15MB43704CB9F682B9F152EA958EB3AD2SA1PR15MB4370namp_" MIME-Version: 1.0 X-OriginatorOrg: meta.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA1PR15MB4370.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 40e97fda-e640-4f15-c4a0-08dca8230e66 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2024 18:46:09.8600 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rVioh3m5yrj5IF1X1ZNSVSNOzUkSvVmvbfHCzXj4u938KHvaYWQ9/4f76tA5wiyg X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR15MB6476 X-Proofpoint-ORIG-GUID: BcsNMo0kGmkmnatrzzDYKo7uJNgg6JoO X-Proofpoint-GUID: BcsNMo0kGmkmnatrzzDYKo7uJNgg6JoO X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16 definitions=2024-07-19_06,2024-07-18_01,2024-05-17_01 X-W3C-Hub-DKIM-Status: validation passed: (address=prvs=29302ad992=bemasc@meta.com domain=meta.com), signature is good X-W3C-Hub-Spam-Status: No, score=-3.5 X-W3C-Hub-Spam-Report: ARC_SIGNED=0.001, ARC_VALID=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, DMARC_PASS=-0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URI_NOVOWEL=0.5, W3C_AA=-1, W3C_WL=-1 X-W3C-Scan-Sig: pan.w3.org 1sUsch-00AZiC-2j 0b598f549b53f8e9f9ae39ff19f1434e X-Original-To: ietf-http-wg@w3.org Subject: Re: [Int-area] New version of WPADNG Archived-At: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/52087 X-Loop: ietf-http-wg@w3.org Resent-Sender: ietf-http-wg-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: --_000_SA1PR15MB43704CB9F682B9F152EA958EB3AD2SA1PR15MB4370namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I think the root of confusion here is that bootstrapping mechanisms like DH= CP, and perhaps PvD, are sometimes being used among mutually-trusting parti= es, sometimes among mutually-distrusting parties, and often somewhere in-be= tween. Configuration elements that make sense in one of these contexts are= often unusable in the other. I think the best solution is usually to move the configuration element out = of these multi-use protocols, to a single-purpose system where this kind of= conflict doesn't arise. In this case, that might mean a BCP that says "tr= ansmit your PAC file URL through your device provisioning channel". If the information must be conveyed in a "dual use" channel like PvD, it ma= y help to emphasize that the information is only to be used for networks th= at the client regards as sufficiently "trusted". --Ben Schwartz ________________________________ From: Josh Cohen Sent: Thursday, July 18, 2024 12:37 PM To: Watson Ladd Cc: David Schinazi ; int-area@ietf.org ; ietf-http-wg@w3.org Subject: Re: [Int-area] New version of WPADNG Lots of good info here. Bernard said: In RFC 5505, the IAB took on this que= stion, separating basic IP configuration (which has in practice proved diff= icult to secure) from application-layer configuration (which can be postpon= ed until later Lots of good info here. Bernard said: * In RFC 5505, the IAB took on this question, separating basic IP confi= guration (which has in practice proved difficult to secure) from applicatio= n-layer configuration (which can be postponed until later in the boot proce= ss when security facilities are available to secure it). Through the lens of RFC5505, that leads towards DNSSD. Is DNSSD considered= safer than DHCP? Paul said: * It's necessary for edge devices to securely learn the security polici= es of a network, for example a proxy if any and the cert or will offer if s= o. We're working around DoH policy signaling using the DNS server itself bu= t it's slow going. I read the Mozilla support pages for DNS over HTTPS (DoH): Are you involved with this Mozilla work? https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-= https https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet The solution to detect when not to use DoH is a canary domain: use-applicat= ion-dns.net. Can you shed light on this choice vs DHCP or DNSSD? Paul said: * I'd like to be able to verifiably inform each connecting device about= the network owner's policy demands so that the device can decide whether t= o accept those terms or remain offline. Tommy Pauly said: * I do think there is room for network-discovered proxies, and I=E2=80= =99d like to continue to explore how to do that safely in the realm of the = PvD-based discovery. I think the cases are going to be more limited there = =E2=80=94 cases of the network saying =E2=80=9CI have this proxy I suggest = using because it is well-optimized for my network, if it=E2=80=99s on your = trusted list of proxies, then please use it"=E2=80=A6 From what I've read of PVD a network's preference for DoH could be expresse= d in a PVD. A network's PVD could be discovered by either DHCP or DNSSD On Thu, Jul 18, 2024 at 9:29=E2=80=AFAM Josh Cohen > wrote: On Wed, Jul 17, 2024 at 11:00=E2=80=AFPM Watson Ladd > wrote: On Wed, Jul 17, 2024, 7:36=E2=80=AFPM Josh Cohen > wrote: > > You lost me with the nuclear submarine reference. I'm guessing instead o= f a terminal room, the IETF now has a navy? https://en.m.wikipedia.org/wiki/USS_Jimmy_Carter She was= n't made for sitting around. > > The coffee shop gives you your IP address, default route to the Internet,= DNS servers and other DHCP options. It often has a captive portal, which m= ay also have a transparent proxy that filters, can eavesdrop or otherwise a= buse you. It is *their* network after all, you are just a guest. That's as= ide from chai latte sipping wifi snoopers and the general jungle of public = wifi. So what's WPAD doing here? It's just another way to get that traffic to the wrong place. Again, the Internet threat model has the network be untrusted. That might be bad news for the vendors of devices that don't work that way, but that's what the RFC and design says. And indeed the coffee shop router shouldn't be trusted. I am having dejavu. We had a similar debate 25 years ago. Proxy servers i= n general weren't exactly popular because they violate the end-to-end ethos= . With respect to the network being untrusted, enterprises will push back = on that. They will do things that seem draconian. > > > I'm definitely getting the "WPAD suxorz" vibe, but what's missing are ans= wers to how scenarios WPAD currently addresses will be addressed without it. > > At work, your computer uses your enterprise's proxy. When you arrive at = the coffeeshop, will you go into your computer's settings and turn off the = proxy? When you go back to work the next day, will you go back into your s= ettings and turn it on again? I think this scenario is due to some fundamental confusion. What is the enterprise proxy doing? Why is it safe to turn off that function at the coffeeshop or entrust it to some random person given the computer will be back on the network the next day? And if the enterprise network needs to administer hosts, it can do that through much better ways. I was assuming a situation where the enterprise proxy is not accessible fro= m outside of the enterprise network. > > > > On Wed, Jul 17, 2024 at 7:50=E2=80=AFPM Watson Ladd > wrote: >> >> One adversary is willing to devote an entire nuclear submarine to the >> task. They are more than willing to use existing vulnerabilities in >> ways that you never hear about because they are good at their jobs. >> >> If you use network links to configure your device, and the device goes >> to the coffeeshop, that coffeeshop gets to configure the device. >> That's just inherently a bad idea, and always has been. >> >> Sincerely, >> Watson Ladd >> >> -- >> Astra mortemque praestare gradatim > > > > -- > > --- > Josh Cohen -- --- Josh Cohen -- --- Josh Cohen --_000_SA1PR15MB43704CB9F682B9F152EA958EB3AD2SA1PR15MB4370namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
I think the root of confusion here is that bootstrapping mechanisms like DH= CP, and perhaps PvD, are sometimes being used among mutually-trusting parti= es, sometimes among mutually-distrusting parties, and often somewhere in-be= tween.  Configuration elements that make sense in one of these contexts are often unusable in the other.

I think the best solution is usually to move the configuration element out = of these multi-use protocols, to a single-purpose system where this kind of= conflict doesn't arise.  In this case, that might mean a BCP that say= s "transmit your PAC file URL through your device provisioning channel".

If the information must be conveyed in a "dual use" channel like = PvD, it may help to emphasize that the information is only to be used for n= etworks that the client regards as sufficiently "trusted".

--Ben Schwartz
From: Josh Cohen <joshco= @gmail.com>
Sent: Thursday, July 18, 2024 12:37 PM
To: Watson Ladd <watsonbladd@gmail.com>
Cc: David Schinazi <dschinazi.ietf@gmail.com>; int-area@ietf.o= rg <int-area@ietf.org>; ietf-http-wg@w3.org <ietf-http-wg@w3.org&g= t;
Subject: Re: [Int-area] New version of WPADNG
 
Lots of good info here. Bernard said: In RFC 5505, the IAB took on this que= stion, separating basic IP configuration (which has in practice proved diff= icult to secure) from application-layer configuration (which can be postpon= ed until later

Lots of good i= nfo here. 

 

Bernard said:<= /p>

  • In RFC 5505, the IAB took o= n this question, separating basic IP configuration (which has in practice p= roved difficult to secure) from application-layer configuration (which can be postponed until later in the boot process when= security facilities are available to secure it).

 

Through the le= ns of RFC5505, that leads towards DNSSD.  Is DNSSD considered safer th= an DHCP?

 

Paul said:

  • It's necessary for edge dev= ices to securely learn the security policies of a network, for example a pr= oxy if any and the cert or will offer if so. We're working around DoH policy signaling using the DNS server itse= lf but it's slow going.

 

I read the Moz= illa support pages for DNS over HTTPS (DoH):

Are you involv= ed with this Mozilla work?

 

https://support.mozilla.org= /en-US/kb/configuring-networks-disable-dns-over-https

https://support.mozilla.org/en-US/= kb/canary-domain-use-application-dnsnet

 

The solution t= o detect when not to use DoH is a canary domain: use-application-dns.net.  Can you shed light on this choice vs DHC= P or DNSSD?

 

Paul said:

  • I'd like to be able to veri= fiably inform each connecting device about the network owner's policy deman= ds so that the device can decide whether to accept those terms or remain offline.

 

Tommy Pauly sa= id:

  • I do think there is room fo= r network-discovered proxies, and I=E2=80=99d like to continue to explore h= ow to do that safely in the realm of the PvD-based discovery.  I think the cases are going to be more limited there =E2= =80=94 cases of the network saying =E2=80=9CI have this proxy I suggest usi= ng because it is well-optimized for my network, if it=E2=80=99s on your tru= sted list of proxies, then please use it"=E2=80=A6


From what I've read of PVD a network's preference for DoH could be expresse= d in a PVD.

 

A network's PV= D could be discovered by either DHCP or DNSSD


On Thu, Jul 18, 2024 at 9:29=E2=80= =AFAM Josh Cohen <joshco@gmail.com> wrote:


On Wed, Jul 17, 2024 at 11:00=E2=80= =AFPM Watson Ladd <watsonbladd@gmail.com> wrote:
On Wed, Jul 17, 2024, 7:36=E2=80=AFPM Josh Cohen <joshco@gmail.com> wrote:
>
> You lost me with the nuclear submarine reference.  I'm guessing i= nstead of a terminal room, the IETF now has a navy?

https://= en.m.wikipedia.org/wiki/USS_Jimmy_Carter She wasn't made for
sitting around.

>
> The coffee shop gives you your IP address, default route to the Intern= et, DNS servers and other DHCP options. It often has a captive portal, whic= h may also have a transparent proxy that filters, can eavesdrop or otherwis= e abuse you. It is *their* network after all, you are just a guest.  That's aside from chai latte sippin= g wifi snoopers and the general jungle of public wifi.

So what's WPAD doing here? It's just another way to get that traffic
to the wrong place. Again, the Internet threat model has the network
be untrusted. That might be bad news for the vendors of devices that
don't work that way, but that's what the RFC and design says. And
indeed the coffee shop router shouldn't be trusted.

I am having dejavu.  We had a similar debate 25 years ago.  = Proxy servers in general weren't exactly popular because they violate the e= nd-to-end ethos.  With respect to the network being untrusted, enterpr= ises will push back on that.  They will do things that seem draconian.
>
>
> I'm definitely getting the "WPAD suxorz" vibe, but what's mi= ssing are answers to how scenarios WPAD currently addresses will be address= ed without it.
>
> At work, your computer uses your enterprise's proxy.  When you ar= rive at the coffeeshop, will you go into your computer's settings and turn = off the proxy?  When you go back to work the next day, will you go bac= k into your settings and turn it on again?


I think this scenario is due to some fundamental confusion. What is
the enterprise proxy doing? Why is it safe to turn off that function
at the coffeeshop or entrust it to some random person given the
computer will be back on the network the next day? And if the
enterprise network needs to administer hosts, it can do that through
much better ways.

I was assuming a situation where the enterprise proxy is not accessibl= e from outside of the enterprise network.  
 
>
>
>
> On Wed, Jul 17, 2024 at 7:50=E2=80=AFPM Watson Ladd <watsonbladd@gmail.com> = wrote:
>>
>> One adversary is willing to devote an entire nuclear submarine to = the
>> task. They are more than willing to use existing vulnerabilities i= n
>> ways that you never hear about because they are good at their jobs= .
>>
>> If you use network links to configure your device, and the device = goes
>> to the coffeeshop, that coffeeshop gets to configure the device. >> That's just inherently a bad idea, and always has been.
>>
>> Sincerely,
>> Watson Ladd
>>
>> --
>> Astra mortemque praestare gradatim
>
>
>
> --
>
> ---
> Josh Cohen


--

---
Josh Co= hen 



--

---
Josh Co= hen 

--_000_SA1PR15MB43704CB9F682B9F152EA958EB3AD2SA1PR15MB4370namp_--