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

"Martin Thomson" <mt@lowentropy.net> Mon, 06 May 2019 04:25 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 24FF9120075 for <dns-privacy@ietfa.amsl.com>; Sun, 5 May 2019 21:25:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, URIBL_BLOCKED=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=vNuB5/YR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=3DI/L63h
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 IVROW4OGU0Hd for <dns-privacy@ietfa.amsl.com>; Sun, 5 May 2019 21:25:14 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E98F120077 for <dns-privacy@ietf.org>; Sun, 5 May 2019 21:25:14 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3861321A7B; Mon, 6 May 2019 00:25:13 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Mon, 06 May 2019 00:25:13 -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=2+TS2FIn+2mIGxnLaPsJP9CdY7j/ CjPEZaygBaD3gRk=; b=vNuB5/YRBFnuNoJxEozkxKu3fGZKMvhv1X5RdG6N0L1V J7QpDb6ItUI7Jxnt1fUxVPGfv2K+YXXfZXbaym1VSGfqKqyv08Wu0/jV0zo5tGsM UfzYVHa3aS1Pcwp2AJ6JBfh3TsTLsJuIqzHdIDC9wShAbevH/BBAlvJzgJVmgkwX JAcrlwDJlvTjYeus/4+Y4nJihLd+erErWXayOp/inDZY21u8RL0l/s5VXrLIAZJf O7SFoJSuEGeHH6Ua1G3O176j5mVt5GapUSYgSsacm8WO5AaSvBCUwg/N4h4u685O jW8k47MZqXQAwrwjQ0wphrHg0WOBkf/ExNcmR9vsVQ==
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=2+TS2F In+2mIGxnLaPsJP9CdY7j/CjPEZaygBaD3gRk=; b=3DI/L63h9SJfg7gZ+7ayuc PYcq+My+RWeVglouYHBN3cePCYrvbA8bHSL6DovWpJz3a7kQrSXPgF2vE3y9l/XR JkWsFNI5oz9FqflkoAzPp9vbhiWVQsq/RSN69wOiFEpWLgDYLezfD+VxkI8zgDam a+kkf/IZQjiYh/33/jUyV4QHNt24da7gL2OUi8SM1qicJ49Jq4XvHZeXQiBv1sYj 7KPRbo97N2iXi+kltCxxthrjniQVeVfoTb2feH0Rg/MzC1ykLL3AaCf6/rijNc+5 fS9E6Ej1v6Eh9AL5Wc4hakf0RlKheo5D9/uCVGwQyXeS7NtVdtoCPZpXL16ogFYg ==
X-ME-Sender: <xms:KLfPXPy-Xy2WR3NICbe5JQ6lhSAoBxUDsOcEygNbAUFEslat3jqRCQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrjeeigdekiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvth hfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophih rdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:KLfPXFMChReC8at84mdBwRLtLGBGCYheLUmzfPeap74r9ZDxA87vgg> <xmx:KLfPXA4NA4yDI7yfUAEQy-bEv-Gt35q9B2pC4qrOdBW2URh9xrd5LA> <xmx:KLfPXGMOhyWJ59XiEHuSAzNUVN4vl26-1HTeeSz9-UChx10pALg7UA> <xmx:KbfPXApApzfwVpx8yX-R90zNqJEk52PLG3I8RmpszncrJqfZSLxzSA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 26A737C12F; Mon, 6 May 2019 00:25:11 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-449-gfb3fc5a-fmstable-20190430v1
Mime-Version: 1.0
Message-Id: <6aba3a8e-f9c8-4476-9746-3fee0e287df1@www.fastmail.com>
In-Reply-To: <977f05e9-36a8-2f1b-14ed-ba4e5e4bcb69@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> <794f6a22-27f0-4652-ac88-a1dc5584e4c3@www.fastmail.com> <977f05e9-36a8-2f1b-14ed-ba4e5e4bcb69@gmail.com>
Date: Mon, 06 May 2019 00:25:11 -0400
From: Martin Thomson <mt@lowentropy.net>
To: Thomas Peterson <nosretep.samoht@gmail.com>
Cc: dns-privacy@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/7GPzqqGqX4cvsqy9ssY0fDL1KSA>
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, 06 May 2019 04:25:16 -0000

So the plan is:

1. new option has > 0 entries: use those IP addresses with DoT.

2. new option has 0 entries: use the other entry, but you can use DoT with confidence.

3. no new option: you are left guessing, but you might be stuck with Do53.

No mention here of how you get the name for certificate validation still.  That's still important.

On Sat, May 4, 2019, at 02:29, Thomas Peterson wrote:
> Thanks Martin.
> 
> I believe there's a trade off decision between providing multiple IP 
> addresses and de-duplicating with Do53 options, offering host names, and 
> complexity. I've updated my version[0] with an attempt to solve the 
> de-duplication, one way we could implement host name support is to 
> either include another field designating the DNS server field as a 
> single host name, or mandate it be such and not have the field.
> 
> Your opinions and those of others on the list appreciated.
> 
> Regards
> 
> 
> 0: 
> https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-peterson-dot-dhcp.txt&url2=https://thpts.github.io/draft-peterson-dot-dhcp/draft-peterson-dot-dhcp.txt
> 
> On 29/04/2019 01:50, Martin Thomson wrote:
> > 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
> >>>
> >>>
> >>>
> >>
>