Re: [dns-privacy] Fwd: New Version Notification for draft-peterson-dot-dhcp-00.txt

"Martin Thomson" <mt@lowentropy.net> Mon, 29 April 2019 00:50 UTC

Return-Path: <mt@lowentropy.net>
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 0896F12013A for <dns-privacy@ietfa.amsl.com>; Sun, 28 Apr 2019 17:50:59 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=LQjWn84y; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cni8MbLT
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 mZOfUvbRSZ9d for <dns-privacy@ietfa.amsl.com>; Sun, 28 Apr 2019 17:50:56 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65B7120090 for <dns-privacy@ietf.org>; Sun, 28 Apr 2019 17:50:56 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id BD1D521650; Sun, 28 Apr 2019 20:50:55 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sun, 28 Apr 2019 20:50:55 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=wUjp1ietP83Khs5/+0re9vZJ32PC k0AIoBu3GTXlJN4=; b=LQjWn84yk/VB2BlJiQOFjiDT6O5fVoVjgSmXj2nhXmxR Qf20DeG/bqHslf+RVwi4qHm+R2xRC0QVbIPrVfrsxiOg2MPjvP6t/M2cFht7t7uU Rgkf6/OUMK5GClpZgwQPrYlceBVtnIejW3BNDH41vvNRLGgP5XKp5G6drNyYDjom mNBuyuSBDZWjgrAuQHgQLH2kTKW6VlvbMe4aGAvsEF1jASfzG9DgFe483J1EWaup 6nTwIMgbMKjALV75dPMDkvQkTisIg4pXX7usJVTUkCXqtAfmQliIekAqxoAod4Lv u5Xn8UlfgFYDklucSYtwRtWd8S5bDQwnKeL9HZMInA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=wUjp1i etP83Khs5/+0re9vZJ32PCk0AIoBu3GTXlJN4=; b=cni8MbLTshckMrRSaMiSXJ 9kSpGglUOALMAYKaDUN8C8+YMtDe4l1dvC/xmBBk3QO6VjlQlxTQ10KMyVnBwQd7 xTZ4+cHRi09o26qgxfeibdIO5Vje37vU7f8qhLxfPBJHHjHQofLMPF1EKTSYFgsr ff36SetBYtkjG3Hw24yzSbawtVerBXZ2IrncrOnioyoryRnYdXpM4euVAO5VVfQQ zcz7BI5c1FPwBexkp3Tx2A4R+IJEvMuxcVMx7EcGvpykPM5YRUwwpdDwCT4tWGZZ S9E0hjEHeafBXaW9zim4ducfD2UPOF1roAthsPon/U4aiGzlu0CJghZFw+RXX1Vg ==
X-ME-Sender: <xms:b0rGXPwzU-7T3wOFhCSRQhtkCE4L_75rX5s0YfhAv29XdNOqPaqwEA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddriedugdefiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvth hfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophih rdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:b0rGXDD088i0h_pHJ8PasABSzlvBv3UJfS3dIfpTE_Hsgu9WBmwaEQ> <xmx:b0rGXB6YsHmJUI50fct0P_bSjdnzfl4CeI0r-rgbZkZ7vgsdsbw-3g> <xmx:b0rGXKruEbVlwq8fQ_2k5BBAJHSvWm2lHbGeprVHf4eTFfAWDE_CnA> <xmx:b0rGXPvichkLUf44BFtuoCNpTa8N_1KH0kX3W1H8DSH1ZucfGNIGZg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1F40A7C199; Sun, 28 Apr 2019 20:50:55 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-448-g5cc1c91-fmstable-20190429v1
Mime-Version: 1.0
Message-Id: <794f6a22-27f0-4652-ac88-a1dc5584e4c3@www.fastmail.com>
In-Reply-To: <fa17715a-74a8-77f3-5310-3da10c40224c@gmail.com>
References: <155637241515.19889.8043108886886364414.idtracker@ietfa.amsl.com> <9a851741-c4e3-44fd-e659-91e7eec8a88a@gmail.com> <60e1d104-a484-e786-5f27-b37916db8ca6@riseup.net> <fa17715a-74a8-77f3-5310-3da10c40224c@gmail.com>
Date: Sun, 28 Apr 2019 20:50:57 -0400
From: Martin Thomson <mt@lowentropy.net>
To: Thomas Peterson <nosretep.samoht@gmail.com>, nusenu <nusenu-lists@riseup.net>
Cc: dns-privacy@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/aT-WjHlM8gRSusE6TWiz1sNq_64>
Subject: Re: [dns-privacy] Fwd: New Version Notification for draft-peterson-dot-dhcp-00.txt
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, 29 Apr 2019 00:50:59 -0000

For DoT and Do53 are similar enough that they can use the same IP address and the DoT configuration only contains a target name.  There is a problem with the first in terms of signaling that DoT is present, but that the server will be using an IP certificate.  I don't know what the answer is there.  I'd first try to see if requiring a name works.

I certainly think that one name is sufficient.  Multiple IP addresses might be useful, but they can all answer to the same name (at least for the same provisioning domain).

DoH is different, and I think that your other draft is right in saying that you just have to use Do53 (or even DoT, though why you would...) to find the IP address for that name.


On Sun, Apr 28, 2019, at 21:12, Thomas Peterson wrote:
> Thank you for the feedback.
> 
> I agree with your suggestion around having host names and pins present 
> in the response and I'll have a think what it might look like - 
> suggestions here or on Github[0] welcome.
> 
> However I disagree that combining both DoT and DoH is appropriate - to 
> me they are different protocols and I am concerned around complexity and 
> size limitations (particularly for DHCPv4) that would be needed.
> 
> Regards
> 
> 
> 0: https://github.com/thpts/draft-peterson-dot-dhcp
> 
> On 2019/04/28 4:12, nusenu wrote:
> > Thomas Peterson:
> >> In a recent discussion in the DoH mailing list around a draft that
> >> describes resolver discovery, Martin Thomson made the suggestion[0]
> >> to use DHCP and RA options instead to transmit both DNS over HTTP
> >> resolver addresses, but more relevant to this WG also DNS over TLS
> >> endpoints as well. I have published draft-peterson-dot-dhcp, which
> >> describe the relevant DHCPv4, DHCPv6, and RA options to support
> >> this.
> > [...]
> >> 0:
> >> https://mailarchive.ietf.org/arch/msg/doh/A2YthHjFwwwpC3d0MrOm1-syH48
> > Thanks for starting this I-D.
> >
> > from the I-D:
> >> Length:  Length of the DNS Servers list in octects
> >>
> >> DNS Servers:  One or more IPv4 addresses of DNS servers
> > The I-D currently only contains IP addresses, not names as
> > proposed by Martin:
> >
> > To quote Martin Thomson's email:
> >> 2. We add a field to DHCP and RA that carries the "DoT resolver".
> >> When this is present, the client resolves this name using the
> >> resolver.  This resolution is unsecured.  The client then connects to
> >> the resulting IP address and validates the certificate it presents
> >> using this name.  This enables easier deployment of DoT because a
> >> certificate for a name is easier to get than an IP certificate (it
> >> also enables use of 1918 address and the like).
> > So I'd suggest to have multiple fields:
> > - IP address (optional)
> > - name (for PKIX verification) (optional)
> > - SPKI pins? (optional)
> >
> > I'd like to see a single document covering DoT and DoH
> > DHCP/RA options (as Martin Thomson suggested)
> > instead of two documents doing the same thing
> > for each protocol separately.
> >
> > kind regards,
> > nusenu
> >
> >
> >
>