Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2538C169437; Tue, 23 Jul 2024 14:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Jgi1-Fa1ZxD; Tue, 23 Jul 2024 14:36:51 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A6B9C169401; Tue, 23 Jul 2024 14:36:51 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id ca18e2360f4ac-81a90913cc3so170509739f.3; Tue, 23 Jul 2024 14:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721770610; x=1722375410; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=AaSzmhNP5AtLwttRir2ERQ0ciYQ/OtQ1m1vnbWinZSQ=; b=kva3m9PZ0VmVeZQKCdEvsPRY5LKimqiMYri18npG6uqEhRqQjMjXolywaLetT8FBYy rtk4JMhPF6gbJ7CjkneMsPO1vr1zPahrvBtdyHbqDM0EJWPLIWFYptVlw+lKiW5k4qCT Mhg4Sc3Hm4bsimB04A0vlwtjZvm2IP07FaLcZjyMdCMo/bytJW2WAKIjGjxiBoY6jtLs tSHhX2pN3+NGUuz+0MhMjjNphSFu6LtJ/dtPXRFLh87PLfmcJA6TstR7CkIQHZdr2Q4M v64iQPXMrAXkzBJQRxenxJhzaAkDGrXn/i+sIK/HMgRdR0Ya0bPhSK3VysLRKOBXL4CR citg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721770610; x=1722375410; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=AaSzmhNP5AtLwttRir2ERQ0ciYQ/OtQ1m1vnbWinZSQ=; b=gaaonKRHUnHs+1qm7yjuMikEdsbrQriQutbb5zusQUpYAYvnUnapqu/i95pxFueEDu 2vwV6adjT854is+tW7jRbb55FE3lfHkz4D01UV5QcfgyT8RbUIlK+lSteaiPQwDfOjQf /MiZmF9XhPlono5gNsgYDNZZz34Y5U1XkU0JcCJeL7PBX+B6/VUYK3OM8mGkwmMWUFJJ rc2vt4MjcaonRgd14hMX5ZnVNPzw11iqmAcup+lTcSItsIgs96/UFuUep4lEJcK2UlEI N6MuqBg+y9xZMI8xaXVVHuM8xLERSctomUKJ2yp8s5JVFaPOy5ZeqtM8dhPHn7tSlsrm Hvng== X-Forwarded-Encrypted: i=1; AJvYcCWyv8xB3uDjFc9aRCdECmc/VJdg5Q5PHNtHbzAX/KTT9Y7Y07E4Jr6Sb0FxOz7q+2y3Qd4RB53FYTikVx5b6ArOYMMI8soH1Rh2wO9b+WmoIA6ZnmmQXgUrneyINbZ8YfNpRsw/aDhKXQ== X-Gm-Message-State: AOJu0YwTbeimpFFAzZRnxCnlV4jTnYaISciiqyos0OtsexlQqBjrzKMX blPU+S/Luaez2uBGR5gxAiglbqMqj//YAJzs6W3A6f9Xi0HRPvT2U4at4uCpUahAAI8gDzS2OJc 1d/Ea7iE9hWiLiYJiHwGWe+vL1pNPsFBLJKQ= X-Google-Smtp-Source: AGHT+IGMflmuRB/b3L3pWZn9lEEWdEEJuOnUfkt8pMibDJFGrD+Q+0+G57kfzNAEBZYqN9PA06eQC2OEgWfzzCOF+K0= X-Received: by 2002:a05:6602:2c81:b0:7f6:1cd3:9659 with SMTP id ca18e2360f4ac-81f71d5d69emr51019939f.6.1721770610365; Tue, 23 Jul 2024 14:36:50 -0700 (PDT) MIME-Version: 1.0 References: <172047471396.458153.12797163404923712142@dt-datatracker-5f88556585-j5r2h> <1E8C3D2F-0F69-4A4F-B29B-C4EA9A5566F3@verisign.com> In-Reply-To: <1E8C3D2F-0F69-4A4F-B29B-C4EA9A5566F3@verisign.com> From: Shumon Huque Date: Tue, 23 Jul 2024 14:36:39 -0700 Message-ID: To: "Wessels, Duane" Content-Type: multipart/alternative; boundary="0000000000009d9ca1061df0f5aa" Message-ID-Hash: GQ3XRJIYJJKALGXBJ7MNOP5DKGZRNE2C X-Message-ID-Hash: GQ3XRJIYJJKALGXBJ7MNOP5DKGZRNE2C X-MailFrom: shuque@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: dnsop , "draft-ietf-dnsop-domain-verification-techniques@ietf.org" X-Mailman-Version: 3.3.9rc4 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?= List-Id: IETF DNSOP WG mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000009d9ca1061df0f5aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 9, 2024 at 2:54=E2=80=AFPM Wessels, Duane wrote: > I read through draft-ietf-dnsop-domain-verification-techniques-05 and hav= e > a few minor comments / suggestions. > Thanks Duane! > > this may result in IP fragmentation, which often does not work > > While it=E2=80=99s true we have come to agree that fragmentation is bad f= or DNS, I > think =E2=80=9Coften does not work=E2=80=9D overstates the situation. I= =E2=80=99d say it works > more often than not and I don=E2=80=99t see draft-ietf-dnsop-avoid-fragme= ntation > making the case that fragmentation does not work. Yes, I agree that this is overstated, and that IP fragmentation often (and maybe even mostly) works. I'm fine with walking this back, but let me tag Paul Wouters here, who I believe added this specific text, for his thoughts= . > Depending on message size limits configured or being negotiated, it > > may alternatively cause the DNS server to "truncate" the UDP response > > and force the DNS client to re-try the query over TCP in order to get > > the full response. Not all networks properly transport DNS over TCP > > and some DNS software mistakenly believe TCP support is optional > > ([RFC9210]). > > I have mixed feelings about this. While perhaps factually true, I think > broken DNS-over-TCP shouldn=E2=80=99t be a reason for not lumping validat= ion > records together. There are other valid reasons to avoid that practice a= nd > networks with broken DNS-over-TCP shouldn=E2=80=99t be coddled. > Maybe more efficient operation of the DNS infrastructure is a better reason to keep responses small rather than coddling to broken DNS/TCP implementations. I'm okay with rewording this. But if you have specific suggested text, please offer it up. > > When multiple distinct services create domain Validation Records at > > the same domain name, > > services don=E2=80=99t create records, users/administrators do. Maybe re= word as > =E2=80=9CWhen multiple distinct services specify placing domain Validatio= n Records > at the same =E2=80=A6=E2=80=9D > Well automated applications can create DNS records too, not just users or admins. But I get your point, and your rewording sounds good to me. > The presence of a Validation Record with a predictable domain name > > (either as a TXT record for the exact domain name where control is > > being validated or with a well-known label) can allow attackers to > > enumerate utilized set of Application Service Providers. > > Not sure I buy this argument. Doesn=E2=80=99t the draft recommend using > predictable names anyway, just one per provider? > Arguably, there is a potential privacy concern here. But there are so many other ways to determine what service provider(s) a domain is using, that I'm not persuaded that we need to address this and obfuscate the verification record too. Erik Nygren - I think this was your proposed change. Can you elaborate on your argument? > 1) A domain name related to the domain name being validated 2) A > > Validation Record, either directly in RDATA or as the target of a > > CNAME (or chain of CNAMEs) > > It=E2=80=99s not clear to me if this an =E2=80=9COR=E2=80=9D list or an = =E2=80=9CAND=E2=80=9D list? > I'd recommend inserting an "and" in there. > > > because base64 relies mixed case > > "utilizes mixed case=E2=80=9D? > Ok. > > > Application owners SHOULD consult the IANA "Underscored and Globally > > Scoped DNS Node Names" registry [UNDERSCORE-REGISTRY] to confirm > > there are no collisions with existing entries. > > maybe this could be less passive as =E2=80=9Cconsult =E2=80=A6 and avoid = using underscore > labels that already exist in the registry=E2=80=9D? > Ok. > > > either the RDATA or a domain name > > > The RECOMMENDED format for a Validation Record's domain name is > > > > > Here and in numerous other places I think =E2=80=9Cdomain name=E2=80=9D m= ight be better as > =E2=80=9Cowner name=E2=80=9D. i.e.: "the owner name of a validation reco= rd" > Yes, I agree. > > > > without having to hand over full DNS access > > what is DNS access? ;-) > We can reword this. I think we mean handing over full access to edit the zone contents to the intermediary. > > > by letting the Intermediary place the random token in their DNS > > in their zone? > Yes, and ok. > > > APIs SHOULD be used to relay instructions. > > Not sure I follow this. An API to relay instructions? > I think this means the application provider has an API that is used to obtain the instructions for how to populate the validation record (owner name, rdata content etc). Though this wasn't my text. I hope one of my co-authors will speak up to confirm. > > > TTL Considerations > > If I were writing software to verify domain control, I probably wouldn=E2= =80=99t > use a caching resolver. I=E2=80=99d just send queries to authoritative n= ame > servers to avoid caching. The draft doesn=E2=80=99t seem to have any tho= ughts on > this one way or the other? > That would certainly avoid most of the TTL considerations stated. But it is more work for the verifier (and requires more DNS knowledge), so I suspect most applications don't do this today. I would be okay however with stating that this one possible way a verifier could work. > CNAME Records for Domain Control Validation > > I think the document could be more clear or explicit that a CNAME target > must exist. i.e., a random token in the owner name of a CNAME record is > not sufficient and such a CNAME whose target does not exist should be > treated as a failure, right? > I don't think this necessarily has to be the case, but in practice it usually is. > Application Service Providers MAY include the random token in a > > domain name that is related to the domain name being validated. An > > proposed rewording: Application Service Providers MAY specify that a > random token be included in the owner name of a validation record. > Ok. Shumon. --0000000000009d9ca1061df0f5aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 9, 2024 at 2:54=E2=80=AFPM We= ssels, Duane <dwessels@verisign= .com> wrote:
I read through draft-ietf-dnsop-domain-ver= ification-techniques-05 and have a few minor comments / suggestions.

