MIME-Version: 1.0
References: <CAFpG3gdiidmjxoauBw56ZybRabB6JET1Nh5dzTLQq1k0ZAn6Uw@mail.gmail.com>
 <AC1FE98D-8F0E-44E9-98EF-8DD5FF7520D5@fugue.com> <2033.1593617945@localhost>
In-Reply-To: <2033.1593617945@localhost>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 1 Jul 2020 09:45:40 -0700
Message-ID: <CABcZeBNfmPsvnzALz3DR7p0HgEQhJTtiekB--bCsO-QiPyec=w@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Ted Lemon <mellon@fugue.com>, tirumal reddy <kondtir@gmail.com>,
 ADD Mailing list <add@ietf.org>, Paul Vixie <paul@redbarn.org>
Content-Type: multipart/alternative; boundary="000000000000d358a705a9640736"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/_8p9_o0yInpp2GqA1FXJRdoAxLA>
Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH
 Resolvers
Precedence: list

--000000000000d358a705a9640736
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 1, 2020 at 8:39 AM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> Ted Lemon <mellon@fugue.com> wrote:
>     > On Jul 1, 2020, at 07:11, tirumal reddy <kondtir@gmail.com> 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=E2=80=99t be trusted is accepted by everybody=
 except
> the
>     > people whose business models rely on snooping, and I expect the sta=
te
>     > 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 tha=
n
> 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

--000000000000d358a705a9640736
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jul 1, 2020 at 8:39 AM Michae=
l Richardson &lt;<a href=3D"mailto:mcr%2Bietf@sandelman.ca">mcr+ietf@sandel=
man.ca</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><br>
Ted Lemon &lt;<a href=3D"mailto:mellon@fugue.com" target=3D"_blank">mellon@=
fugue.com</a>&gt; wrote:<br>
=C2=A0 =C2=A0 &gt; On Jul 1, 2020, at 07:11, tirumal reddy &lt;<a href=3D"m=
ailto:kondtir@gmail.com" target=3D"_blank">kondtir@gmail.com</a>&gt; wrote:=
<br>
=C2=A0 =C2=A0 &gt;&gt; Secure bootstrapping methods for IoT devices are dis=
cussed both inside<br>
=C2=A0 =C2=A0 &gt;&gt; (e.g., BRSKI) and outside of IETF (DPP, OCF, OMA).<b=
r>
<br>
=C2=A0 =C2=A0 &gt; Indeed, there is a lot of interesting work going on in t=
his space. The<br>
=C2=A0 =C2=A0 &gt; idea that devices can=E2=80=99t be trusted is accepted b=
y everybody except the<br>
=C2=A0 =C2=A0 &gt; people whose business models rely on snooping, and I exp=
ect the state<br>
=C2=A0 =C2=A0 &gt; of the art to improve continuously.<br>
<br>
=C2=A0 =C2=A0 &gt; That said, commissioning protocols are ways of making li=
nk security<br>
=C2=A0 =C2=A0 &gt; (e.g. 802.1x) more usable, and have nothing much to do w=
ith DHCP. They<br>
=C2=A0 =C2=A0 &gt; are generally one-time unless something goes wrong.<br>
<br>
While what you say is true, it misses an important point.<br>
Those mechanisms that result in the device having<br>
=C2=A0 a) an identity<br>
=C2=A0 b) a trust anchor to validate local resources<br>
<br>
mean that other management protocols (such as DHCP!) can be done securely.<=
br>
We never could get DHCP security to work, because device never had identiti=
es<br>
we could leverage.<br>
<br>
This is far afield from whether a *browser* should use a CNAME rather than =
a<br>
new RR-type for discovery.=C2=A0 It feels to me DNS is being used as a hamm=
er<br>
because browsers don&#39;t have access to DHCP</blockquote><div><br></div><=
div>Hmm... Sort of. CNAME is being used rather than another RRType for engi=
neering convenience reasons. <br></div><div><br></div><div>It&#39;s *also* =
inconvenient to do DHCP, but the real concern there is whether the local mi=
ddleboxes etc. will propagate whatever DHCP information is needed. Consider=
 the case where we have a DHCP option that says &#39;here is a DoH server&#=
39; 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 cl=
ients? If not, then the DHCP thing is not going to work super well.<br></di=
v><div><br></div><div>-Ekr</div><div><br></div><div><br></div><div><br></di=
v><div><br></div></div></div>

--000000000000d358a705a9640736--