Re: [dns-privacy] Operating System API support for DNS security policy

Tommy Jensen <Jensen.Thomas@microsoft.com> Mon, 19 August 2019 17:29 UTC

Return-Path: <Jensen.Thomas@microsoft.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 2A1A7120096 for <dns-privacy@ietfa.amsl.com>; Mon, 19 Aug 2019 10:29:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ro-ceszqNJxs for <dns-privacy@ietfa.amsl.com>; Mon, 19 Aug 2019 10:29:09 -0700 (PDT)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640126.outbound.protection.outlook.com [40.107.64.126]) (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 E5DED120089 for <dns-privacy@ietf.org>; Mon, 19 Aug 2019 10:29:08 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MqOgFicdkpCLOtILy6P7iv8VVgC44mzMmbbr2rO6bjJ7a7r+K9LwheZMLBmxxI/7Wb+3npfZpHKFu9mW1ji7QJLaSPuS+vQ+KfulhijhNdGzgZ6BHJqHCnCl8/KTUI8cVyXz+hCc6sH2nRX043n5CVTzDynIq4XI/JKKoIlbYmtlAvgiv6R6urecO1NMuPYMR/xPjoaxWrBam5S8KF4H8FUMG3ogaRQQjV1JJm+t9E27ncm4lsgqeGZdNOPpjcvLmfIGMqsE596ez7+UO+qf5FFQWpOEWfLvCGoKjKMouaiedeHU7gB+WErb4fiiaNsSu6nryymtoJmsCKN9RPXcYg==
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=PuFuz+8WMSQegql85OWzhSnZ5025RLfAsOU7t7Pr668=; b=Iy72OAdMH0Tr7XXfiTymCEvxcNiNF+MPFUkDwZB05N1dP0KgGpXFgxFnLALuKSuy+xOaASMtQP5kLddqy9Z07FlAzoi4dVhj3LRd/LBikEXlMMkTVfpvsokZeQmqv9FxbVzBllg1SYr25YRUXJ5ATYxQqBsWVDqB+01HZcNxKc14g7zamLQdWyrX8vlSJJXIEFcTSAr9FqrFbF6Psia8lH2d8Vs01k02vvqU/S7m7xQobzk9VoWfiNmqGy3xOYPcyeQdcqdcKjxk7MbYmJxzczspUkWk/Pb3AsYF/9Sy7yVSEJ7giU0ifI2JPbuPeh03avTkSMirELOxonHTB7hjyw==
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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PuFuz+8WMSQegql85OWzhSnZ5025RLfAsOU7t7Pr668=; b=DWXg/OTiGNOYKgU7ulB1h0Wv9PBGPdxgSSZsA3Qi9hHVExmnzVks7j9K5V4KnxOZ5zjbGawq2a8GXcxmC0LZ3BHonovOrOZcyh0OIHbU8ICOv8s5g6qEyCZwAR2UXdAzec2O8VTAnPb4W2owZIcqxfKmACoCOodGB0pLsNzp/yY=
Received: from CO2PR00MB0072.namprd00.prod.outlook.com (10.166.215.138) by CO2PR00MB0134.namprd00.prod.outlook.com (10.166.215.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2227.0; Mon, 19 Aug 2019 17:29:06 +0000
Received: from CO2PR00MB0072.namprd00.prod.outlook.com ([fe80::9901:ff7d:846:97a8]) by CO2PR00MB0072.namprd00.prod.outlook.com ([fe80::9901:ff7d:846:97a8%13]) with mapi id 15.20.2233.000; Mon, 19 Aug 2019 17:29:06 +0000
From: Tommy Jensen <Jensen.Thomas@microsoft.com>
To: Iain Sharp <isharp@atis.org>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Thread-Topic: Operating System API support for DNS security policy
Thread-Index: AdVWc+IFAQCIla+6Tnq+4hdu11XGygAN2GoD
Date: Mon, 19 Aug 2019 17:29:06 +0000
Message-ID: <CY1PR00MB0074C6229B0418BDC1AEC45DFAA80@CY1PR00MB0074.namprd00.prod.outlook.com>
References: <MN2PR10MB4046A5FC33FDE3192C93AA95B0A80@MN2PR10MB4046.namprd10.prod.outlook.com>
In-Reply-To: <MN2PR10MB4046A5FC33FDE3192C93AA95B0A80@MN2PR10MB4046.namprd10.prod.outlook.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=2019-08-19T17:29:05.851Z; 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: spf=none (sender IP is ) smtp.mailfrom=Jensen.Thomas@microsoft.com;
x-originating-ip: [131.107.147.40]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a6573379-c699-46d0-8b0f-08d724cabcf3
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600158)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:CO2PR00MB0134;
x-ms-traffictypediagnostic: CO2PR00MB0134:
x-microsoft-antispam-prvs: <CO2PR00MB01348AA372D2DE41FB860270FAA80@CO2PR00MB0134.namprd00.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 0134AD334F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(136003)(39860400002)(396003)(346002)(366004)(15404003)(189003)(199004)(486006)(19627405001)(316002)(2501003)(22452003)(476003)(53546011)(6506007)(26005)(102836004)(105004)(3846002)(186003)(11346002)(6116002)(10090500001)(110136005)(446003)(74316002)(10290500003)(25786009)(478600001)(2906002)(8990500004)(14454004)(7736002)(76176011)(86362001)(71190400001)(53936002)(33656002)(81166006)(81156014)(8676002)(91956017)(76116006)(5660300002)(66946007)(66446008)(66556008)(6436002)(52536014)(9686003)(54896002)(6512007)(6486002)(256004)(66066001)(8936002)(6246003)(99286004)(14444005)(15650500001)(19627235002)(64756008)(66476007)(71200400001)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR00MB0134; H:CO2PR00MB0072.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: rPsdvaB65zlPXbmc/iIZ76eDTY4T1zL1TBONW78J9uVK1mlvfgLIlT0GHRlAqJi21iJIkvAW5HTWcRq5SXP4sz/a7HpXupBtqj4X6I4Rq7+oDoZMdapPhzig4Nvh8VOSDlqT47toyCXM7k3xZMZuKZVygsFNHyvpF53PfS7MVXbMBkvUvLx1OeQelswZxqeWREg38xm5MvYGyDdUQqr+nDUJ+fIOTp0t1niOJuciCbgXVKhzSg5/bN2/P2apXA9uUCK0HTR2WbQQlFdwkqJ3/YBl1pFHQPHTKKR0yfs2UOeu3D4MCZLXhDNJE6A62YtCzgFYwumKFQbXdW4PynNCB+TsPeETxAWTKsXIlsnYfwkuQFDH71QP4CnPodfjS+8vhWf/zRmFZmfvsOhxg/hdi6K4LMqWpwByhDXkJGzE/3g=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CY1PR00MB0074C6229B0418BDC1AEC45DFAA80CY1PR00MB0074namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a6573379-c699-46d0-8b0f-08d724cabcf3
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2019 17:29:06.5886 (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: zM66ydP94MXG09dzOIHPFw1jf0FZt8EZUlb2eux1CvjIY/kYDUkOG8u/gIr34i283xs1hggLkEHuiAQEom739Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR00MB0134
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/h1gM3ixRDbFBzT4TRCb3Zg3cNgg>
Subject: Re: [dns-privacy] Operating System API support for DNS security policy
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: Mon, 19 Aug 2019 17:29:12 -0000

Hey Iain,

Iain> Many applications rely on operating system APIs to access DNS services. As native support of DNS over TLS rolls out in to operating systems it seems likely that some applications will wish to control the security policy that the operating system applies when it performs DNS resolution. For example, the application may wish to require that the operating system uses an encrypted DNS protocol.

I actually don't see this being necessary. Walking through the possibilities:

  *   If the OS supports DoT and the configured servers support it:
     *   OS should be using DoT whether the app requests it or not
  *   If the OS supports DoT but the servers don't:
     *   App intent isn't helpful (to the same server)
  *   If the OS doesn't support it:
     *   App intent isn't helpful

My view is that the OS should be taking the most secure DNS route it has available regardless of app request (after all, think of all the apps which won't request DoT but should). In the case where the OS supports DoT but isn't using it, that decision is being made in the context of other information, such as enterprise configuration, that the app may not have.

Iain> Unless operating systems support secure DNS standards and expose APIs to allow applications to use them effectively then applications that require secure DNS have little choice other than to roll their own implementations.

I totally agree. Platforms should be providing the network tools apps need so all apps can benefit similarly, rather than leaving apps to figure out networking nuance on their own. I just think in this case that there should never have to be a situation where an app needs to request DNS encryption (because either it's already happening or it can't happen for some reason unknown to the app).

Summary: I think such an API should be unnecessary on well-behaved platforms.

Thanks,
Tommy
________________________________
From: dns-privacy <dns-privacy-bounces@ietf.org>; on behalf of Iain Sharp <isharp@atis.org>;
Sent: Monday, August 19, 2019 2:56 AM
To: dns-privacy@ietf.org <dns-privacy@ietf.org>;
Subject: [dns-privacy] Operating System API support for DNS security policy


All,



DNS over TLS offers the ability to perform DNS queries over a TLS secured channel. In my understanding, DNS over TLS is not yet available in all operating systems, but operating system support could become common in future.



Many applications rely on operating system APIs to access DNS services. As native support of DNS over TLS rolls out in to operating systems it seems likely that some applications will wish to control the security policy that the operating system applies when it performs DNS resolution. For example, the application may wish to require that the operating system uses an encrypted DNS protocol.



Today, most operating systems use the getaddrinfo() function described in RFC3493 as the basis of their API for translating DNS names to IP addresses, but this does not have security policy attributes. Is anyone aware of any activity to enhance the RFC3493 work to add application control of security policy to the getaddrinfo()  capabilities?



Unless operating systems support secure DNS standards and expose APIs to allow applications to use them effectively then applications that require secure DNS have little choice other than to roll their own implementations.





Thanks



Iain