Re: [DNSOP] Draft for dynamic discovery of secure resolvers

manu tman <chantr4@gmail.com> Mon, 20 August 2018 16:51 UTC

Return-Path: <chantr4@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382EF130E50 for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 09:51:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=no 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 GloJqaIZhUqP for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 09:51:12 -0700 (PDT)
Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 9766C126BED for <dnsop@ietf.org>; Mon, 20 Aug 2018 09:51:12 -0700 (PDT)
Received: by mail-it0-x230.google.com with SMTP id s7-v6so264407itb.4 for <dnsop@ietf.org>; Mon, 20 Aug 2018 09:51:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lkjvrJ5N6pKka9ZM9qX2mPwKO3nQCbIky+bCIKCmvqo=; b=UVuonjRTb+/1pkHCnaWs78WmYX35l1xRoYOWxB10YnWzwvoAziBuSy2e6Ab7rSQOs1 MLfn2b/6DaUAcg2hqXTDVSLVF88oXq/hzrunGDFbMdCgKcAFEwfD7lODky6/UZJp0zfT 3UbpH9St5BK7cIvb5SXpWa/i471txMEgnNfNv/PfzIgQzPbgA3d5bnC1NJ+MZ1I7LanU 9EwjyszGnOHEFW7n3yTxBI5xXKySRAIyC+oIe7AQBfjuibX3ABbKeqq33z+KN7/PGzK3 h9QLeOoOkY19ncS+9cpwtJ0Wj4tzfJlu9qZP+PUtzYruvNA3/JeFPT0m599mKM6plMk0 z5PA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lkjvrJ5N6pKka9ZM9qX2mPwKO3nQCbIky+bCIKCmvqo=; b=QEdnMcIG1gYEfx/IFchVmHr9m7zK3iewnU7UIA9E1JZ0Z4r0xFrCdJtpw7mTkmGYnI mNS0IDKgPftpMQIf9OoVIFgLkCKucHY/0CxjFgEwMhfgAs0Wp+ON/AXv9M5sFJuvsILQ dA7LNPciPZrd1XxM5IWQhwDkF1POkWRzTxTk5LS3P0NyfPkOPClKVSOEcSOqIV49X3mc eUD/uHC8g7vrks0/quLL0zbWh6THG14C+BgwmAV7Kv7LJggkarUwdVdLMBbozVHwdsBE yiqe1EDU3pXP1KAjNp0jBwyGhLvOj+zwzDNHwKF3STkyWJwcxrXGB02yXHAHjvaeTsAv BcSQ==
X-Gm-Message-State: AOUpUlFD7n5VlXJ+tpcEDqe9fJ4QtuZueXQqxVzzhxoMYsjkO6IN1TEw eJ5W3qbJrsfYLjYiIAX7Ur9t1460FT/8Y8bji8M=
X-Google-Smtp-Source: AA+uWPx9NXox4MGZnTtgqVhpJeI/+/+XvXhwHUHy8NNceItAowxDWO87dHvrGNgJ4P24lhcmv/inUBV/lY7IC4rtCTw=
X-Received: by 2002:a24:250f:: with SMTP id g15-v6mr35403476itg.108.1534783871688; Mon, 20 Aug 2018 09:51:11 -0700 (PDT)
MIME-Version: 1.0
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com> <alpine.DEB.2.20.1808201720060.3596@grey.csi.cam.ac.uk>
In-Reply-To: <alpine.DEB.2.20.1808201720060.3596@grey.csi.cam.ac.uk>
From: manu tman <chantr4@gmail.com>
Date: Mon, 20 Aug 2018 09:50:59 -0700
Message-ID: <CAArYzrJwPSfTLKYgy4Xtn-XZwqvJ2M-UStDcsOtFzzKEos-byg@mail.gmail.com>
To: dot@dotat.at
Cc: mvavrusa=40cloudflare.com@dmarc.ietf.org, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007aac770573e0b72c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Whkjb0KmKLnvwYZU1yPUTgRZAk8>
Subject: Re: [DNSOP] Draft for dynamic discovery of secure resolvers
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Aug 2018 16:51:14 -0000

I am going to echo my original comment on the draft as it may have been
lost in this long thread and it will make sense to keep this close to
related convo.

```
As for feedback on the draft options.
- Section 2.3: Why DoH has no option data? The IP from the DNS recursive
name server option merely provide an IP to connect to. DoH server may have
a cert that will validate for a hostname. The endpoint may or may not be
/dns-query . How about alternate ports? It seems a having the URI as part
of the data would be useful ( e.g https://dnsserver.example.net/dns-query ,
https://10.10.10.10:8443/dns-query , https://2001:DB8::1/doh ...)
- the draft as is, assumes that port 853 will be used for DoT, 443 for DoH.
Being able to provide alternate ports could be a plus
- It is not clear to me if the options apply to all nameservers from the
dns recursive nameserver option, or if there needs to be 1 option for each
nameserver. I could for instance have nameserver1 which does DoT + DoH
while nameserver2 does none. In this case, I would get option 147 with
option len of 2 for the first server, followed by option 147 with option
len of 0 for the second one.
- A DHCP option should be able to be set multiple time, so one can
configure TLS_SPKI with multiple values. May be useful for rotations and
such.
```

Manu

On Mon, Aug 20, 2018 at 9:42 AM Tony Finch <dot@dotat.at> wrote:

> Marek Vavruša <mvavrusa=40cloudflare.com@dmarc.ietf.org> wrote:
> >
> >
> https://github.com/vavrusa/draft-dhcp-dprive/blob/master/draft-dhcp-dprive.txt
>
> This is interesting to me because I want to support DoTH on my campus
> resolvers.
>
> Regarding DoT, it seems to me that a super simple way for the client to
> be able to authenticate the server would be to include the server's IP
> address(es) in the subjectAltName field. This wouldn't require a DHCP
> extension, and nicely supports opportunistic updgrade. I'm afraid I wasn't
> paying attention when RFC 8310 was being prepared so I don't know why it
> excludes iPAddress authentication.
>
> Regarding DoH, the DHCP option ought to include a URI template (there
> isn't a .well-known for DoH). I plan to set up my servers so that
> misdirected attempts to get web pages from the DoH server are redirected
> to the relevant documentation; that's much easier if the DoH endpoint
> isn't at the server root.
>
> A URI template usually implies the need for DNS queries to resolve the
> server name (unless it's an address literal). Would it be plausible to
> allow the client to assume that the DoH server IP addresses are the same
> as the DNS server addresses, so it can skip the lookup? I guess that would
> be too annoying for operators that want their DoH servers to be separate
> from their normal DNS resolvers, so maybe it's a bad idea :-)
>
> Tony.
>
> (PS. DoTH is clearly what happens if someone suggests "DoNT" but we do it
> anyway.)
>
> --
> f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
> fight poverty, oppression, hunger, ignorance, disease, and
> aggression_______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>