Re: [dns-privacy] Trying to understand DNS resolver 'discovery'

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Wed, 27 November 2019 15:25 UTC

Return-Path: <tirumaleswarreddy_konda@mcafee.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 A78661209AF for <dns-privacy@ietfa.amsl.com>; Wed, 27 Nov 2019 07:25:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 xwYG0Yq_nvDv for <dns-privacy@ietfa.amsl.com>; Wed, 27 Nov 2019 07:25:06 -0800 (PST)
Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [216.205.24.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC4D512081E for <dns-privacy@ietf.org>; Wed, 27 Nov 2019 07:25:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1574868304; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0KXSbwaDnBbr/SVDECp3FOlpsR/HBYUCyyD0Mxigqds=; b=hOMOvHwppIoID9QrNYXDDU0SsrV8YIdv15wm50N1fGmKO6Eq42fpE+J6yPFWOkVQaoZh0e 39PNSz6SLcvIKQUOPDoURvNbXZjmn/vryJtRrQVhVseVOArsA1+ap9UnzD3l/dWuKxuCCd /pI6D7Uiia2cOEaQU1lW2oleUIzVFaE=
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-co1nam05lp2055.outbound.protection.outlook.com [104.47.48.55]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-39-80QoMGKjNSaVwI6QbqVRWA-1; Wed, 27 Nov 2019 10:25:02 -0500
Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (10.172.118.12) by CY4PR1601MB1110.namprd16.prod.outlook.com (10.172.116.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.16; Wed, 27 Nov 2019 15:25:01 +0000
Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::4aa:ad9b:390a:f7af]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::4aa:ad9b:390a:f7af%12]) with mapi id 15.20.2474.023; Wed, 27 Nov 2019 15:25:01 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Neil Cook <neil.cook@noware.co.uk>, Stephane Bortzmeyer <bortzmeyer@nic.fr>
CC: "dns-privacy@ietf.org" <dns-privacy@ietf.org>, Phillip Hallam-Baker <phill@hallambaker.com>
Thread-Topic: [dns-privacy] Trying to understand DNS resolver 'discovery'
Thread-Index: AQHVpH/sjJ4BY7ksP0eWka61gH491qedvvOAgAD5mmCAAFxiAIAAB2MAgAAB8wA=
Date: Wed, 27 Nov 2019 15:25:00 +0000
Message-ID: <CY4PR1601MB1254DF2F266BC2878C240BC5EA440@CY4PR1601MB1254.namprd16.prod.outlook.com>
References: <CAMm+Lwig+90Riqav6BT6D-0n4pZJFgAr3p996Q+qXJSPt0kqBQ@mail.gmail.com> <20191126180441.GA4452@sources.org> <CY4PR1601MB125470ADE243F60FB710E8C7EA440@CY4PR1601MB1254.namprd16.prod.outlook.com> <20191127142842.GA18601@nic.fr> <04A83ADF-C347-49C2-AB8D-D6D905C179A7@noware.co.uk>
In-Reply-To: <04A83ADF-C347-49C2-AB8D-D6D905C179A7@noware.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.4.0.45
dlp-reaction: no-action
x-originating-ip: [49.37.206.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 721d2320-2063-4855-bada-08d7734df838
x-ms-traffictypediagnostic: CY4PR1601MB1110:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <CY4PR1601MB1110378B9A785A1B2A321CD4EA440@CY4PR1601MB1110.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 023495660C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(376002)(39860400002)(396003)(136003)(199004)(189003)(13464003)(32952001)(256004)(7736002)(305945005)(6116002)(33656002)(5024004)(14444005)(71190400001)(66574012)(71200400001)(80792005)(52536014)(4326008)(8676002)(478600001)(3846002)(8936002)(2906002)(6246003)(316002)(81166006)(54906003)(14454004)(110136005)(81156014)(25786009)(66066001)(74316002)(5660300002)(186003)(9686003)(26005)(7696005)(99286004)(55016002)(11346002)(446003)(76116006)(66556008)(76176011)(66446008)(66476007)(66946007)(966005)(64756008)(6506007)(6436002)(86362001)(53546011)(229853002)(102836004)(6306002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1601MB1110; H:CY4PR1601MB1254.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Nyjxzhw9axygeMSbFRr8SJh0dwqaZpqRyHc30k6SHni86ybyAp+TIYT+C1/M0DuNuYV+IivyvXZTL0AwlSO6T3xIRhU96bKocolSCqz8qm5qeadY7WdudMsjY9P6PYvgfCDwLcLYiT+1PLNkVlcwpMl3HUOCHQZnAsbNbGxsVB4dO30gD/eHRWw3M4OZYDk2hDoP+WxmBAkhSOCdXq5SR5mGpGWSgHSTvdnRuu6Q62B6jxLpHcczl1SuMrTNRMVf4BDPdZcB+hBZxD5R0hGXoE+EC0q15ghKxEPNEiOkPqHPTN4JretU1XYKeLATwre2i9eQDm06FNSVARtGYEQxUD51HDGQ2IiNaPxePaPwKo8rhPagNqwZNpexAC5ebyUVJd/CUrCdwwhs8qvraMiqQAoZRixDgyBfqTeJpfP/uJ3Xv4ZExKsktEL8T6G0hRGcanzITuaXAkKGjuiSbOSE6Z5Ni7FVX3bF6mcUaMg7kxs=
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: mcafee.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 721d2320-2063-4855-bada-08d7734df838
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2019 15:25:00.9598 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: TFk4PXH7V0FBPC6oIpzhjCAoN/U5WWEnXg+1nmM5g1LqBq9CTx51vsm56CrKbttHJiOQT2gzUp+QRlDmmSz0C3R/zh04knv0gmZ2E0WzPwJB+b4QUwUrmV2vW5vbK3cW
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1110
X-MC-Unique: 80QoMGKjNSaVwI6QbqVRWA-1
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/ABVsP3Vu-SK78sEqGIfvYXL_lzA>
Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'
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: Wed, 27 Nov 2019 15:25:07 -0000

> -----Original Message-----
> From: Neil Cook <neil.cook@noware.co.uk>
> Sent: Wednesday, November 27, 2019 8:25 PM
> To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
> Cc: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
> dns-privacy@ietf.org; Phillip Hallam-Baker <phill@hallambaker.com>
> Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'
> 
> CAUTION: External email. Do not click links or open attachments unless you
> recognize the sender and know the content is safe.
> 
> 
> 
> > On 27 Nov 2019, at 14:28, Stephane Bortzmeyer <bortzmeyer@nic.fr>
> wrote:
> 
> > If you use DoH/DoT, it is because you don't trust the access network.
> 
> It says nothing about whether you trust the access network. You *may* be
> using DoH/DoT because you don’t trust the access network. However, you
> may trust the access network for example, but the resolver it gives you may
> be located somewhere else entirely and your queries may be transiting over
> an untrusted network.

Yes. In addition, Internal attacks have become a reality, please see https://tools.ietf.org/html/draft-arkko-arch-internet-threat-model-01#section-4.2.1. 
Clients should use DoT/DoH in all networks.

-Tiru

> 
> > Relying on it to
> > indicate a DoH/DoT resolver is pointless.
> >
> 
> You’re conflating the lack of trust in the access network with discovery. Yes, if
> you don’t trust the access network then you may not want to use a discovery
> protocol to indicate the best way to contact the resolver over DoT/DoH.
> 
> However what if you have configured a resolver manually using an IP address,
> and want to opportunistically upgrade to DoT/DoH if the resolver supports it?
> 
> Neil