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

Iain Sharp <isharp@atis.org> Tue, 20 August 2019 10:13 UTC

Return-Path: <isharp@atis.org>
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 9427C1200B2 for <dns-privacy@ietfa.amsl.com>; Tue, 20 Aug 2019 03:13:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.288
X-Spam-Level:
X-Spam-Status: No, score=-4.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=atis.org
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 1gJJXlaI1AEL for <dns-privacy@ietfa.amsl.com>; Tue, 20 Aug 2019 03:13:44 -0700 (PDT)
Received: from us-smtp-delivery-174.mimecast.com (us-smtp-delivery-174.mimecast.com [63.128.21.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25CE12003E for <dns-privacy@ietf.org>; Tue, 20 Aug 2019 03:13:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=atis.org; s=mimecast20190423; t=1566296022; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6iMlUbsjBewK/136ajrvb0Gp1aXBEJgkInSl4OssaUY=; b=cAG6N9Va/mwx9kTPG6V8V0s/YAIOUd2b4dsPEd9s0KrTP6IrorWQIEEu93oI5z3xXO0Dtz xpGj0FsBaQRVWUdrz0MXea7bpdp+ASEhhzlJXlzOudJdGlTsW33r2IOlwr1X7OE3FULL6B cF8ChgroJA483wSyt9G1Yz7WQGSLPos=
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03lp2050.outbound.protection.outlook.com [104.47.40.50]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-68-TtfGYnwBPWK8_3yqkJbxmQ-1; Tue, 20 Aug 2019 06:13:41 -0400
Received: from MN2PR10MB4046.namprd10.prod.outlook.com (52.132.175.31) by MN2PR10MB3984.namprd10.prod.outlook.com (52.132.174.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.16; Tue, 20 Aug 2019 10:13:37 +0000
Received: from MN2PR10MB4046.namprd10.prod.outlook.com ([fe80::59fd:33db:6bde:7a43]) by MN2PR10MB4046.namprd10.prod.outlook.com ([fe80::59fd:33db:6bde:7a43%3]) with mapi id 15.20.2178.018; Tue, 20 Aug 2019 10:13:37 +0000
From: Iain Sharp <isharp@atis.org>
To: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Thread-Topic: [dns-privacy] Operating System API support for DNS security policy
Thread-Index: AdVWc+IFAQCIla+6Tnq+4hdu11XGygAN2GoDAAJougAAAT2xAAAgnlIA
Date: Tue, 20 Aug 2019 10:13:37 +0000
Message-ID: <MN2PR10MB404640ABB9D1EFF1530880DEB0AB0@MN2PR10MB4046.namprd10.prod.outlook.com>
References: <MN2PR10MB4046A5FC33FDE3192C93AA95B0A80@MN2PR10MB4046.namprd10.prod.outlook.com> <CY1PR00MB0074C6229B0418BDC1AEC45DFAA80@CY1PR00MB0074.namprd00.prod.outlook.com> <CA+nkc8Bk_AdP4w9m1wo8L+u98=ip7jrw13U-QdkF_GMhfYXKAA@mail.gmail.com> <ijd4mi.pwhxb9.31eoyz-qmf@mercury.scss.tcd.ie>
In-Reply-To: <ijd4mi.pwhxb9.31eoyz-qmf@mercury.scss.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [87.114.65.49]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bbb8d8b1-29d2-4088-fb9a-08d725571145
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(7168020)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR10MB3984;
x-ms-traffictypediagnostic: MN2PR10MB3984:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <MN2PR10MB3984F809A7A306DC6B6EFBC4B0AB0@MN2PR10MB3984.namprd10.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 013568035E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400004)(346002)(136003)(366004)(376002)(396003)(51914003)(13464003)(15404003)(189003)(199004)(55236004)(3846002)(14454004)(81166006)(81156014)(2906002)(8676002)(6436002)(229853002)(2351001)(52536014)(7696005)(7736002)(966005)(33656002)(508600001)(99286004)(6916009)(76176011)(74316002)(5660300002)(15650500001)(305945005)(53936002)(6116002)(8936002)(14444005)(256004)(71200400001)(6506007)(71190400001)(2501003)(53546011)(86362001)(6246003)(186003)(25786009)(26005)(102836004)(9686003)(76116006)(316002)(66066001)(11346002)(55016002)(486006)(6306002)(446003)(5640700003)(66446008)(64756008)(66556008)(66476007)(66946007)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR10MB3984; H:MN2PR10MB4046.namprd10.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: DE4bjtNwckJBzcio9hKyL7misX5s4K3IpS4BYiHG1FzYQRzBHa07B4av5xo0RlYwjOO5/OsqiX5td75ylKx8kZKQyHnlK9tZd67ZImfwXuu/lqy6/bea9q1U5SO+NdlLnWXOtqJBRwnQJjJxhSpPvyXV+qkxZtB65I5/hkGlz27lTfva0Fw0zAwsRxJVhakIt1G9Vnu/RByQ8DzY8Lo0TN/fIIeRs94v4xIm57PtPfFkdBFK9/4OfABxrtLRXBp9gM3lAIBJND/TvEtiLin//hDm90G2K5dAGDuE3+t9W8I53ZY3HlX9Ygi/OPZwf7b9rbgs2Hx4zY18OjjhyQsrZkITLuwk8lmLJ96UgvFwawL2sp94N21tpq2bc7QwvdFPTdYXJC9P9XD0ngrABenOEdO0xgzZYXeB1QZm19uRw4w=
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: atis.org
X-MS-Exchange-CrossTenant-Network-Message-Id: bbb8d8b1-29d2-4088-fb9a-08d725571145
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2019 10:13:37.7166 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 1c6cdebf-458e-4ef3-8f8e-96f15ccaa2b3
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: bdfbGLLB5jo51h2BN6QoyP8oI6jH8IcYpcxVTI6YsmtLDJskkqbJuhQqkn5Vql/+
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR10MB3984
X-MC-Unique: TtfGYnwBPWK8_3yqkJbxmQ-1
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/eSOMOU7kMhJxPpw-UQjxsJRM26w>
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: Tue, 20 Aug 2019 10:13:47 -0000

Thanks for the informative replies.

The use cases I was thinking of are similar to those outlined by Bob and Stephen. Hypothetically, there might also be scenarios where the application wishes the DNS to be done without security (e.g. for debugging) though I don't know in practice how important these are.

The getdns API is quite similar to what I had in mind. In getdns you can specify the transports you want from UDP, TCP and TLS. Possibly other levers may be needed for things like ESNI.

Would the following be a fair summary of the discussion?
1) There is some support for the idea it would be useful for APIs to allow an application to at least know, and perhaps influence, what DNS security features will be used if it makes a DNS request via the operating system.
2) The getaddrinfo() API in RFC3493 doesn't provide this capability.
3) As far as we are aware there is no work in IETF currently on how to express security policy in DNS APIs, but the getdns API seems to have similar goals to point 1.


