Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...

"Vinny Parla (vparla)" <vparla@cisco.com> Sun, 11 October 2020 23:34 UTC

Return-Path: <vparla@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 A63B33A09C3 for <dns-privacy@ietfa.amsl.com>; Sun, 11 Oct 2020 16:34:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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=Cv9AxMpm; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=rOqaOPf5
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 JZ5Kd7HeZWVw for <dns-privacy@ietfa.amsl.com>; Sun, 11 Oct 2020 16:34:20 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C7A83A09C1 for <dns-privacy@ietf.org>; Sun, 11 Oct 2020 16:34:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16892; q=dns/txt; s=iport; t=1602459260; x=1603668860; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=N/eQmxFiEl0Nv6Chs36a0RClHtiQ9gngW9FXCpXrmOY=; b=Cv9AxMpmrbBFdyTAohw6fM65YWY3bsvlzQ7shvzjnpzwFHacUpcWh01t C5GPTNLJ14GIukKSsuwsovTEfRxbHJvfn5KjehyruBqMaI0Fi7fspXtIk LlQKrQGNAxEhFWId0xhHAS/J8WM7+LZ3AxvvOeUF2+9+Wg0Gn4C0FI/UA I=;
X-Files: smime.p7s : 3980
IronPort-PHdr: =?us-ascii?q?9a23=3AYe1X7hR0b1jRKufXc4TTPdjrLtpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQB9mJt6sVzeHRtbv9XXAB55nS+HwBcZkZUR?= =?us-ascii?q?gDhI1WmgE7G8eKBAX9K+KidC01GslOFToHt3G2OERYAoDyMlvVpHDhsWdDXB?= =?us-ascii?q?74MxFoIvj0HIGBx8iy3vq5rpvUZQgAjTGhYLR0eROxqwiZtsQfjYZ4bKgrzR?= =?us-ascii?q?6cqXpTcOMQzmRtdl8=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlCAAFlYNf/4cNJK1gHQEBAQEJARI?= =?us-ascii?q?BBQUBgg+BIy9RB3AsLS8shD2DRgONUIECiQ+Je4RvglMDVQQHAQEBCgMBAR8?= =?us-ascii?q?OAgQBAYRKAoITAiU4EwIDAQELAQEFAQEBAgEGBG2FXAyFcgEBAQEDEhEKEwE?= =?us-ascii?q?BNwEPAgEIEAEEAQErAgICHxEdCAIEAQ0FCAYNB4MFgX5NAx8PAQ6cZQKBOYh?= =?us-ascii?q?hdoEygwEBAQWFAg0LggkHAwaBOIFTgR+DboZWG4FBP4ERQ4FPSTU+ghpCAQE?= =?us-ascii?q?DgV4VFQGCajOCLZMNPZMGkAo4UgqCaIRMgl+BVoxdhS2hOpMiinGCbJJIAgQ?= =?us-ascii?q?CBAUCDgEBBYFrIyoNgSBwFYMkUBcCDY4fg3GFFIVCdDcCBgEJAQEDCXyNTAE?= =?us-ascii?q?B?=
X-IronPort-AV: E=Sophos;i="5.77,364,1596499200"; d="p7s'?scan'208,217";a="837772821"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Oct 2020 23:34:12 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 09BNYC8f030819 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 11 Oct 2020 23:34:12 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 11 Oct 2020 18:34:11 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 11 Oct 2020 19:34:10 -0400
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sun, 11 Oct 2020 18:34:10 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ML6u1eKj75PdixDNHZY6C9yp0dzHxVl0gQ0fO3chpk/P1uLjR3V9DG9rggy2cZ8GRtTypvc87sJJ5bnpgdQWE2n9lzqLh347ObwZbIZb+OPFuJ9+i8BayaTOJp8YlCRAfPcQ/A60A4upR1RpJbEGhj6xOz+01PC5wjHpV4AB506+jCAJPnV4SIXeoLoNXW1IJiiQJEtOnnyn9KZKxDFAR7VJc1auCwuOnhZrobZKM658ljr83RVZTmJhrl9TYfyYly9K3w8moc0jWR4mMmvsgPc3u8EFeVnKRexK8mBSKeRGquD1D7/k6hhzV5xrWz20Yt0gEK+iO69lVpg//e89rA==
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=oCGa8+ZI79elEFmJoMvK+F7AtVlrq3t+lz65SvxgsVs=; b=h2hP69C9crivzoajiDeoVFXb55FmiOWejnGTKrgfSdardDHnYVzmzDSVzqiy+xGgNoIPhG/Cl826gRo1oSOcFKSx2n7twsQNq0P8smiTiYZLiF8Yu7Pt0ePGMPOjiDx4+XbJRnjGIlkQrbcmN+C1fryyK3svbHTB1J8w+bOFXY3R60QiWHCVlUxr0nM/DJpVX+YOU4HawvgmFBySeR3/ZdDR35OmOxU8wJH0EdszI+nIQl+Bh3tU/9XMaeEs3A9mZHyORnVXtGZrSviprtTVAOb3xU7HKehg6ns/1EZ+4uOBXSfVqUk2BDHLlOCbwKWa/5qHRqBe/BRifIVSbeR6Eg==
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.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oCGa8+ZI79elEFmJoMvK+F7AtVlrq3t+lz65SvxgsVs=; b=rOqaOPf5XVpc2InhWou/pks4jOcYr9bCR12wtXoIzNhuyJFGg5koHKQNmBVm8F8zaIIbcm14V764pXH2hgNLblgoASD8UnOscP8y/ZyjnFBQNBxrz294tz/7RO4UoF5ZskpfYFiGlWMAU+YcFoIgSzjFRHkPBXc/UoLJ5t3DkpM=
Received: from MN2PR11MB4760.namprd11.prod.outlook.com (2603:10b6:208:266::22) by MN2PR11MB4318.namprd11.prod.outlook.com (2603:10b6:208:17a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.22; Sun, 11 Oct 2020 23:34:09 +0000
Received: from MN2PR11MB4760.namprd11.prod.outlook.com ([fe80::3d81:a330:3f9a:4f07]) by MN2PR11MB4760.namprd11.prod.outlook.com ([fe80::3d81:a330:3f9a:4f07%7]) with mapi id 15.20.3455.029; Sun, 11 Oct 2020 23:34:08 +0000
From: "Vinny Parla (vparla)" <vparla@cisco.com>
To: Andrew Campling <andrew.campling@419.consulting>, Christian Huitema <huitema@huitema.net>, Tommy Pauly <tpauly@apple.com>
CC: Eric Orth <ericorth@google.com>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>, James <james.ietf@gmail.com>
Thread-Topic: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...
Thread-Index: AdabLJ2GPjqR+/akTMiZMRHmFMQKNAA94NwAACIy4oAAApqMsAAlj7MAAAvi7OAAA7jTgAAhtWkAAB5P7gAABiGwAABZ6HyAAAZnV8A=
Date: Sun, 11 Oct 2020 23:34:08 +0000
Message-ID: <MN2PR11MB476046767EE2584816AEFBE9D8060@MN2PR11MB4760.namprd11.prod.outlook.com>
References: <MN2PR11MB47604813E0DC2DDA0E297A36D80C0@MN2PR11MB4760.namprd11.prod.outlook.com> <CAO+dDxn1J2bOz1b8iPKbUnYLTFhSLJRhx9Od5hAHpP3TSkp7yQ@mail.gmail.com> <C276A52C-DCBA-4920-95E1-FAF2D3881D0B@apple.com> <MN2PR11MB476044BA6BD5D47C8088D434D80A0@MN2PR11MB4760.namprd11.prod.outlook.com> <LO2P265MB0573F65FD0DC18B528FD3282C20B0@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <MN2PR11MB47604811528E52E2ED48E41AD80B0@MN2PR11MB4760.namprd11.prod.outlook.com> <CAMOjQcEnhjh_VzQeTFRk6mAF9c8P_i9NMO8S3oMZBv4f81RHew@mail.gmail.com> <CWXP265MB056674BB1E637A04AE2E8860C2080@CWXP265MB0566.GBRP265.PROD.OUTLOOK.COM> <4F75DF4C-63D7-4101-A5C5-4057B34EAB23@apple.com> <e920622d-3f22-3e36-d11c-32a122d15fb3@huitema.net> <LO2P265MB05735A3BC771C6E340E91F55C2060@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM>
In-Reply-To: <LO2P265MB05735A3BC771C6E340E91F55C2060@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: 419.consulting; dkim=none (message not signed) header.d=none;419.consulting; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2601:188:c400:bde0:2088:515f:de1d:a646]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: be71acc5-3ba6-464e-287d-08d86e3e26be
x-ms-traffictypediagnostic: MN2PR11MB4318:
x-microsoft-antispam-prvs: <MN2PR11MB43187A53A4755D8CAA733F0DD8060@MN2PR11MB4318.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: F5w6A5P51XbH47aQm52fB0qSkMVMZq+3RlO506sxuN1VHQRaIwuQsioeR+4lFQCs/Z2x+U5trx0Pkp88ZkQLcQC1REC9qdqx3SG1ZZuUuk4DC/KAEUDdme3gcCOyidH98PYrHvvuG8bt0tKmGBMN09kktsKJzATYK9w7Z8sT1U8eqgJHkHvCxyVBwUPCSXuh+Jjm/EFxGm9AiIXpcmjNlyCJIdYsf7gZMFGTIa9EhN9/hnI8PPwv9Cb6AN3RGsvu0q0hAKKzYXbTm1y0C60OFIziaaqqWl4aBvGJSLnX9+yavDbMgO6V8JbwOacqwriS2jxpukgCT2i1viAdm96HZS7/XcMhCu/zgRgEUbpgQVKaIDXSIgumOeuBhnGojW3sske0/hfqO0a6GC8Snl2hUw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4760.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(39860400002)(136003)(366004)(376002)(346002)(7696005)(9686003)(33656002)(4326008)(55016002)(478600001)(71200400001)(66446008)(52536014)(54906003)(110136005)(5660300002)(8936002)(9326002)(99936003)(76116006)(66616009)(86362001)(83080400001)(8676002)(186003)(66946007)(316002)(53546011)(2906002)(83380400001)(166002)(6506007)(64756008)(66556008)(66476007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: KhaU7kOJlMuVstZx2D6Ka6HTdFqDpX08KpcrwM/75t0/e34cxghZPG0DbxVIf1Pli/GkIXF0ZCnB5pr953BYYxP0DBKqSCH1FWuVTlokwPvmJzo4Q/Fkl8AZcYlni/PZrtzEzZnk3RCWVgx93WvN0+PTrzOXsOJjj/CUoZLY5bOEW7Ig1cIDhDlMeEIf69hG1ZFM1fIxix01GU3O61Pk5du+lerBv/67kkBofE4FgnxRwZjRyG7kf7nfArP0hxUNlVyb4hm9fqv9t8jq4QxSUnQI2LuU2WaHbp1WNrewCQy6SfpGFvobF8TD63SatWshTtPgtDdxIQLCVxF9xcUyv40FBizt3FHdrOyV68hr+aNDvFrG8M1W6aeUxKONRU0WpMMBSED6oPn6pLg8I6XIm2Tfa5fIVdJ7lZbYS5ITtWpod8na/h+tZriSGH+sLy16Ift7Bagb8GgYng022iYmwGbp+iR88Z4ktkGIzRJuiOj/DVPB96XcpGBxrzoOte64ItnCQQxHsp01doKlRF+xXzMS6tLu9aH0kGf9Rq1ZBzC2xWu6h5eiUk6EMusRa03Y2ucVcOIBvVNEogOk3Dshrt5CSMpAHqVU+f06+8PtjFMJ7ZRhwPveYkEbiHsISaRnqQgWuONLywTbgBUrzE8QkMOIE+0jG0UPepMptkas9905XLXWAUGBk0gHa78ELVdKdXRPQSASzsUFEyhYG5iG1A==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0020_01D6A005.7BC83F90"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4760.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: be71acc5-3ba6-464e-287d-08d86e3e26be
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2020 23:34:08.7968 (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: 1aKWqYErD8dUKnWKGx31oZTyA4sChx6nWOe+hrY+LVlsWOHJ5+84dUOKXEo1SAgasTaNKAx/mcgI8EfRahRWVA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4318
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/rPfid8hX2_arUFMGnB-LKs929m4>
Subject: Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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: Sun, 11 Oct 2020 23:34:23 -0000

Hi,

 

I think that aggregation with Content is generally undesirable in terms of DoH.

 

However there are use cases for authentication of a DoH channel for enterprise scenarios that we should not simply dismiss as a ‘user tracking’ mechanism.

 

For example if an enterprise wants to build a Zero Trust solution and protect their private domain names to only those users authorized to access them.

In such a case, the enterprise would want an authenticated DoH channel to do that.

 

That authentication could be via mTLS on the DoH tls channel, OAuth or even WebAuthN.  

The point being there is a valid use case for doing this in a client implementation.

 

-Vinny

 

From: Andrew Campling <andrew.campling@419.consulting> 
Sent: Sunday, October 11, 2020 4:23 PM
To: Christian Huitema <huitema@huitema.net>et>; Tommy Pauly <tpauly@apple.com>
Cc: Eric Orth <ericorth@google.com>om>; dns-privacy@ietf.org; James <james.ietf@gmail.com>om>; Vinny Parla (vparla) <vparla@cisco.com>
Subject: RE: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...

 

On 10/10/2020 2:28 AM, Christian Huitema wrote:

On 10/9/2020 3:32 PM, Tommy Pauly wrote:

Hi Andrew, 

 

At least the cookie aspect of this isn’t just a “best practice” of one implementer, but something indeed built into the protocol spec (https://tools.ietf.org/html/rfc8484):

 

   Determining whether or not a DoH implementation requires HTTP cookie
   [RFC6265 <https://tools.ietf.org/html/rfc6265> ] support is particularly important because HTTP cookies are
   the primary state tracking mechanism in HTTP.  HTTP cookies SHOULD
   NOT be accepted by DOH clients unless they are explicitly required by
   a use case.

 

I think it is incorrect to characterize that DoH has a flawed design by basing itself on a protocol that allows cookies, or allows multiplexing. These are certainly tools provided by HTTP, but it is up to use them or not as appropriate. “Bad” implementations can put information in just about any protocol that could be used for tracking users.

I am not sure about that. These days, if a protocol design allow it to be used for surveillance, you can be pretty sure that it will be.

That’s my concern too.  If the capability exists then it will be used, the opportunity for monetisation (and other negative outcomes) is too great.

Maybe DoH should add a requirement for servers to reject requests on multiplexed connections, or reject requests that come with cookies attached. That would provide a strong incentive for clients to do the right thing.

My European DNS Resolver Policy for resolver operators includes the following: “[operators of DNS resolver services] SHOULD NOT use or require HTTP cookies when communicating with DNS clients that use HTTP-based DNS transports for resolution”.  

 

Andrew