Thanks Duane!
=C2=A0
> this may result in IP fragmentation, which often does not work

While it=E2=80=99s true we have come to agree that fragmentation is bad for= DNS, I think =E2=80=9Coften does not work=E2=80=9D overstates the situatio= n.=C2=A0 I=E2=80=99d say it works more often than not and I don=E2=80=99t s= ee draft-ietf-dnsop-avoid-fragmentation making the case that fragmentation = does not work.=C2=A0

Yes, I agree that this= is overstated, and that IP fragmentation often (and maybe even mostly) wor= ks. I'm fine with walking this back, but let me tag Paul Wouters here, = who I believe added this specific text, for his thoughts.

> Depending on message size limits configured or being negotiated, it > may alternatively cause the DNS server to "truncate" the UDP= response
> and force the DNS client to re-try the query over TCP in order to get<= br> > the full response. Not all networks properly transport DNS over TCP > and some DNS software mistakenly believe TCP support is optional
> ([RFC9210]).

I have mixed feelings about this.=C2=A0 While perhaps factually true, I thi= nk broken DNS-over-TCP shouldn=E2=80=99t be a reason for not lumping valida= tion records together.=C2=A0 There are other valid reasons to avoid that pr= actice and networks with broken DNS-over-TCP shouldn=E2=80=99t be coddled.<= br>

