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

[Erik Kline <[e-mail]>]

On Tue, 7 May 2019 at 14:07, Thomas Peterson <[e-mail]>
wrote:

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

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.

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
>
> On 06/05/2019 05:25, Martin Thomson wrote:
> > 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
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>
>
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>