IETF Logo Mail Archive

Re: [dd] DBOUND scope

Peter Thomassen <peter@desec.io> Tue, 19 March 2024 23:05 UTC

Return-Path: <peter@desec.io>
X-Original-To: dd@ietfa.amsl.com
Delivered-To: dd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCB1C151552; Tue, 19 Mar 2024 16:05:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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=a4a.de
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 94_SI4elkqWW; Tue, 19 Mar 2024 16:05:16 -0700 (PDT)
Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0AA5C14F604; Tue, 19 Mar 2024 16:05:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Cv4kgqmE+TxsV5zZfX0v4sQdBeznJdZVlncJuFW3udU=; b=Aob9cS9RXhTJ1lJqfwcO7DjOYp MV8u+0lMQ8S5SvOIGBSwoJmQyISmsx8ef+zKR7QMwmCevfX7beG2SX2cOf5iurjby+LPYadcpuRzb onaNcwjgre5xs8g7RZk/KrfglpdKWoxYYopGpHGMypdYBscLw2ZveesM98y3eu+WJwJo39DMrxFxS w3C9je32M+7VfTtgA76hGBvFACr/voIxh7kS3eHjjqCFNS7reNUwkDz+eSk8kFzF6om5byra2FbSf FnX4kJPtv1l5jJ7XKXxRJJ/n+NDZbqBcAzKP3P7bhlKMcHC6T/4UF0GkrcAr/5zCT+XIAQDcry76O gWasTK8w==;
Received: from tel3872392.lnk.telstra.net ([139.130.73.134] helo=[192.168.1.143]) by mail.a4a.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <peter@desec.io>) id 1rmiW7-000uOy-90; Wed, 20 Mar 2024 00:05:11 +0100
Message-ID: <f3d01c17-6cc1-4fb2-bca7-57361550ff4a@desec.io>
Date: Wed, 20 Mar 2024 09:05:05 +1000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Ben Schwartz <bemasc=40meta.com@dmarc.ietf.org>, "dd@ietf.org" <dd@ietf.org>
References: <MW4PR15MB437960E4E89D3EDFE8818665B32C2@MW4PR15MB4379.namprd15.prod.outlook.com>
From: Peter Thomassen <peter@desec.io>
In-Reply-To: <MW4PR15MB437960E4E89D3EDFE8818665B32C2@MW4PR15MB4379.namprd15.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dd/OgMJoiU0DJuTxr00ol0dJ3fi9Qc>
Subject: Re: [dd] DBOUND scope
X-BeenThere: dd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DNS Delegation <dd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dd>, <mailto:dd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dd/>
List-Post: <mailto:dd@ietf.org>
List-Help: <mailto:dd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dd>, <mailto:dd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Mar 2024 23:05:20 -0000


On 3/19/24 12:53, Ben Schwartz wrote:
> I saw a few concerns in Zulip today about whether the DBOUND-like work is addressable by /any/​ technical solution.  I think it is.  Additionally, I think:
> 
> * We should use DELEG to solve it.

... at least for parent-side claims.

I have little hope that there's a way to express child-asserted domain boundaries through delegations (because they are asserted by the parent).

So, I think that any effort in this direction (be it now or in the future) should declare child-asserted domain boundaries *out of scope*.

Peter

-- 
https://desec.io/

v2.39.1 | Report a Bug | By Email | System Status