Maybe more efficient operation of the D= NS infrastructure is a better reason to keep responses small rather than co= ddling to broken DNS/TCP implementations. I'm okay with rewording this.= But if you have specific suggested text, please offer it up.
=C2= =A0
> When multiple distinct services create domain Validation Records at > the same domain name,

services don=E2=80=99t create records, users/administrators do.=C2=A0 Maybe= reword as =E2=80=9CWhen multiple distinct services specify placing domain = Validation Records at the same =E2=80=A6=E2=80=9D

=
Well automated applications can create DNS records too, not just= users or admins. But I get your point, and your rewording sounds good to m= e.

> The presence of a Validation Record with a predictable domain name
> (either as a TXT record for the exact domain name where control is
> being validated or with a well-known label) can allow attackers to
> enumerate utilized set of Application Service Providers.

Not sure I buy this argument.=C2=A0 Doesn=E2=80=99t the draft recommend usi= ng predictable names anyway, just one per provider?
Arguably, there is a potential privacy concern here. But there= are so many other ways to determine what service provider(s) a domain is u= sing, that I'm not persuaded that=C2=A0we need to=C2=A0address this and= obfuscate the verification record too.

Erik Nygre= n - I think this was your proposed change. Can you elaborate on your argume= nt?

> 1) A domain name related to the domain name being validated 2) A
> Validation Record, either directly in RDATA or as the target of a
> CNAME (or chain of CNAMEs)

