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

Phillip Hallam-Baker <ietf@hallambaker.com> Tue, 03 December 2019 19:59 UTC

Return-Path: <hallam@gmail.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 80C0E12002F for <dns-privacy@ietfa.amsl.com>; Tue, 3 Dec 2019 11:59:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.471
X-Spam-Level:
X-Spam-Status: No, score=-1.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.073, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 YmYNB1i3UAwK for <dns-privacy@ietfa.amsl.com>; Tue, 3 Dec 2019 11:59:17 -0800 (PST)
Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com [209.85.167.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DD8D12004C for <dns-privacy@ietf.org>; Tue, 3 Dec 2019 11:59:17 -0800 (PST)
Received: by mail-oi1-f182.google.com with SMTP id x195so4527803oix.4 for <dns-privacy@ietf.org>; Tue, 03 Dec 2019 11:59:17 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=WMm3V/9alnnP3vGZU4HFb0lU3RswnSiQSNt/uVgjlAc=; b=pCCqZwpA9Feh6FwMAFYwzLjgfPVKzJLyQt4IbbmXKgR2zE0Ne5Hej9ApizoC2UrtRt TXdEO5ImF2gnrMzXnv8HHfcv+jnq7vvatxNRgPGHNaOn0mLjTIVVr2rTxMlpWPWvRISy koT9DPFBohaXVS9XetWKxEsZDDTuAKrA6CXRs1ODMkSTXIdw1A2pvOhOTvW5DFY+zsZl C9ToTpDYffnyIjgB1xINg9Iff/6EWVTBQrk3O85wk1Pz45ACIrIK2dx49SxVqCQr6zpY KRHjKCjmaI81vvkaE+uTVPhb5o8ugJPXKWq5NZ7QxaPF0h8pYuwH+AoIuuKrltwkq+VU 0xrg==
X-Gm-Message-State: APjAAAWVgdwA9cwP7dvuaENMwDDKVn6OqRH9fIVSbaP43RFhrrkdyhN2 1+T8CpmUQejwT4OqJW2eiHAK9S68laupfTmcD+JzXg==
X-Google-Smtp-Source: APXvYqw8WFuMSsH1SSEp2n0S6xp5DRpfpR3ywZ/hiyNDkO8/UPUkhqGF4v6gSRdvB8QXC5ZJ/iRxBfd///jasMFylWE=
X-Received: by 2002:aca:7583:: with SMTP id q125mr5476706oic.100.1575403156185; Tue, 03 Dec 2019 11:59:16 -0800 (PST)
MIME-Version: 1.0
References: <CAMm+Lwig+90Riqav6BT6D-0n4pZJFgAr3p996Q+qXJSPt0kqBQ@mail.gmail.com> <20191126180441.GA4452@sources.org> <CY4PR1601MB125470ADE243F60FB710E8C7EA440@CY4PR1601MB1254.namprd16.prod.outlook.com> <20191127142842.GA18601@nic.fr> <716ED073-F71D-412C-A54B-D060DDC6F469@cable.comcast.com> <LO2P265MB05736FAB2D38226EB21D9C72C2440@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <CY4PR1601MB1254A759EC4EA55D3B11603EEA470@CY4PR1601MB1254.namprd16.prod.outlook.com> <CADWWn7WavXNU0jN_dKTjHGyhGoe+UDPxVF0NACJHRitCdvM=2A@mail.gmail.com> <480149195.32229.1575288229166@appsuite-gw1.open-xchange.com> <D205CCCE-DF07-460F-B1EB-D8419E4C7AF5@sky.uk>
In-Reply-To: <D205CCCE-DF07-460F-B1EB-D8419E4C7AF5@sky.uk>
From: Phillip Hallam-Baker <ietf@hallambaker.com>
Date: Tue, 03 Dec 2019 14:59:06 -0500
Message-ID: <CAMm+Lwh6SW2EPdMu44U8mzjNa+pkb075trYPgAx29uryTVQdOA@mail.gmail.com>
To: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000080a68b0598d2218a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/-Mdw5G3CRHD6QCjrKsVSUcR_4Rs>
Subject: Re: [dns-privacy] [EXTERNAL] Re: 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: Tue, 03 Dec 2019 19:59:19 -0000

This business of proxy chains. It seems like it is insoluble. We faced the
same problem when we were trying to deal with spam. There is a huge amount
of complexity there. I have been thinking about this problem for the past
week and I think I have come up with the answer:

None of it matters.

To explain, if Alice decides to use DavesDNS.resolv as her resolution
service, that is the end of the matter as far as Alice is concerned. There
are two possible types of service Dave might provide:

1) Untrusted: Dave returns full DNSSEC paths for all his answers, Alice
checks them. In this case, the source of the data Dave supplies is
irrelevant as the source of trust is whatever DNSSEC apex is used for
validation.

2) Trusted: Dave returns unsigned records and Alice must trust that Dave
obtained the records, processed them etc. in accordance with the agreement
between Alice and Dave.

The point is that Alice ONLY has a relationship here with Dave. How Dave
obtains the records is irrelevant. They can be sent by carrier pigeon for
all it matters. The internals of how Alice obtains the information is
'black box'.

Within any relay structure, there is always a controller who decides which
will be the next relay in turn and unless there is a successful MITM attack
(in which case we should want to force the connection to ABORT) the control
is always with either the sender or the receiver

As far as the Internet protocol is concerned, there is always exactly one
hop, the point where the client side hands control over to the service
side. And this is always the hop that crosses the narrow waist.