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

Tom Pusateri <pusateri@bangj.com> Mon, 16 December 2019 04:34 UTC

Return-Path: <pusateri@bangj.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 4CA661200CC for <dns-privacy@ietfa.amsl.com>; Sun, 15 Dec 2019 20:34:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=bangj.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 uVvaaBolb5wh for <dns-privacy@ietfa.amsl.com>; Sun, 15 Dec 2019 20:34:38 -0800 (PST)
Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D090B120024 for <dns-privacy@ietf.org>; Sun, 15 Dec 2019 20:34:37 -0800 (PST)
Received: from [172.16.10.110] (mta-107-13-246-59.nc.rr.com [107.13.246.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id B2B2B310CA; Sun, 15 Dec 2019 23:34:36 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bangj.com; s=201907; t=1576470876; bh=WgUOvmr6kTS2gerf927UcbCtyfNvM+N7gfNFVh9IwVU=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=qvk/c9MsaKlBrIJczDxqGh3kM7zey0MSfwcfgobt+kg0ehbSHjj83W2nysWF0L2Ct oC5KKN+bmGFg8d6orXo0MY0PvcobWbnII4blEL5aswZDinXfp59hehdN3aW5T6upGj YnaSpiUMmWrpKuWSJUVda4A+CJmy1gAbyHNRfSZ6ilJurohYClJ8EWA0LidwzHGhlt 2nCR3J0D/XYXiUV4sRJ5EIbBr8kJwY4YgbBd5C1isDqPQz3AvjjkVfrT80VyuRm/IK rvaUEqfErg/ouMRp8I0o1lpQCJu+EyP+qaKeqTbjMDxR3vgjEKw4PtU2iKDTbm5633 ZWDaZtTiBVvIA==
From: Tom Pusateri <pusateri@bangj.com>
Message-Id: <16B223AB-218C-491E-9386-C426A879FF4D@bangj.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FEC6C4C2-AE32-442C-B639-0293A704FD7C"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Sun, 15 Dec 2019 23:34:36 -0500
In-Reply-To: <0269b662-17d6-4302-bb65-afaa627dd2e0@www.fastmail.com>
Cc: dns-privacy@ietf.org
To: Martin Thomson <mt@lowentropy.net>
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>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/bfuulB_tNlO5WQPmW-OQCzujyLg>
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 04:34:40 -0000


> On Dec 15, 2019, at 11:06 PM, Martin Thomson <mt@lowentropy.net> wrote:
> 
> On Mon, Dec 16, 2019, at 13:40, Tom Pusateri wrote:
>> 
>> 
>>> On Dec 15, 2019, at 7:35 PM, Martin Thomson <mt@lowentropy.net> wrote:
>>> 
>>>> So, let's back up a step: are people interested in using DHCP and RA as 
>>>> part of the discovery story here or not?
>>> 
>>> I am.
>>> 
>>> I tend to think that https://thpts.github.io/draft-peterson-dot-dhcp/draft-peterson-dot-dhcp.html is a reasonable start here. Sure, it makes some assumptions, and leaves some of the harder 8310-style questions unanswered, but that's where I think we should be paying more attention anyway.
>> 
>> This is at least the fourth list that DoT discovery over DHCP has been 
>> discussed (see DoH, DNSOP, and DRIU).
>> 
>> In the previous three times, it was rejected as not a trustworthy source.
> [...]
>> https://www.youtube.com/watch?v=cfEX8zuoRAA <https://www.youtube.com/watch?v=cfEX8zuoRAA>
> 
> I refreshed my memory here and I my interpretation of Ted's presentation is perhaps different than what you took away.  I could make one of two inferences:
> 
> 1. Don't allow the network to configure DNS.  You can't trust it.
> 
> 2. Be clearer about the trust model when you allow the network to provide this information.
> 
> There was a bunch of other noise about the shortcomings of DHCP, but this was the central point.
> 
> The first might be read as a firm argument for certain DoH deployment arrangements. Arrangements that have proven to be highly controversial.  Your own introduction to the next presentation acknowledges the shortcoming and even identified a trust model or two that might fit within the remit of the second option.


My take-away was that it was ok to use DHCP to bootstrap but then a host should then establish trust in other ways. Maybe this was the result of other discussions in combination.

The Android folks seemed happy with using the existing DHCP DNS server information and attempting to connect to that server over port 853 for DoT at the same time as sending queries to port 53 and preferring the TLS connection if it was available.

This required no new DHCP options.

I was under the impression this is how most clients were going to proceed.

Thanks,
Tom