Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

Olafur Gudmundsson <ogud@ogud.com> Thu, 22 August 2013 14:39 UTC

Return-Path: <ogud@ogud.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7B511E81CE for <ietf@ietfa.amsl.com>; Thu, 22 Aug 2013 07:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 906u6RXbnLWc for <ietf@ietfa.amsl.com>; Thu, 22 Aug 2013 07:39:53 -0700 (PDT)
Received: from smtp94.ord1c.emailsrvr.com (smtp94.ord1c.emailsrvr.com [108.166.43.94]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBEB11E81D7 for <ietf@ietf.org>; Thu, 22 Aug 2013 07:39:48 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 42BD11401CD; Thu, 22 Aug 2013 10:39:47 -0400 (EDT)
X-Virus-Scanned: OK
Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id DB4721400DA; Thu, 22 Aug 2013 10:39:40 -0400 (EDT)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Subject: Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
From: Olafur Gudmundsson <ogud@ogud.com>
In-Reply-To: <5215CD8D.3080302@sidn.nl>
Date: Thu, 22 Aug 2013 10:39:55 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <FAF76B13-BAFF-44B8-9D71-64C9AF1FAED1@ogud.com>
References: <20130819131916.22579.36328.idtracker@ietfa.amsl.com> <20130819150521.GB21088@besserwisser.org> <20130819200802.GI19481@mx1.yitter.info> <521284A4.4050901@qti.qualcomm.com> <5212862F.3080507@qti.qualcomm.com> <5212873B.1010007@dcrocker.net> <CAL0qLwaPJSEXbEadyxcExDSbHg7RMDZ-YzfLztkHkvNF6WOOAQ@mail.gmail.com> <20130819214139.GB19946@mx1.yitter.info> <7D0CBAC9-1E0C-4F07-997E-E98942802884@ogud.com> <5215CD8D.3080302@sidn.nl>
To: Jelte Jansen <jelte.jansen@sidn.nl>
X-Mailer: Apple Mail (2.1508)
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Aug 2013 14:39:58 -0000

On Aug 22, 2013, at 4:36 AM, Jelte Jansen <jelte.jansen@sidn.nl> wrote:

> On 08/21/2013 08:44 PM, Olafur Gudmundsson wrote:
>> 
>> Most of the recent arguments against SPF type have come down to the following (as far as I can tell): 
>> 	a) I can not add SPF RRtype  via my provisioning system into my DNS servers
>> 	b) My firewall doesl not let SPF Records through 
>> 	c) My DNS library does not return SPF records through or does not understand it, thus the application can not receive it.
>> 	d) Looking up SPF is a waste of time as they do not get through, thus we only look up TXT
>> 
>> So what I have taken from this is that the DNS infrastructure is agnostic to RRtype=99 but the 
>> edges have problems. 
>> As to the arguments 7 years is not long enough to reach conclusion and force the changes through the
>> infrastructure and to the edges. The "need" for SPF has been blunted by the "DUAL SPF/TXT" strategy and 
>> thus we are basically in the place where the path of lowest-resistence has taken us. 
>> 
>> What I want the IESG to add a note to the document is that says something like the following: 
>> "The retirement of SPF from specification is not to be taken that new RRtypes can not be used by applications, 
>> the retirement is consequence of the dual "quick-deploy" strategy. The IETF will continue to advocate application 
>> specific RRtypes applications/firewalls/libraries SHOULD support that approach."
>> 
> 
> So what makes you think the above 4 points will not be a problem for the
> next protocol that comes along and needs (apex) RR data? And the one
> after that?
> 

There are two reasons, mail is a legacy application with lots of old cruft around it. 
New protocols on the other hand can start with clean slate, and the use of the protocol is
optional unlike email. 
With a new protocol you can tell someone "you can not use Vendor X as it does not support Y" 
and they will put up a system that works, for email there is installed base and enterprise policies to use
Vendor X then SPF RR can not be used. 


> While I appreciate the argument 'this works now, and it is used'
> (running code, and all that), I am very worried that we'll end up with
> what is essentially a free-form blob containing data for several
> protocols at the zone apexes instead of a structured DNS.
> 
> So if this approach is taken, I suggest the wording be much stronger, in
> the hope this chicken/egg problem (with 5 levels of eggs. or chickens)
> will be somewhat mitigated at some point. Preferably with some
> higher-level strategy to support that goal.
> 
> Jelte


I agree 

	Olafur