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

From: Thomas Peterson <[email-masked]>
Date: Fri, 3 May 2019 17:29:10 +0100

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

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 06 May 2019 00:25:11 -0400

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.

---

From: Dan Wing <[email-masked]>
Date: Mon, 6 May 2019 11:24:21 -0700

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

We wrote a procedure where an endpoint can see if the local network's DNS servers are already on the endpoint's trust list (e.g., you trust your ISP's DoH server, visit a friend using that same ISP so you want to trust that same configuration at your friend's house).  When joining a network where you don't trust that network's DNS servers, the user is asked if they want to trust that network's DNS servers for DoH.  We also added some policy communication so the user can determine if they like the DNS server's policies (e.g., selling browsing history, filtering malware, etc.).   With the policy information, the endpoint could avoid bugging the user if that network's DoH policies aren't at all aligned with the user's desires (e.g., user always wants malware filtering or wants parental filtering).

  https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-02#section-3

Earlier versions of that same I-D did different things; we have reduced scope considerably.

-d

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 06 May 2019 20:39:57 -0400

On Tue, May 7, 2019, at 04:24, Dan Wing wrote:
> We wrote a procedure where an endpoint can see if the local network's 
> DNS servers are already on the endpoint's trust list (e.g., you trust 
> your ISP's DoH server, visit a friend using that same ISP so you want 
> to trust that same configuration at your friend's house).  When joining 
> a network where you don't trust that network's DNS servers, the user is 
> asked if they want to trust that network's DNS servers for DoH.  We 
> also added some policy communication so the user can determine if they 
> like the DNS server's policies (e.g., selling browsing history, 
> filtering malware, etc.).   With the policy information, the endpoint 
> could avoid bugging the user if that network's DoH policies aren't at 
> all aligned with the user's desires (e.g., user always wants malware 
> filtering or wants parental filtering).

Hi Dan,

I wasn't talking about trust, I was simply talking about ensuring that the server you are talking to the one is the one the network intends.

But how you might automate some of the process of "trust"  is not something I think we should be talking about until we know what "trust" looks like in more detail.  There is probably a place for building whitelists, but it's not clear that the DoH server someone "trusts" at home is something they want to "trust" when they are someplace else.

--Martin

---

From: Thomas Peterson <[email-masked]>
Date: Tue, 7 May 2019 22:06:54 +0100

If a mechanism that facilitates certificate validation is important then 
the only two options I believe we have are:

A: Providing a host name only within the option, and expect clients to 
use Do53 to resolve it, performing host name validation against the 
certificate CommonName or SubjectAltName.

B: Using IP address(es) only, with either Do53 option or this option 
providing the IP addresses, in addition to a non-DNS related identifier 
to facilitate certificate validation - perhaps the Serial Number, 
Subject Key Identifier or some other field or a derived field of data. 
Having an option with both a host name and IP addresses makes no real 
sense to me.

It seems the first option is probably the most appropriate and I should 
rewrite the draft accordingly, would you agree?

Regards

---

From: Erik Kline <[email-masked]>
Date: Tue, 7 May 2019 15:23:23 -0700

> certificate CommonName or SubjectAltName.

FWIW, this is what Android "Private DNS" does: bootstrap using
network-assigned nameservers and then do the usual validation dance.

If there were some URL-ish representation of DoT vs DoH then a list of UTF8
strings might suffice.

> >>> 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.
> >>>
> >>>
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 07 May 2019 20:34:49 -0400

> the only two options I believe we have are:

Yes, I believe that certificate validation is important, if not critical.  As I said earlier, the process by which a DoT (or DoH) server is contacted is materially different than the network configuration process.

> Having an option with both a host name and IP addresses makes no real 

I want to dig into this.  How do you think that hostname + IP is nonsensical?  I am given a name and some candidate IP addresses for that name.  The security all hangs off the name, but I need the IP addresses to make a connection. 

In a way it is not fundamentally different than your suggestion to include a serial number or SPKI.  The important difference is that TLS stacks know how to deal with names and we have (elaborate) systems for ensuring that a host that claims to control a name really does.  A name allows us to use all that infrastructure.

---

From: Brian Haberman <[email-masked]>
Date: Wed, 8 May 2019 07:58:40 -0400

If an RA option were to carry the IP address of the name server, that
could be done within the framework of RFC 8106. That document already
describes an RA option for advertising DNS servers to clients.

Regards,
Brian

On 4/29/19 5:28 AM, Ole Troan wrote:
>> 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.
> 
> 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
>

---

From: Thomas Peterson <[email-masked]>
Date: Wed, 8 May 2019 13:54:18 +0100

Assuming that the host name must be a FQDN and not another 
representation (say a wildcard e.g. "*.example.com") to me it appears 
redundant to have both IP addresses and a host name and that having both 
present really only mitigates a client making a Do53 query. It also 
potentially permits scenarios like a network sending an option of an IP 
address and host name, however the host name does not actually resolve 
via any resolver to that IP address. It could also permit or encourage 
more multi-horizon DNS being deployed in networks, a subject I have 
generally negative views of.

Perhaps what is missing that would help steer this would be a threat 
model around client DNS bootstrapping before we attempt to go one 
direction or another?

Regards