Re: [dbound] BoF request for IETF 115 (fwd)

John R Levine <johnl@taugh.com> Fri, 23 December 2022 03:07 UTC

Return-Path: <johnl@taugh.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A08C14F74E for <dbound@ietfa.amsl.com>; Thu, 22 Dec 2022 19:07:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-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=iecc.com header.b=DsPNeeq3; dkim=pass (2048-bit key) header.d=taugh.com header.b=n7Lm+p7t
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 RgrL2VObE1_8 for <dbound@ietfa.amsl.com>; Thu, 22 Dec 2022 19:07:39 -0800 (PST)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 2EA5BC14F746 for <dbound@ietf.org>; Thu, 22 Dec 2022 19:07:38 -0800 (PST)
Received: (qmail 55295 invoked from network); 23 Dec 2022 03:07:37 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:mime-version:content-type:content-transfer-encoding; s=d7fd.63a51b79.k2212; bh=/rWB25ejxDFFcTkH5s6wZ98i55PQ511GpbG2b7U0Wio=; b=DsPNeeq3lZ+1weaRHCDrBooININw2YI3g52KcZMqyvyVh1ELwHLHhrelkC0OUhsiY2KRUphecB3YrLClUMYEE2/1SayTjcFst5v6U76f8mDRLurlR/S3YtdqDORHgf3xJ29TjATcklXQMqp6+Abk9Dv62BT5VWhLcxMTLa2U+dMq8k8Fq9+QArsFNksDqE9TB6vHM0RlFEoSxIlgHibCyP4r3Xr0a9II/hM4/VPLYaOkwwzTUAvSQJqwlkZNXINGb7nVfNHin3NdRw4soBS4CtpSh8OaAlO32vRPpST6yDU2ClrbSNe1HioWFwx6jtijyGfpJJTBf/LSrOC4miKhAA==
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:mime-version:content-type:content-transfer-encoding; s=d7fd.63a51b79.k2212; bh=/rWB25ejxDFFcTkH5s6wZ98i55PQ511GpbG2b7U0Wio=; b=n7Lm+p7tDDA2oX9wtq++V6xR9D4HhNhXF268sN7Xzv7aB4vLP8MGYSrD+YLh3PbDF/WMQ6HHQKcMS7e70DVk4pT4fJFUbajp23N5jLtisqoYjQovjZtT7MhdJzSipehrzj4k9cNOvPLUyO1UNRUY4Amt7Xwmu5mUOSfm4g0I6W/+JxhLCOBpYKOD+yRW7DMs8jnKLYSxHuiaG4cPwmPkNphrf+VBVUx5sv89FWhFUjCNoF00cKbuupwsxUNsYQgxaqjcaFvvqgvohrlD7y1RrYRALkBCALcRNKiQ6UYMsBCNtoxhLC6tAO1oBh3FI6Xi5KeXfqQ4OrNBQFVRqQzBhg==
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.3 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 23 Dec 2022 03:07:37 -0000
Received: by ary.qy (Postfix, from userid 501) id 7C0975898FB9; Thu, 22 Dec 2022 22:07:36 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 2C5335898F99; Thu, 22 Dec 2022 22:07:36 -0500 (EST)
Date: Thu, 22 Dec 2022 22:07:36 -0500
Message-ID: <d29af3e2-694a-bee9-fcda-89b42947f5e8@taugh.com>
From: John R Levine <johnl@taugh.com>
To: dbound@ietf.org
Cc: upavixie@amazon.com
X-X-Sender: johnl@ary.qy
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dbound/8LnPl4e6Dr5NRaJLp8cX4kUz_4k>
Subject: Re: [dbound] BoF request for IETF 115 (fwd)
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Dec 2022 03:07:44 -0000

-----Original Message-----
From: John R Levine <johnl@taugh.com>
Date: Thursday, December 22, 2022 at 14:51

     Vixie: ... ability to (as an example) let google.com set a cookie which would be sent to gmail.com. I agree that it's a hard problem. If someone wants to work on that problem in the IETF, I have yet to see evidence of that interest. The coalition of the willing that I hope we can isolate for this WG is narrowly just the thing Tim quoted out of the earlier charter:

         Tim: What appears to be needed is a mechanism to determine policy realm
         boundaries in the DNS.  That is, given two domain names, one needs to
         be able to answer whether the first and the second are either within
         the same policy realm or have policy realms that are related in some
         way.

     John: The hard bit is to do it in a way that people are willing to use.  If
     domain owners are willing to put a few records in the DNS and domain users
     are willing to do a DNS lookup or two each time they're checking a
     boundary, then my thing or Casey's should work.

> If by "it" you mean my example (google.com can set-cookie for gmail.com) ...

No.

> If by "it" you mean putting PSL-like stuff into the DNS per your (John's) 2016 draft, then I do not expect some people (like browser makers) to be "willing to use it" unless it gets aggregated.

So far we agree.

     ... If you want to be able to
     prefetch everything, they won't.

> So, I could disagree. Any decent passive DNS database can "prefetch everything" ...

Aw, come on

> even if there is no linkage in the DNS tying related records together. This is routinely done for SPF and DMARC now.

That is not anything like the SPF or DMARC used by the mail systems I know.  They do regular DNS lookups using
well defined DNS names found in the messages they're checking.

> However, none of that matters, so I won't disagree on that basis. Instead I will say that not everyone wants to prefetch everything, and the requirement to do so is one of the problems with the PSL today.

I really don't understand what point you're making here.  If you need to 
be able to prefetch stuff, you need to be able to prefetch all the records 
that apply to some DNS subtree and I am reasonably sure that is not 
feasible with the wildcard hacks that Casey and I have proposed.

R's,
John