It=E2=80=99s not clear to me if this an =E2=80=9COR=E2=80=9D list or an =E2= =80=9CAND=E2=80=9D list?

I'd recomm= end inserting an "and" in there.
=C2=A0

> because base64 relies mixed case

"utilizes mixed case=E2=80=9D?

Ok.=
=C2=A0

> Application owners SHOULD consult the IANA "Underscored and Globa= lly
> Scoped DNS Node Names" registry [UNDERSCORE-REGISTRY] to confirm<= br> > there are no collisions with existing entries.

maybe this could be less passive as =E2=80=9Cconsult =E2=80=A6 and avoid us= ing underscore labels that already exist in the registry=E2=80=9D?

Ok.
=C2=A0

> either the RDATA or a domain name

> The RECOMMENDED format for a Validation Record's domain name is >


Here and in numerous other places I think =E2=80=9Cdomain name=E2=80=9D mig= ht be better as =E2=80=9Cowner name=E2=80=9D.=C2=A0 i.e.: "the owner n= ame of a validation record"

Yes, I= agree.
=C2=A0


> without having to hand over full DNS access

what is DNS access?=C2=A0 ;-)

We can re= word this. I think we mean handing over full access to edit the zone conten= ts to the intermediary.
=C2=A0

> by letting the Intermediary place the random token in their DNS

in their zone?

Yes, and ok.
= =C2=A0

> APIs SHOULD be used to relay instructions.

Not sure I follow this.=C2=A0 An API to relay instructions?

I think this means the application provider has an API= that is used to obtain the instructions for how to populate the validation= record (owner name, rdata content etc). Though this wasn't my text. I = hope one of my co-authors will speak up to confirm.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
> TTL Considerations

If I were writing software to verify domain control, I probably wouldn=E2= =80=99t use a caching resolver.=C2=A0 I=E2=80=99d just send queries to auth= oritative name servers to avoid caching.=C2=A0 The draft doesn=E2=80=99t se= em to have any thoughts on this one way or the other?
=
That would certainly avoid most of the TTL considerations st= ated. But it is more work for the verifier (and requires more DNS knowledge= ), so I suspect most applications don't do this today. I would be okay = however with stating that this one possible way a verifier could work.

> CNAME Records for Domain Control Validation

I think the document could be more clear or explicit that a CNAME target mu= st exist.=C2=A0 i.e., a random token in the owner name of a CNAME record is= not sufficient and such a CNAME whose target does not exist should be trea= ted as a failure, right?

I don't th= ink this necessarily has to be the case, but in practice it usually is.

> Application Service Providers MAY include the random token in a
> domain name that is related to the domain name being validated. An

proposed rewording: Application Service Providers MAY specify that a random= token be included in the owner name of a validation record.

Ok.

Shumon.

--0000000000009d9ca1061df0f5aa--