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

Vladimír Čunát <vladimir.cunat+ietf@nic.cz> Mon, 16 December 2019 11:54 UTC

Return-Path: <vladimir.cunat+ietf@nic.cz>
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 EE41E120817 for <dns-privacy@ietfa.amsl.com>; Mon, 16 Dec 2019 03:54:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.977
X-Spam-Level:
X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 657We_x6DMQ0 for <dns-privacy@ietfa.amsl.com>; Mon, 16 Dec 2019 03:54:27 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 3A571120811 for <dns-privacy@ietf.org>; Mon, 16 Dec 2019 03:54:26 -0800 (PST)
Received: from [IPv6:2001:1488:fffe:6:c436:ea8a:6136:980a] (unknown [IPv6:2001:1488:fffe:6:c436:ea8a:6136:980a]) by mail.nic.cz (Postfix) with ESMTPSA id D3960140842 for <dns-privacy@ietf.org>; Mon, 16 Dec 2019 12:54:23 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1576497264; bh=0AYOmCmJjeYKvwtuK6XDvCmfnPbdcfWT8URO0AKLM94=; h=From:Date; b=BSci17DJAUdKVcwH2JdhCpraCOxC4Wrn+Ky8R8AA4xs3V1RZWO82I5hGkUEd6obEf 8d/ySa5s0ZXvsYsdJirOfFGvy5mOEkUrxz5bG0LF9SVReDpX8X4siW1HOJbPPTbnvL VKWCtaRvhlBRI2R4W8XgoozrEAQMSM1lb4/sKiOU=
Cc: dns-privacy@ietf.org
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>
From: Vladimír Čunát <vladimir.cunat+ietf@nic.cz>
Message-ID: <20ca7c85-fbf6-ff69-69ca-94117a1de23a@nic.cz>
Date: Mon, 16 Dec 2019 12:55:51 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0
MIME-Version: 1.0
In-Reply-To: <1809728506.26481.1576495365159@appsuite-gw1.open-xchange.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.101.4 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/chLgb959kSGTzJXTQd6n7C0_aMY>
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: Mon, 16 Dec 2019 11:54:29 -0000

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.

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).

--Vladimir