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

From: Thomas Peterson <[email-masked]>
Date: Sat, 27 Apr 2019 15:30:30 +0100

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.

Could I please get feedback, specifically if the WG is in support of it.

Regards

0: https://mailarchive.ietf.org/arch/msg/doh/A2YthHjFwwwpC3d0MrOm1-syH48

On 27/04/2019 13:40, [email-masked] wrote:
> A new version of I-D, draft-peterson-dot-dhcp-00.txt
> has been successfully submitted by Thomas Peterson and posted to the
> IETF repository.
>
> Name:		draft-peterson-dot-dhcp
> Revision:	00
> Title:		DNS over Transport Layer Security announcements using DHCP or Router Advertisements
> Document date:	2019-04-27
> Group:		Individual Submission
> Pages:		5
> URL:            https://www.ietf.org/internet-drafts/draft-peterson-dot-dhcp-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-peterson-dot-dhcp/
> Htmlized:       https://tools.ietf.org/html/draft-peterson-dot-dhcp-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-peterson-dot-dhcp
>
>
> Abstract:
>     This specification describes a DHCP option and Router Advertisement
>     (RA) extension to inform clients of the presence of DNS resolvers
>     with Transport Layer Security (TLS).
>
>                                                                                    
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>

---

From: nusenu <[email-masked]>
Date: Sat, 27 Apr 2019 19:12:00 +0000

Thomas Peterson:
> 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

-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu

---

From: Thomas Peterson <[email-masked]>
Date: Sun, 28 Apr 2019 20:11:54 +0900

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

---

From: "Martin Thomson" <[email-masked]>
Date: Sun, 28 Apr 2019 20:50:57 -0400

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.

---

From: Ole Troan <[email-masked]>
Date: Mon, 29 Apr 2019 11:28:14 +0200

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

I'm not very keen on yet another DNS configuration option.
But if you were to do it in the RA, I wonder if it wouldn't be cleaner to do it with the universal RA approach:

https://tools.ietf.org/html/draft-troan-6man-universal-ra-option-01

Currently the DNS option is defined as (in CDDL):
 dns = {
      dnssl : [* tstr]
      rdnss : ipv6-addresses : [* tstr]
      ? lifetime : uint
 }      

And you could just add a new attribute for transport:

 dns = {
      dnssl : [* tstr]
      rdnss : ipv6-addresses : [* tstr]
      ? lifetime : uint
      transport : "udp" / "tls" / "https"
 }

Ole