Re: [Doh] [EXTERNAL] Re: DoH

"Reed, Jon" <jreed@akamai.com> Mon, 01 April 2019 10:56 UTC

Return-Path: <jreed@akamai.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89491200F4 for <doh@ietfa.amsl.com>; Mon, 1 Apr 2019 03:56:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Level:
X-Spam-Status: No, score=-1.851 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, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, 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=akamai.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 YL1Wx7dYJltC for <doh@ietfa.amsl.com>; Mon, 1 Apr 2019 03:56:00 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 7AF8C12001A for <doh@ietf.org>; Mon, 1 Apr 2019 03:56:00 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x31Apawx002701; Mon, 1 Apr 2019 11:55:30 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=jtM47DpImWJY/vYXQIorpYhU1ukJ2ZwPekZiNk9biIw=; b=b126s+eeHc6zlziNbM4duI693JRISAWr8t43PKUZ9I1zorGmjanEhGJaYYIJqacF0rAl GvnixYGflSAxc89Q0/6iMA/z48jSbhadsKCyQ6Cv2uj9X5TpwP240AAvAwtNZxCyis1n njWj8etThxQO3gA7UevtWvBpajXYBo1QMW5u65N3SUl3yfO5iISLjmfS1Xx0zpvRsaWA PUlYhwJFSIcoo6Dn2sgrY137Hb4xbpjOzEW+LCsZi7z16rzUOlxUnafFl8NiUoKiShm0 Ussslox5oImOkTnEL8lmjKFNnEmER0cHHaDOizr8UJD0SBXy8/x7+DM6Z2RulixQgUix FQ==
Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2rj0kt7yy5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 01 Apr 2019 11:55:30 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x31AlELm006480; Mon, 1 Apr 2019 06:55:29 -0400
Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint3.akamai.com with ESMTP id 2rj3sx9un9-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 01 Apr 2019 06:55:28 -0400
Received: from USTX2EX-DAG3MB6.msg.corp.akamai.com (172.27.27.28) by USTX2EX-DAG3MB2.msg.corp.akamai.com (172.27.27.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 1 Apr 2019 03:55:15 -0700
Received: from USTX2EX-DAG3MB6.msg.corp.akamai.com ([172.27.27.28]) by USTX2EX-DAG3MB6.msg.corp.akamai.com ([172.27.27.28]) with mapi id 15.00.1473.003; Mon, 1 Apr 2019 05:55:15 -0500
From: "Reed, Jon" <jreed@akamai.com>
To: Adam Roach <adam@nostrum.com>, Paul Brears <pbrears@rm.com>, "andrew.campling@bt.com" <andrew.campling@bt.com>, "Alister.Winfield@sky.uk" <Alister.Winfield@sky.uk>, "john@johncarr.eu" <john@johncarr.eu>, "mcmanus@ducksong.com" <mcmanus@ducksong.com>
CC: "paul.hoffman@icann.org" <paul.hoffman@icann.org>, "doh@ietf.org" <doh@ietf.org>
Thread-Topic: [Doh] [EXTERNAL] Re: DoH
Thread-Index: AQHU5jBcBn/wQwg5BUOVVmuJRjhusKYnNycA
Date: Mon, 1 Apr 2019 10:55:15 +0000
Message-ID: <01528060-1D57-4480-93EB-3A5406EE2164@akamai.com>
References: <DB7PR03MB4698C510EC609C85725FC158C6590@DB7PR03MB4698.eurprd03.prod.outlook.com> <CAOdDvNpJqaemDTHcUtTQ7Xc1cq5OOFU91qq_h97j6Uv1RTHD7A@mail.gmail.com> <DB7PR03MB4698A645255E883C9CC07AC3C6590@DB7PR03MB4698.eurprd03.prod.outlook.com> <73a0935d-f80b-0e8d-eb89-cb35a473122c@nostrum.com> <826904ddc23941d5be4d8872c4f2737a@tpw09926dag11h.domain1.systemhost.net> <2af82a6d-6887-ae36-4527-47e476829345@nostrum.com> <9E29A232-BA75-478D-96BF-5D6164142BDD@sky.uk> <6bebaadff9b54dc1a906c237a756d476@tpw09926dag11h.domain1.systemhost.net> <AM6PR04MB4997FC8AA781788F17A861B6CF5A0@AM6PR04MB4997.eurprd04.prod.outlook.com> <62c8932a-34f6-e0be-99fe-0976a8b4d5f7@nostrum.com>
In-Reply-To: <62c8932a-34f6-e0be-99fe-0976a8b4d5f7@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.32.137]
Content-Type: text/plain; charset="utf-8"
Content-ID: <6D9F229BE9E13C4B942693B6F2325F65@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-01_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904010074
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-01_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904010075
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/pV1vNcrVqvBbV5k6Eytb4Z75xEQ>
Subject: Re: [Doh] [EXTERNAL] Re: DoH
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2019 10:56:02 -0000

On 3/29/19, 9:07 AM, "Adam Roach" <adam@nostrum.com> wrote:

    On 3/29/19 12:54, Paul Brears wrote:
    > I think the key difference is that on a normal Widows PC you’d need device admin credentials to change DNS provider.
    
    
    This again conflates product concerns with protocol ones. Applications 
    have always had the ability to incorporate their own resolver library 
    and configure it to use servers other than those provided by the 
    operating system (cf. c-ares, adns). The concern you describe is that 
    some popular applications may choose to do so.
    
I think at this point, it's difficult to separate the protocol from its use by applications _as it pertains to these sorts of discussions_.  As an engineer, I understand the difference and I think it's important to continue to convey it, but I think for many people, DoH may be forever conflated with the concept of a browser selecting a recursive for you.  I think it's fair to say that the existence of the DoH protocol itself makes it much much easier for applications to incorporate their own resolver library, since many environments provide an HTTPS client "for free".  (In my experience, when an application chooses to use ares or adns, it's because the app needs the async functionality, as opposed to simply selecting an alternate resolver library.  Certainly they're both much harder to integrate than simply issuing a GET request.)
 
To avoid re-hashing everything on yet another thread, and speaking for myself only, it sounds like the answer to John's question is: "Yes, there has been considerable discussion in various working groups about the impact of widespread deployment of applications that choose bypass the system resolver, and choose to do so over a protocol that is indistinguishable from regular HTTPS traffic.  There isn't a good answer yet.  Several people have authored drafts about the operational issues, and there was a side-meeting at IETF 104 about which working groups are suitable for raising these issues, but this is a concern shared by some network operators, security software vendors, and cloud providers."

-Jon


--
Jon Reed <jreed@akamai.com>
Senior Performance Engineer
Akamai Technologies
Nameservers Service Performance