Regards

Iain



-----Original Message-----
From: dns-privacy <dns-privacy-bounces@ietf.org>; On Behalf Of stephen.farrell@cs.tcd.ie
Sent: 19 August 2019 19:14
To: rharolde@umich.edu
Cc: Iain Sharp <isharp@atis.org>;; dns-privacy@ietf.org; Jensen.Thomas=40microsoft.com@dmarc.ietf.org
Subject: Re: [dns-privacy] Operating System API support for DNS security policy



On Monday, 19 August 2019, Bob Harold wrote:
> On Mon, Aug 19, 2019 at 1:29 PM Tommy Jensen <Jensen.Thomas= 
> 40microsoft.com@dmarc.ietf.org>; wrote:
> 
> > 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
> >
> > I read this differently - the api needs to tell the app whether the 
> > OS
> does encrypted DNS:
> 
>    - OS supports DoT and can connect to a DoT resolver
>       - App uses OS for DNS
>    - OS does not support DoT
>       - App connects to a DoT server itself, bypassing the OS  (even though
>       I dislike this, unless the user has agreed)
>    - OS supports DoT but cannot reach a DoT server
>       - various choices, we don't need to discuss this now.
>

+1, there's also the case of TLS ESNI where the application wants to only do the lookup if DNS privacy will be used. Different applications may choose different  fallbacks if DNS privacy is  not available from the OS.

Cheers,
S.

 
> --
> Bob Harold
> 
> 
> >
> >
> > 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 
> > Iain> 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
> >
>
_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy