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

Shumon Huque <shuque@gmail.com> Wed, 24 July 2024 17:17 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 EA48DC1519B4 for <dnsop@ietfa.amsl.com>; Wed, 24 Jul 2024 10:17:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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] 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 8uigRTjWZPYP for <dnsop@ietfa.amsl.com>; Wed, 24 Jul 2024 10:17:23 -0700 (PDT)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 69472C15109F for <dnsop@ietf.org>; Wed, 24 Jul 2024 10:17:23 -0700 (PDT)
Received: by mail-io1-xd2f.google.com with SMTP id ca18e2360f4ac-8138e2f2f69so1923539f.0 for <dnsop@ietf.org>; Wed, 24 Jul 2024 10:17:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721841442; x=1722446242; 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=+fT75Vr5bsPBVuGOXyszEcwnD1gk/m6+2K7aXYE9OPg=; b=GQXCLlUyjdKSlMuqIOcevHdGcSVTXtgqwSxx9m3Bhedf5xS83ZeCdZe3Y6U9y0MsUD 3n4ytaliT52n6rnTMCuVnva9KUT/mZwXsMF+AuQLkf3jHOs432vdxG3j07r0wZyzivbJ 8TXpFj0LIk3uVOpqiGlU8Os988PObf3zYKm+ns8n3CwxSbJwdt7REB9qStCp2UykkMSO qKFgn1Dd0C3NvmIMJMOjek2fXGP/vPZbpRI6G0hxQuVQ4+bIpk0Y1oGmjJiKtZcKD0uH 6iE0Y1qhUNK9FFqJ24+bRT+m0gJGWOSOwg7iAXewseOXP2CKaYqQtD2Q4QOZiGFDu6Jc 5z1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721841442; x=1722446242; 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=+fT75Vr5bsPBVuGOXyszEcwnD1gk/m6+2K7aXYE9OPg=; b=CSD0ia4Ec0enBG/K46P4tFyLRJEZ4Po7DLi5CokqS2BzvqvWYvw6v+IS4vPZAl8svB FpRhptzGjbZ7vzAt+QEnMOZSVH8PGY8Wd2S+57ARoxysg8Qbzf7zENFyI1uESxnQGbFy 0i3z+91jbjQlUrT1Kou1dDdu+cKbsAWuSL/6Mj9MDMrFsvrt/o0wHJ/Fp6ubg+isG64T nXCWXfPGvhbdKOgto5bzME4hgaAxv66zKXvNZH+abnFjICC6mNS70rBocuj+WsGxc9LX kym9hNq2D2WfZqQ9vHck9UAgeESG/hEbNLV/DEBSOKGEfLJ0avlR6LrWTrVCqwXklYQG H+Ow==
X-Gm-Message-State: AOJu0Yxpk/OlUkeb8MZG2+yaIFNQPkKRajtBfOJz+WT89Ah+ormoNxyc L5CfRU66bXnO2NcB+7zJpDPfxXg2gId8QviWbyEf+xkDSdkG/2tan+OIZwH9JkJaJ+YElbvTk19 WEg5978+lm6CqKs1cYOL/OZqxFOw=
X-Google-Smtp-Source: AGHT+IHHv20foQBdnWEzsUklqcb1wQf2V6f7+jVkcJPkr7IFz/dpErh68me2ceWBTKVQbNwngRv5fQk+BIogPC/API4=
X-Received: by 2002:a05:6602:1650:b0:803:f97f:59d8 with SMTP id ca18e2360f4ac-81f7be85b51mr59746239f.0.1721841442348; Wed, 24 Jul 2024 10:17:22 -0700 (PDT)
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
X-Message-ID-Hash: IR36QCQI5DLKAHESW4AUHMDAS2TGPNAV
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@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>
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/LlQOdYO9Re8k-BzLFCu9BLLsCAA>
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 23, 2024 at 3:56 PM John R Levine <johnl@taugh.com> wrote:

>
> > 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 you
> 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 only
> 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 multiple
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.