Content-Type: multipart/alternative;
 boundary=Apple-Mail-DB8FCEC9-ED91-4607-8BF8-3395AB2DEB10
Content-Transfer-Encoding: 7bit
From: Brian Dickson <brian.peter.dickson@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Wed, 11 Jun 2025 19:22:58 -0700
Message-Id: <4F949062-8C2D-450E-A4EF-73AD611AA429@gmail.com>
References: <AE182B59-62AD-42BA-8490-FC6F7F80D4F1@strandkip.nl>
In-Reply-To: <AE182B59-62AD-42BA-8490-FC6F7F80D4F1@strandkip.nl>
To: Joe Abley <jabley=40strandkip.nl@dmarc.ietf.org>
Message-ID-Hash: ECCLEVINLE6X3YZBU5QYZNLARMBMJTHK
CC: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= <ondrej@sury.org>,
 dnsop <dnsop@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BDNSOP=5D_Re=3A_Working_Group_Last_Call_for_draft-ietf-dnsop-cds?=
	=?utf-8?q?-consistency?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/dnsop/IhgV27H8Cm_KTAc5FPHMQ2Rub1c>


--Apple-Mail-DB8FCEC9-ED91-4607-8BF8-3395AB2DEB10
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Joe,=20
(Response below or in-line or both=E2=80=A6)
Sent from my iPhone

> On Jun 11, 2025, at 5:14=E2=80=AFAM, Joe Abley <jabley=3D40strandkip.nl@dm=
arc.ietf.org> wrote:
>=20
> =EF=BB=BF
> Hi Ondrej,
>=20
>> On 28 May 2025, at 14:42, Ond=C5=99ej Sur=C3=BD <ondrej@sury.org> wrote:
>>=20
>> this starts a Working Group Last Call for draft-ietf-dnsop-cds-consistenc=
y
>>=20
>> Current versions of the draft is available here:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-cds-consistency/
>>=20
>> The Current Intended Status of this document is: Proposed Standard
>=20
> I don't think the recommendations in the document will do any harm, and so=
me people think they are useful, so I think it is fine to publish this advic=
e. However, I do have some reservations, about which I am happy to be told w=
hy I am wrong.
>=20
> The core advice:
>=20
>    This document therefore specifies that parent-side entities MUST
>    ensure that the updates indicated by CDS/CDNSKEY and CSYNC record
>    sets are consistent across all of the child's authoritative
>    nameservers, before taking any action based on these records.
>=20
> is, in general, not actionable. The full set of authority servers for a zo=
ne are frequently not available from a single vantage point, since a single n=
ameserver address often maps to many different individual servers which may o=
r may not serve consistent information (e.g. when an individual NS target is=
 deployed using anycast in one or more address families). Depending on how y=
ou count them, most nameservers are anycast, so I think it could be said tha=
t this is not a niche observation. The revised advice might boil down to "in=
stead of just looking for an answer as a stub resolver would, look at a rand=
om two out of 100,000 possible authoritative servers" and I'm not convinced t=
hat is much of an improvement.
>=20

I think a balanced reading of the advice, which might depend on favorable in=
terpretation of semantics and definitions, can be actionable and an improvem=
ent.

I think this boils down to looking at signatures as =E2=80=9Cproof of posses=
sion=E2=80=9D and also as an authoritative indication of intent.

The (IMHO) reasonable expectation regarding these specific record types is t=
hat they SHOULD be consistent across an anycast set. This reading of the rec=
ommendations reduces the required queries to one per unique server name/addr=
ess, without weakening the logic or the security model(s) involved.

The presence of multiple signers implies multiple operators, and a trust bou=
ndary that requires a =E2=80=9Ctrust but verify=E2=80=9D approach to preserv=
e the trust model (where the authorization properly belongs to the registran=
t, notwithstanding the involvement of additional parties).

> I am also not very convinced that incoherence between authoritative server=
s or the effects of caching are good reasons to do this. I can see how there=
 are failure modes where those effects could be unhelpful, but there are alw=
ays more failure modes and sometimes I think a failure should just be a fail=
ure and the greater mission  is not actually helped by the application of ye=
t more duct tape.
>=20

Unfortunately, the automation involved prevents the ability to distinguish b=
etween innocent errors and malicious activity, particularly from an otherwis=
e trusted participant. I would expect this present document to create enough=
 of a protection to dissuade such activity by anyone not possessing sufficie=
nt resources to successfully use brute force to defeat the encryption involv=
ed.

Sincerely,
Brian

> With respect to multi-signer configurations, I think the right way to solv=
e that is to sync CDS and CDNSKEY between participating signers just as the c=
orresponding DNSKEY RRs are synced. This seems like a solution that is more e=
ffectively aligned with the problem; to put it another way, multi-signer imp=
lementations would be more robust if they didn't have to make assumptions ab=
out whether the polling advice in this document was followed or not.
>=20
>=20
> Joe
> _______________________________________________
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-leave@ietf.org

