MIME-Version: 1.0
References: <1EA6A13C-6E60-4ED9-9A50-E33D9D17504C@fugue.com>
 <129b0546-0123-30e0-cfca-8a66721ab046@nthpermutation.com>
In-Reply-To: <129b0546-0123-30e0-cfca-8a66721ab046@nthpermutation.com>
From: Shumon Huque <shuque@gmail.com>
Date: Wed, 29 Apr 2020 22:12:15 -0400
Message-ID: <CAHPuVdU0BkdWszQs0cAE0N2AA9cqJfO=aA70GsmyWw7Hzeb6Cw@mail.gmail.com>
To: Michael StJohns <msj@nthpermutation.com>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009c26ed05a47898e2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/s0Vipk7WKTIyj0Hee8VcOQsmX0U>
Subject: Re: [DNSOP] Validating responses when following unsigned CNAME
 chains...
Precedence: list

--0000000000009c26ed05a47898e2
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 29, 2020 at 8:02 PM Michael StJohns <msj@nthpermutation.com>
wrote:

> See this chain
> https://mailarchive.ietf.org/arch/msg/dnsext/_kxMmGeBUI8OW03tWlcgcCW9QlU/
> (Yup - 12 years ago).
>
> I don't think I ever managed to convince anyone this was a problem.
>

Mike, perhaps there was some confusion on this point 12 years ago, but
deployed validator code all agree on what the state is. I encourage
implementers to confirm (or correct me if I misstate something).


> If you've got a validated CNAME, that points into an unsecured zone,
> then your state is probably Unsecure (if you treat it similar to a
> secure delegation to an unsigned zone) or Unknown.
>

Assuming the unsecured target zone can be proved to such (because of an
authenticated "insecure" referral, or opt-out referral on the way down to
that
zone), then the state is Insecure - the validator will return the answer,
but not
set AD=1. If the zone is unsigned, yet had a secure referral from the parent
(signed DS), then the state is Bogus, and the validator will return SERVFAIL
(unless the downstream querier set CD=1 and the validator implements a
BAD cache, in which case it will return the bogus answer).

If you've got an securely insecure (e.g. delegation was to an insecure
> zone at some point) CNAME that points into a secure zone, I would say
> your result is probably Bogus  or Unsecure as you haven't any way to
> evaluate trust.  I don't think you can bootstrap security this way.
>

Deployed validator code says Insecure. It can't be Bogus, because the
validator
has determined that the CNAME is a demonstrably insecure zone,

Shumon.

--0000000000009c26ed05a47898e2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Wed, Apr 29, 2020 at 8:02 PM Michael S=
tJohns &lt;<a href=3D"mailto:msj@nthpermutation.com">msj@nthpermutation.com=
</a>&gt; wrote:</div><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex">
See this chain <br>
<a href=3D"https://mailarchive.ietf.org/arch/msg/dnsext/_kxMmGeBUI8OW03tWlc=
gcCW9QlU/" rel=3D"noreferrer" target=3D"_blank">https://mailarchive.ietf.or=
g/arch/msg/dnsext/_kxMmGeBUI8OW03tWlcgcCW9QlU/</a> <br>
(Yup - 12 years ago).<br>
<br>
I don&#39;t think I ever managed to convince anyone this was a problem.<br>=
</blockquote><div><br></div><div>Mike, perhaps there was some confusion on =
this point 12 years ago, but</div><div>deployed validator code all agree on=
 what the state is. I encourage=C2=A0</div><div>implementers to confirm (or=
 correct me if I misstate something).</div><div>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">
If you&#39;ve got a validated CNAME, that points into an unsecured zone, <b=
r>
then your state is probably Unsecure (if you treat it similar to a <br>
secure delegation to an unsigned zone) or Unknown.<br></blockquote><div><br=
></div><div>Assuming the unsecured target zone can be proved to such (becau=
se of an=C2=A0</div><div>authenticated &quot;insecure&quot; referral, or op=
t-out referral on the way down to that</div><div>zone), then the state is I=
nsecure - the validator will return the answer, but not</div><div>set AD=3D=
1. If the zone is unsigned, yet had a secure referral from the parent</div>=
<div>(signed DS), then the state is Bogus, and the validator will return SE=
RVFAIL</div><div>(unless the downstream querier set CD=3D1 and the validato=
r implements a</div><div>BAD cache, in which case it will return the bogus =
answer).</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">
If you&#39;ve got an securely insecure (e.g. delegation was to an insecure =
<br>
zone at some point) CNAME that points into a secure zone, I would say <br>
your result is probably Bogus=C2=A0 or Unsecure as you haven&#39;t any way =
to <br>
evaluate trust.=C2=A0 I don&#39;t think you can bootstrap security this way=
.<br></blockquote><div><br></div><div>Deployed validator code says Insecure=
. It can&#39;t be Bogus, because the validator</div><div>has determined tha=
t the CNAME is a demonstrably insecure zone,</div><div><br></div><div>Shumo=
n.</div><div><br></div></div></div>

--0000000000009c26ed05a47898e2--