Re: [spfbis] RFC6147 and RFC7208 interoperability issues

Andrew Sullivan <ajs@anvilwalrusden.com> Mon, 07 February 2022 15:22 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: spfbis@ietfa.amsl.com
Delivered-To: spfbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481FD3A0C80 for <spfbis@ietfa.amsl.com>; Mon, 7 Feb 2022 07:22:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=m85Sh8Qt; dkim=pass (1024-bit key) header.d=yitter.info header.b=RGTIibBy
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEe-lWQwUQLR for <spfbis@ietfa.amsl.com>; Mon, 7 Feb 2022 07:22:51 -0800 (PST)
Received: from mx5.yitter.info (mx5.yitter.info [159.203.31.152]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A8B43A0CAA for <spfbis@ietf.org>; Mon, 7 Feb 2022 07:22:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx5.yitter.info (Postfix) with ESMTP id B369CBD5C8 for <spfbis@ietf.org>; Mon, 7 Feb 2022 15:22:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1644247331; bh=dsAvKPE5lbPQ2LxT4YrMNSgG04SDULjFT4Vn/LkBHj8=; h=Date:From:To:Subject:References:In-Reply-To:From; b=m85Sh8Qt/IuGrO6qWZURQHMQjnLh5SknM9dgDNPo1Rm6gWAG/Mh26p7gdMrH20K2P JHXkJBfS8VrBgNPAyftmHKFHnjLBPTBPeUoFPIQYVZktCLGlaz24qoBq86e+VK3V/E k4hCTcUwCPQLx33W0SIfkOgxuLfJBFt+DlwYXCew=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx5.yitter.info ([127.0.0.1]) by localhost (mx5.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26ebCZ4GfYRI for <spfbis@ietf.org>; Mon, 7 Feb 2022 15:22:10 +0000 (UTC)
Date: Mon, 07 Feb 2022 10:22:07 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1644247330; bh=dsAvKPE5lbPQ2LxT4YrMNSgG04SDULjFT4Vn/LkBHj8=; h=Date:From:To:Subject:References:In-Reply-To:From; b=RGTIibBy+04aqSkntZLQDjFkI4Ryc935ya2ORlb+UilhgpoQhLK5Rbk+hk+mWuBzE cf5ISVzTtAtWK10BmlXZd1RgQ7GDBAbI3ShjDT/i2Q72Vvb48gRWe+SDA5CmjsxUet qqxC3l+C5dFjd/SZFTzaHZWqUlJa9ZkhMNkTgUa4=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: spfbis@ietf.org
Message-ID: <20220207152207.hw66pu5zmb6sqfbv@crankycanuck.ca>
Mail-Followup-To: spfbis@ietf.org
References: <45e423cc-4095-cca2-bf8c-aa15e977b19c@posteo.de> <8021771.rLJEViv2lv@localhost> <85cb8ec0-4316-c4db-4aed-2d49fda46f49@posteo.de> <45673006.FIhfuaby8d@localhost> <20220206224715.kzynnbwkt5a26wii@crankycanuck.ca> <b8e38c6a-aee9-8f86-350c-636c2f9d5efc@posteo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline
In-Reply-To: <b8e38c6a-aee9-8f86-350c-636c2f9d5efc@posteo.de>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spfbis/pzNDgZYP5xkNX8il1K0MFV9JNck>
Subject: Re: [spfbis] RFC6147 and RFC7208 interoperability issues
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SPFbis discussion list <spfbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spfbis>, <mailto:spfbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spfbis/>
List-Post: <mailto:spfbis@ietf.org>
List-Help: <mailto:spfbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spfbis>, <mailto:spfbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Feb 2022 15:23:02 -0000

On Mon, Feb 07, 2022 at 12:09:11AM +0000, Klaus Frank wrote:
>On 2022-02-06 23:47, Andrew Sullivan wrote:
>
>But it wouldn't be "every TXT record". If it doesn't start with 
>"v=spf1" it can be passed as is and does not require parsing. And even 
>then it's also a defined structure and not "arbitrary".

That is only true if you assume that the only case that counts is SPF.  But of course, that probably _isn't_ true.  Moreover, you still have to look at every TXT record and examine the RDATA.  That's not true for the other kinds of records: if you're a DNS64 you know that the A records are something you're going to have to process and you can have a high confidence that you'll probably need to process PTR records too.  What you are proposing is that the DNS64 needs to grab every TXT too, then look at the RDATA and _decide_ whether to process it, which is way more complicated.

>Actually the only limitation for that is the SPF record not being 
>updated by DNS64.

Sounds like a pretty severe limitation to me!

>What do you have in mind? What else would be there?

Anything could be in a TXT record, and once we start setting the precedent that the DNS64 should do rewrites of arbitrary text to capture certain relevant IPv4 addresses and make them IPv6 addresses with the appropriate prefix, there's no reason one has to stop at SPF.  The whole argument for using TXT records for SPF was that it was easy and you get to put what you want in a TXT.  But since "you get to put what you want", you have to live with the fact that there's not structured data in there from the point of view of the DNS.  Just because some other protocol wants to overload TXT and put structure into it does not mean that the DNS ought to be handling that RDATA programmatically.  TXT is arbitrary text data.

>As nothing else contains IP addresses but only dns names. I've 
>looked at the other record types. Did I miss something?

There's nothing that says that SPF is the only use of TXT here, so I don't see how you looking at your sample is proof of anything.  If DNS64 is supposed to start munging TXT records then it needs to do so in some predictable way.  If instead you want a neat hack of the sort John Levine suggested in order to generate the records on the fly, I certainly see the utility.  But I don't think standardizing that as part of DNS64 is a good idea.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com