Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers

[Eric Rescorla <[e-mail]>]

On Wed, Jul 1, 2020 at 8:39 AM Michael Richardson <[e-mail]>
wrote:

>
> Ted Lemon <[e-mail]> wrote:
>     > On Jul 1, 2020, at 07:11, tirumal reddy <[e-mail]> wrote:
>     >> Secure bootstrapping methods for IoT devices are discussed both
> inside
>     >> (e.g., BRSKI) and outside of IETF (DPP, OCF, OMA).
>
>     > Indeed, there is a lot of interesting work going on in this space.
> The
>     > idea that devices can’t be trusted is accepted by everybody except
> the
>     > people whose business models rely on snooping, and I expect the state
>     > of the art to improve continuously.
>
>     > That said, commissioning protocols are ways of making link security
>     > (e.g. 802.1x) more usable, and have nothing much to do with DHCP.
> They
>     > are generally one-time unless something goes wrong.
>
> While what you say is true, it misses an important point.
> Those mechanisms that result in the device having
>   a) an identity
>   b) a trust anchor to validate local resources
>
> mean that other management protocols (such as DHCP!) can be done securely.
> We never could get DHCP security to work, because device never had
> identities
> we could leverage.
>
> This is far afield from whether a *browser* should use a CNAME rather than
> a
> new RR-type for discovery.  It feels to me DNS is being used as a hammer
> because browsers don't have access to DHCP


Hmm... Sort of. CNAME is being used rather than another RRType for
engineering convenience reasons.

It's *also* inconvenient to do DHCP, but the real concern there is whether
the local middleboxes etc. will propagate whatever DHCP information is
needed. Consider the case where we have a DHCP option that says 'here is a
DoH server' and the router provided CPE provides that. But if I have a
third party WiFi router, it consumes that option. Does it then propagate
that to the clients? If not, then the DHCP thing is not going to work super
well.

-Ekr