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

Tim Wicinski <tjw.ietf@gmail.com> Thu, 11 July 2024 17:21 UTC

Return-Path: <tjw.ietf@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 84CF5C169411 for <dnsop@ietfa.amsl.com>; Thu, 11 Jul 2024 10:21:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 zjr0GC4zybvJ for <dnsop@ietfa.amsl.com>; Thu, 11 Jul 2024 10:21:17 -0700 (PDT)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 B33A8C169430 for <dnsop@ietf.org>; Thu, 11 Jul 2024 10:21:17 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2ebe40673d8so15894861fa.3 for <dnsop@ietf.org>; Thu, 11 Jul 2024 10:21:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720718476; x=1721323276; 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=CCZrkCUWOVLKWslnIev8RZ9b54fUfRd6qk/DrDAR2mE=; b=W3MHBO6dqS46KmKvTZkSMRTrqGeLQ/Qu2OCDs209BQcqv53x9KnJZaz32IGqOMUD1D jRs8LYnpT+Th8b/1d595UEj77VQWRJkVSTLaaIklhSBrzJpoJcsu/y/1rMGOjltPwKuO lQ5wSOI9NKTVBcx7RKq1NulnDsHmGwEijJpnkgf/DwLobjtzcfZS4fQyF1CoxAgTNVmX NUBzjriuQC84txfMEwODozZvWpaZoP45EF3snErhMBSGL/R7FO6vW4lb/1V+gTCAqLo2 BnxSiGn2whKH9YZhWb6e4ubf1Awj7eebfthOGfl0N6Mo3Hpd7+ddx4tXpQc259Pudn7s BIlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720718476; x=1721323276; 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=CCZrkCUWOVLKWslnIev8RZ9b54fUfRd6qk/DrDAR2mE=; b=Ue5e94MZH6R6TjEri17RszTam3JhhGxFVu/bPKwd3dxztxTLnfnV5HwXz5gaguK+8U NNAr8AgHbxYm3aX9DbMHJsd2OojknFRHZpzPMhcz4aiwggJv8ln0SAoRuQXQ/ZhA4Cyt qgE5l3enJwCrbldqLZIBC1Ym8AbI0+gRHp3nhRw2FXYwfN6iIVqcnacQUwbtlAkkOEJw WE20U6qmYEiQQPoiKSm76eOusT9vrZXc3XDG02OqjtinYxZp7ynJ2FoIauKZmpvZQSXj 0BpTAuqiZ9DIGLIG47hCg88t7LEcPrjLrbuRtW5IDge9TrxT12o7sCuk6ARsoz+L04Rk f6XQ==
X-Gm-Message-State: AOJu0Yx8chViN+k4/eDKglZJb/Fb+ppRlpa+PhyfmIQXbSueTNadqz9X uhIdIOQzxlnyveibQ5uHAU9KzFN5wBPBNhxOKTvttTqx7qSTuUlFh64FMHCAWhmhQiPKjru73Cp sovM85K2OshqCf4MXcy45Q6Avdoo7kQ==
X-Google-Smtp-Source: AGHT+IFw2l249xpvkVZXDbjglj57TiGqerrIklu85DhFFLMR+gaLmGMBOpx91AeBiBQ/RqfwcwNAN7I8ulmFphfQC2Y=
X-Received: by 2002:a05:651c:2204:b0:2ec:56b9:259b with SMTP id 38308e7fff4ca-2eeb31986c0mr64913931fa.49.1720718475536; Thu, 11 Jul 2024 10:21:15 -0700 (PDT)
MIME-Version: 1.0
References: <172047471396.458153.12797163404923712142@dt-datatracker-5f88556585-j5r2h> <CADyWQ+GMHrL2ABd6hMhWujMEO=pDtDXsc3tGDPx72uYqxa4JbQ@mail.gmail.com> <20240709212356.43B838F44515@ary.qy>
In-Reply-To: <20240709212356.43B838F44515@ary.qy>
From: Tim Wicinski <tjw.ietf@gmail.com>
Date: Thu, 11 Jul 2024 13:21:03 -0400
Message-ID: <CADyWQ+EqWf2ERkzM0yK4g=RdQ79JE5ip+Ncoc3McgzOXwRTavw@mail.gmail.com>
To: John Levine <johnl@taugh.com>
Content-Type: multipart/alternative; boundary="0000000000007e31df061cfbfd22"
Message-ID-Hash: YXYJPSC3LVDFUE5QNPLE2EPVDRFM7BK3
X-Message-ID-Hash: YXYJPSC3LVDFUE5QNPLE2EPVDRFM7BK3
X-MailFrom: tjw.ietf@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@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/HfSIeh_HdlqW7V_U9EKesh0G6DA>
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>

I'm going to try to answer a few of these John, as acting Document
Shepherd, herder of author kittens.

On Tue, Jul 9, 2024 at 5:23 PM John Levine <johnl@taugh.com> wrote:

> It appears that Tim Wicinski  <tjw.ietf@gmail.com> said:
> >This is one of those DNSOP documents that may not be relevant to those who
> >implement DNS, or those who operate DNS infrastructure. It is relevant to
> >Applications that use the DNS, and those who focus on what actually DNS
> >records exist in zones.
>
> I took a look and it is indeed greatly improved. Here are some
> implementation issues that may or may not be worth addressing:
>
> It says to put everything in a text record which is fine, but it
> doesn't say anything about how to encode it. There are two competing
> approaches. One says that the string boundaries in the record don't
> matter, so combine all of the strings into one string. The other is to
> treat each string as a token or expression, and the string boundaries
> are the token or expression boundaries. The examples suggest the
> former way, but it should say so. Alternatively, people checking
> domain verification records need to say which way they're doing it.
>

This is valid, and we had some back and forth on how the encodings should
be handled.  It seems some of the motivations were left off. I'll leave
this to the authors for confirmation.


> Wildcards can cause some annoying problems, notably that a wildcard
> will match any tagged name so queries for tagged names can get junk
> answers.
>
> A) Should verification records have a tag at the front of the data to
> identify the record type? There's plenty of prior art for this, e.g.,
> the 63 text records at stanford.edu. Or you might say that a
> sufficiently long random token in the interesting part will prevent
> false positives so there's no need.
>

Are you referring to the "token=value" ? This gets discussed in the Token
Metadata section, and perhaps the document is using the assumption of _
foo-challenge.example.com makes it more relevant?


> 2) If you put records at a tagged name that is supposed to be unique
> and a query returns some junk records and some plausibly good records,
> what do you do? Use what you can? Ignore it all because you probably
> stepped on a wildcard?
>

Wildcards are brought up in Scope of Validation and Security
Considerations, but more explicit text on handling is needed.




>
> Minor nit: why are the CNAME targets quoted?  I've never seen a
> quoted target name and when I look at RFC 1034 it doesn't look
> like it's valid.
>
>
This is totally my fault.  I was going through and cleaning up the examples
(making sure if all examples say "IN TXT" or had quotes around the
TXT records), and in my focus on uniformity, I accidently did this.  I'll
file an issue to remove this.


thanks
tim

R's,
> John
>