[DNSOP] Re: Fwd: New Version Notification - draft-ietf-dnsop-domain-verification-techniques-05.txt

Shumon Huque <shuque@gmail.com> Tue, 23 July 2024 21:36 UTC

Return-Path: <shuque@gmail.com>
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> <CADyWQ+GMHrL2ABd6hMhWujMEO=pDtDXsc3tGDPx72uYqxa4JbQ@mail.gmail.com> <1E8C3D2F-0F69-4A4F-B29B-C4EA9A5566F3@verisign.com>
In-Reply-To: <1E8C3D2F-0F69-4A4F-B29B-C4EA9A5566F3@verisign.com>
From: Shumon Huque <shuque@gmail.com>
Date: Tue, 23 Jul 2024 14:36:39 -0700
Message-ID: <CAHPuVdUWwpkeiFY=aWq1Yt_MXv8Kx=ToWrWyqn-5MwNKTeCK_A@mail.gmail.com>
To: "Wessels, Duane" <dwessels@verisign.com>
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 <dnsop@ietf.org>, "draft-ietf-dnsop-domain-verification-techniques@ietf.org" <draft-ietf-dnsop-domain-verification-techniques@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: Fwd: New Version Notification - draft-ietf-dnsop-domain-verification-techniques-05.txt
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/RWDwSiwfCtxvUeeWT2wx1SE0QQY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

On Tue, Jul 9, 2024 at 2:54 PM Wessels, Duane <dwessels@verisign.com> wrote:

> I read through draft-ietf-dnsop-domain-verification-techniques-05 and have
> a few minor comments / suggestions.
>

Thanks Duane!


> > this may result in IP fragmentation, which often does not work
>
> While it’s true we have come to agree that fragmentation is bad for DNS, I
> think “often does not work” overstates the situation.  I’d say it works
> more often than not and I don’t see draft-ietf-dnsop-avoid-fragmentation
> 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’t be a reason for not lumping validation
> records together.  There are other valid reasons to avoid that practice and
> networks with broken DNS-over-TCP shouldn’t 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’t create records, users/administrators do.  Maybe reword as
> “When multiple distinct services specify placing domain Validation Records
> at the same …”
>

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’t 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’s not clear to me if this an “OR” list or an “AND” list?
>

I'd recommend inserting an "and" in there.


>
> > because base64 relies mixed case
>
> "utilizes mixed case”?
>

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 “consult … and avoid using underscore
> labels that already exist in the registry”?
>

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 “domain name” might be better as
> “owner name”.  i.e.: "the owner name of a validation record"
>

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’t
> use a caching resolver.  I’d just send queries to authoritative name
> servers to avoid caching.  The draft doesn’t seem to have any thoughts 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.