MIME-Version: 1.0
References: 
 <172047471396.458153.12797163404923712142@dt-datatracker-5f88556585-j5r2h>
 <CADyWQ+GMHrL2ABd6hMhWujMEO=pDtDXsc3tGDPx72uYqxa4JbQ@mail.gmail.com>
 <20240709212356.43B838F44515@ary.qy>
 <CAHPuVdX=8Lv3r41g8YVkjRQ-YCx9r+nB94wqep7oG+_o20EHfA@mail.gmail.com>
 <453c7d44-355f-571b-70b9-e8e69ab90259@taugh.com>
In-Reply-To: <453c7d44-355f-571b-70b9-e8e69ab90259@taugh.com>
From: Shumon Huque <shuque@gmail.com>
Date: Wed, 24 Jul 2024 10:17:10 -0700
Message-ID: 
 <CAHPuVdWwiFAnK8VZYJv4OVk=9v5YCCT4pHykW4Ei3PLEyTZvfg@mail.gmail.com>
To: John R Levine <johnl@taugh.com>
Content-Type: multipart/alternative; boundary="00000000000087e958061e017371"
Message-ID-Hash: IR36QCQI5DLKAHESW4AUHMDAS2TGPNAV
CC: dnsop@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>
Precedence: list
Subject: =?utf-8?q?=5BDNSOP=5D_Re=3A_Fwd=3A_New_Version_Notification_-_draft-ietf-dns?=
	=?utf-8?q?op-domain-verification-techniques-05=2Etxt?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/dnsop/LlQOdYO9Re8k-BzLFCu9BLLsCAA>

--00000000000087e958061e017371
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 23, 2024 at 3:56=E2=80=AFPM John R Levine <johnl@taugh.com> wro=
te:

>
> > I don't think this is necessary. Some applications do this today, but
> > I suspect it is to make it easier to identify the application from the
> > sea of verification TXT records at the zone apex. Since the draft
> > recommends application specific validation record "owner names",
> > that seems to be a better place to make this identification.
>
> The issue is that a wildcard will match every possible owner name.  If yo=
u
> are confident that there is enough entropy in the tokens that no verifier
> will ever be confused, OK.  But since the token is supposed to be the onl=
y
> thing at the _prefix name, how about saying that if a verifier sees more
> than one record or a junk record, it gives up rather than trying to guess
> which is the right one.
>

I'm not sure I follow.

A wildcard is a match of last resort. If there is an explicit validation
record deployed at _foobar.example.com/TXT then a wildcard at
*.example.com.TXT (even if it exists) has no bearing on the query for
the former. So, no extra unrelated validation records will be returned,
and there is nothing to be confused about.

On your last point, yes, I think we can say that if a verifier sees multipl=
e
validation records, they can abort.

If the token is time limited you'd might get a new one for the existing
> name but I don't think there should be a case when you'd need to publish
> both new and old.  As soon as you have the new one you install it and
> throw away the old one.
>

I agree with this. The draft already recommends time limited validation
records, and that they should be deleted after verification.

Shumon.

--00000000000087e958061e017371
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Tue, Jul 23, 2024 at 3:56=E2=80=AFPM J=
ohn R Levine &lt;<a href=3D"mailto:johnl@taugh.com">johnl@taugh.com</a>&gt;=
 wrote:</div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">
<br>
&gt; I don&#39;t think this is necessary. Some applications do this today, =
but<br>
&gt; I suspect it is to make it easier to identify the application from the=
<br>
&gt; sea of verification TXT records at the zone apex. Since the draft<br>
&gt; recommends application specific validation record &quot;owner names&qu=
ot;,<br>
&gt; that seems to be a better place to make this identification.<br>
<br>
The issue is that a wildcard will match every possible owner name.=C2=A0 If=
 you <br>
are confident that there is enough entropy in the tokens that no verifier <=
br>
will ever be confused, OK.=C2=A0 But since the token is supposed to be the =
only <br>
thing at the _prefix name, how about saying that if a verifier sees more <b=
r>
than one record or a junk record, it gives up rather than trying to guess <=
br>
which is the right one.<br></blockquote><div><br></div><div>I&#39;m not sur=
e I follow.</div><div><br></div><div>A wildcard is a match of last resort. =
If there is an explicit validation</div><div>record deployed at _<a href=3D=
"http://foobar.example.com/TXT">foobar.example.com/TXT</a> then a wildcard =
at</div><div>*.example.com.TXT (even if it exists) has no bearing on the qu=
ery for</div><div>the former. So, no extra unrelated validation records wil=
l be returned,</div><div>and there is nothing to be confused about.</div><d=
iv><br></div><div>On your last point, yes, I think we can say that if a ver=
ifier sees multiple</div><div>validation records, they can abort.</div><div=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If the token is time limited you&#39;d might get a new one for the existing=
 <br>
name but I don&#39;t think there should be a case when you&#39;d need to pu=
blish <br>
both new and old.=C2=A0 As soon as you have the new one you install it and =
<br>
throw away the old one.<br></blockquote><div><br></div><div>I agree with th=
is. The draft already recommends time limited validation<br></div><div>reco=
rds, and that they should be deleted after verification.</div><div><br></di=
v><div>Shumon.</div><div><br></div></div></div>

--00000000000087e958061e017371--