Re: [spfbis] RFC6147 and RFC7208 interoperability issues

Andrew Sullivan <ajs@anvilwalrusden.com> Sun, 06 February 2022 22:47 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 F36383A0E93 for <spfbis@ietfa.amsl.com>; Sun, 6 Feb 2022 14:47:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, 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=Mb8rUsZV; dkim=pass (1024-bit key) header.d=yitter.info header.b=a59BGQ8j
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 3kgeGO3YIUCn for <spfbis@ietfa.amsl.com>; Sun, 6 Feb 2022 14:47:22 -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 215663A0E8C for <spfbis@ietf.org>; Sun, 6 Feb 2022 14:47:21 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx5.yitter.info (Postfix) with ESMTP id 85D83BD5C8 for <spfbis@ietf.org>; Sun, 6 Feb 2022 22:47:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1644187639; bh=RMr/6b4GKxU4nHermOQhQ7BNoZB76rqbev5xL7WZT1s=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Mb8rUsZV/5RCFR5TlnsJNS8FnJMt0S0LFLemxapNxgfw8WCJc6B72gIeqnyaHVyhC cvC7WxWGxX/rOZtc6yudMsmUIu4i7CY5caAElQNGBYWTkAJbvvYkS7r4vQ9jXrzoC3 Xc48uqhB1981/m5yunxuOOmtgSFO7/YXqAKC0Fb0=
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 Zw3V4KK-EO67 for <spfbis@ietf.org>; Sun, 6 Feb 2022 22:47:17 +0000 (UTC)
Date: Sun, 06 Feb 2022 17:47:15 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1644187637; bh=RMr/6b4GKxU4nHermOQhQ7BNoZB76rqbev5xL7WZT1s=; h=Date:From:To:Subject:References:In-Reply-To:From; b=a59BGQ8jYN404nQFnJXv0W679e9d3+zwAKhSmEXJMvyGNPoejv/GGB/06bttGC6kY 9rfCiphDYuJ2eL4Lwx/U0TF2P94KsRH7+84ivHVTPZtDTV2qhZoXl15XwxoKyoL2qM E550Hf/Mr5CErMRsMSw7hNQ18YYFeOU9x0GFYdH0=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: spfbis@ietf.org
Message-ID: <20220206224715.kzynnbwkt5a26wii@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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline
In-Reply-To: <45673006.FIhfuaby8d@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spfbis/bv7b44T3JjmHOtmo5HGEuM9WzX0>
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: Sun, 06 Feb 2022 22:47:28 -0000

Hi,

I'm one of the primary offenders behind DNS64.  I work for the Internet Society but I am not speaking for them (or anyone eles) right now.

On Sun, Feb 06, 2022 at 02:57:08PM -0500, Scott Kitterman wrote:

>I think your original suggestion that an SPF record be modified by the DNS64
>server to add ip6: mechanisms with <prefix> + <address> is a reasonable path
>forward, but I think it's really an RFC 6147 discussion, not so much RFC 7208.

The problem with this is that it's importing the DNS64 intimate knowledge of this protocol for TXT records, which means in effect that DNS64 needs to start parsing arbitrary data in TXT records.  (There is a reason DNS weenies always got upset about ignoring the strong typing in DNS, and this is an example of it.)

DNS64, to be honest, was always sort of a hack that was intended to make transition to v6 easier.  It really basically depended on the strong data typing of A, AAAA, and PTR records in order to give it clear places to insert itself.  "Look at every TXT record," doesn't really support that plan.  I never thought we were designing it for long life or high degrees of robustness, and I think it is likely to be extremely difficult to operate a modern mail server on v6-only infrastructure and be able to talk to v4-only mail servers.  In any case, I guess it would be _possible_ to teach a DNS64 server to parse and edit TXT records on the fly, but the idea that this is going to be limited to SPF is, I suspect, a false hope.  For that reason, my reaction is that it wouldn't be a great idea to do.  I nevertheless sympathize with the desire, even though I am made nervous about the implications.

>It is not, however, without risks.  RFC 7208 Section 3.4 gives advice on SPF
>record size.  Your proposed approach would increase the record size, which, in
>theory, could be problematic.  It might be that anything running on an IPv6
>only network is modern enough that this isn't actually a problem.  I don't
>know.

I'd be especially worried about RRset size, because a lot of stuff in contemporary operations is jammed into TXT records (all those application keys, for instance).  I can imagine cases where the change could move the response size across the response size boundary, forcing truncation and TCP fallback.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com