Re: [dns-privacy] Discovery of DNS over (not 53) and ALPN

Dan Wing <danwing@gmail.com> Wed, 18 December 2019 02:57 UTC

Return-Path: <danwing@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 EED5A120073 for <dns-privacy@ietfa.amsl.com>; Tue, 17 Dec 2019 18:57:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 xdq7oToqyJiV for <dns-privacy@ietfa.amsl.com>; Tue, 17 Dec 2019 18:57:16 -0800 (PST)
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 2209A120043 for <dns-privacy@ietf.org>; Tue, 17 Dec 2019 18:57:16 -0800 (PST)
Received: by mail-pg1-x52c.google.com with SMTP id x7so403762pgl.11 for <dns-privacy@ietf.org>; Tue, 17 Dec 2019 18:57:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xJlkkg3qSF0FURvV9jqCqwEl9gL78FKhM8wuJ9fdEQU=; b=E/MYr1OJ6f1Mg7mwATBj5NMHxsbOuyuHw1yDtNAbFzigrclmPmll1uXHylp5F18l2t Yf1wIXZY8uqvpZX0rXpAcRbrhaoqubJ/yXa6gdpLBPGpyvePSeWX+6MvV2kwGUUHWVuK /muwYIlYFFJKk9ZVOmDcUUr70DBkRo4gZe/zGrb+ARmIx7h8HtZfjU+PjnH6YtY307qe InpwvCT+bh6zPHo2pGDjwNH8LmYpdHsHSbfzFNj1PVq8jPn+q3XTj0ZKPeCj+NS0mF0+ sL7b0WxdwiXsX9woth/Isf9/QwOfXPMqxo/9EylJZDF6GuTB0W0LD/FsU+j+HuTJQpSB vaYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xJlkkg3qSF0FURvV9jqCqwEl9gL78FKhM8wuJ9fdEQU=; b=BvH/LUEwSxgIFwft5yP2TYtXwBDJfHhrHKM08AGF15wEYd62EMWXlTPJnW9sbGFD/v ei6ieWowKh5B4hxNjv+lAZeBE/bcmm0aa01gd+ncg5b9fh0nKYvR0Qr0cHukwsSFAPuI v+qwKTrZshCP+AKCZ3EKiE+qK7PgHZgZiQgRKN+/tfMR8rNJRGYAqd1QW8JgqDOUKaau Q4C5bdpegJLNoiehGxTHlHINWh8t16nZnJiVJREPGxfEMG6GdSe2CX7uayLR//ext591 lLD6WPb2I60XKgRW5nSxrBXY4joIcilrrX0sg7BM9K6+VUaEWX76WQN74F7PNWADDMct ahxA==
X-Gm-Message-State: APjAAAWnroxv/mQl5Uqs0PBV8FVunP12PcjQMKs9GvjzApaovDSXlwBA /4652oLi+/1tJ3QPEhDOua8cKTLd
X-Google-Smtp-Source: APXvYqyVp3CYBvSndpwtoaq7AMo20pxqr1hQfMi/BLCWPNJeYzf6GIqCWsa6z+L//5Hz6/J/xs9IkA==
X-Received: by 2002:a63:4d1b:: with SMTP id a27mr213026pgb.352.1576637835434; Tue, 17 Dec 2019 18:57:15 -0800 (PST)
Received: from [192.168.1.53] (47-208-190-34.trckcmtc01.res.dyn.suddenlink.net. [47.208.190.34]) by smtp.gmail.com with ESMTPSA id 136sm430841pgg.74.2019.12.17.18.57.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Dec 2019 18:57:14 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
From: Dan Wing <danwing@gmail.com>
In-Reply-To: <20ca7c85-fbf6-ff69-69ca-94117a1de23a@nic.cz>
Date: Tue, 17 Dec 2019 18:57:13 -0800
Cc: dns-privacy@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <CFBD5CB5-3D29-4BB3-8893-2FE84CF6C5AB@gmail.com>
References: <CA+9kkMAmsK746ViRb9tXkJX+t_paOGpWCN3i78WK_t86bLGUnQ@mail.gmail.com> <CAKC-DJhiZAv8gESrhvUc5v86TcRXrfASq4ujQ3BxOYnuENrBjg@mail.gmail.com> <CA+9kkMA1LC2tMKjqF5Lvthhs+3iNS=hUZLoJXqZG9F8COutDUA@mail.gmail.com> <1e2a07b6-89cc-40aa-a617-db39765779a6@www.fastmail.com> <57E4F3C9-B313-4F8F-B7AE-F815A8966BA7@bangj.com> <0269b662-17d6-4302-bb65-afaa627dd2e0@www.fastmail.com> <1809728506.26481.1576495365159@appsuite-gw1.open-xchange.com> <20ca7c85-fbf6-ff69-69ca-94117a1de23a@nic.cz>
To: Vladimír Čunát <vladimir.cunat+ietf@NIC.CZ>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/abh74DfLQdsflocNMfQ-LC5idAc>
Subject: Re: [dns-privacy] Discovery of DNS over (not 53) and ALPN
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, 18 Dec 2019 02:57:18 -0000

On Dec 16, 2019, at 3:55 AM, Vladimír Čunát <vladimir.cunat+ietf@NIC.CZ> wrote:
> On 12/16/19 12:22 PM, Vittorio Bertola wrote:
>> Incidentally, though it is much easier said than done, I think that being able to apply different trust models to different types of networks, so that the OS/application behaves differently when you connect to a random wi-fi in a cafe than when you connect to the usual network in your home, would really help in finding possible middle grounds in terms of deployment models.
> 
> Trust model: I could imagine each client having a pre-configured *list*
> of TLS-certificate names trusted for the purpose of encrypted DNS.  You
> might add your ISP's in there or you might not.
> 
> Then address+port+protocol from DHCP (or any insecure magic) seems fine
> to me - it only matters whether it "matches" an item on the list...
> otherwise there would fallback to a public service.  For example, some
> items of the list would also have a configured IP, or perhaps even
> bootstrapping with the untrusted DNS could be done.

Exactly that, yes.

Said another way:  the network coiuld send you to a malicious DoH/DoT server via the network's DHCP advertisement, or the network could send your queries to a malicious host (by routing the packets towards the malicious host). Both attacks are solved the same way:  by validating the certificate presented in the TLS handshake.  Throwing out DHCP and RA advertisements of DNS won't get us to a happy place, it will get us to vendors building TLS ALPN routing and port routing and lots of other stuff, in order to deliver split-horizon DNS and .local resolution and DNS filtering and avoiding round-trips to corporate HQ's DNS server.

> Of course, here I'm not trying to address what exactly is the client (I
> personally prefer OS level) and how exactly the choice is exposed to the
> human users (a hard question).


Yes, there are difficult questions and answers there.

But when I visit a branch office of my company, I would like to use the local DNS belonging to my company (split horizon DNS, thanks) rather than suffering the round-trip to corporate HQ.

-d