--Apple-Mail-DB8FCEC9-ED91-4607-8BF8-3395AB2DEB10
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto">Hi Joe,&nbsp;<div>(Response below or in-lin=
e or both=E2=80=A6)<br id=3D"lineBreakAtBeginningOfSignature"><div dir=3D"lt=
r">Sent from my iPhone</div><div dir=3D"ltr"><br><blockquote type=3D"cite">O=
n Jun 11, 2025, at 5:14=E2=80=AFAM, Joe Abley &lt;jabley=3D40strandkip.nl@dm=
arc.ietf.org&gt; wrote:<br><br></blockquote></div><blockquote type=3D"cite">=
<div dir=3D"ltr">=EF=BB=BF<meta http-equiv=3D"content-type" content=3D"text/=
html; charset=3Dutf-8"><div dir=3D"ltr"></div><div dir=3D"ltr">Hi Ondrej,</d=
iv><div dir=3D"ltr"><br><div>On 28 May 2025, at 14:42, Ond=C5=99ej Sur=C3=BD=
 &lt;ondrej@sury.org&gt; wrote:<br></div><div><br></div></div><blockquote ty=
pe=3D"cite"><div dir=3D"ltr"><span>this starts a Working Group Last Call for=
 draft-ietf-dnsop-cds-consistency</span><br><span></span><br><span>Current v=
ersions of the draft is available here:</span><br><span>https://datatracker.=
ietf.org/doc/draft-ietf-dnsop-cds-consistency/</span><br><span></span><br><s=
pan>The Current Intended Status of this document is: Proposed Standard</span=
><br></div></blockquote><div><br></div><div>I don't think the recommendation=
s in the document will do any harm, and some people think they are useful, s=
o I think it is fine to publish this advice. However, I do have some reserva=
tions, about which I am happy to be told why I am wrong.</div><div><br></div=
><div>The core advice:</div><div><br></div><div><pre style=3D"box-sizing: bo=
rder-box; font-family: var(--bs-font-monospace); font-size: 0.875em; margin-=
top: 0px; margin-bottom: 0px; overflow: auto; caret-color: rgb(33, 37, 41); c=
olor: rgb(33, 37, 41); -webkit-tap-highlight-color: rgba(0, 0, 0, 0); -webki=
t-text-size-adjust: 100%;">   This document therefore specifies that parent-=
side entities MUST
   ensure that the updates indicated by CDS/CDNSKEY and CSYNC record
   sets are consistent across all of the child's authoritative
   nameservers, before taking any action based on these records.</pre></div>=
<div><br></div><div>is, in general, not actionable. The full set of authorit=
y servers for a zone are frequently not available from a single vantage poin=
t, since a single nameserver address often maps to many different individual=
 servers which may or may not serve consistent information (e.g. when an ind=
ividual NS target is deployed using anycast in one or more address families)=
. Depending on how you count them, most nameservers are anycast, so I think i=
t could be said that this is not a niche observation. The revised advice mig=
ht boil down to "instead of just looking for an answer as a stub resolver wo=
uld, look at a random two out of 100,000 possible authoritative servers" and=
 I'm not convinced that is much of an improvement.</div><div><br></div></div=
></blockquote><div><br></div><div>I think a balanced reading of the advice, w=
hich might depend on favorable interpretation of semantics and definitions, c=
an be actionable and an improvement.</div><div><br></div><div>I think this b=
oils down to looking at signatures as =E2=80=9Cproof of possession=E2=80=9D a=
nd also as an authoritative indication of intent.</div><div><br></div><div>T=
he (IMHO) reasonable expectation regarding these specific record types is th=
at they SHOULD be consistent across an anycast set. This reading of the reco=
mmendations reduces the required queries to one per unique server name/addre=
ss, without weakening the logic or the security model(s) involved.</div><div=
><br></div><div>The presence of multiple signers implies multiple operators,=
 and a trust boundary that requires a =E2=80=9Ctrust but verify=E2=80=9D app=
roach to preserve the trust model (where the authorization properly belongs t=
o the registrant, notwithstanding the involvement of additional parties).</d=
iv><br><blockquote type=3D"cite"><div dir=3D"ltr"><div>I am also not very co=
nvinced that incoherence between authoritative servers or the effects of cac=
hing are good reasons to do this. I can see how there are failure modes wher=
e those effects could be unhelpful, but there are always more failure modes a=
nd sometimes I think a failure should just be a failure and the greater miss=
ion &nbsp;is not actually helped by the application of yet more duct tape.</=
div><div><br></div></div></blockquote><div><br></div><div>Unfortunately, the=
 automation involved prevents the ability to distinguish between innocent er=
rors and malicious activity, particularly from an otherwise trusted particip=
ant. I would expect this present document to create enough of a protection t=
o dissuade such activity by anyone not possessing sufficient resources to su=
ccessfully use brute force to defeat the encryption involved.</div><div><br>=
</div><div>Sincerely,</div><div>Brian</div><br><blockquote type=3D"cite"><di=
v dir=3D"ltr"><div>With respect to multi-signer configurations, I think the r=
ight way to solve that is to sync CDS and CDNSKEY between participating sign=
ers just as the corresponding DNSKEY RRs are synced. This seems like a solut=
ion that is more effectively aligned with the problem; to put it another way=
, multi-signer implementations would be more robust if they didn't have to m=
ake assumptions about whether the polling advice in this document was follow=
ed or not.</div><div><br></div><div><br></div><div>Joe</div><span>__________=
_____________________________________</span><br><span>DNSOP mailing list -- d=
nsop@ietf.org</span><br><span>To unsubscribe send an email to dnsop-leave@ie=
tf.org</span><br></div></blockquote></div></body></html>=

--Apple-Mail-DB8FCEC9-ED91-4607-8BF8-3395AB2DEB10--