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

[Scott Kitterman <[e-mail]>]

On Wednesday, August 21, 2013 22:05:37 Måns Nilsson wrote:
> 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 Date: Wed, Aug 21, 2013 at 08:51:31AM -0400 Quoting
> Scott Kitterman (scott@kitterma
> > > Apparently.
> > 
> > Translated:
> > 
> > RFC 4408 was in error because it didn't abandon it's installed base.  I
> > gather this is an error you propose to rectify.
> 
> Well, almost. 4408 sort of blunders about like the elephant in a china
> shop wrt. query method and depreciation.
> 	(As I have been sternly lectured off-list that I do not understand
> 	the SPF payload and therefore am in no position to discuss the
> 	DNS usage, I'd like to assert that the payload syntax matters
> 	marginally, if at all, for the discussion about which DNS records
> 	to use and how.)
> 
> Specifically, 4408 section 3.1.1 should be updated to:
> 
> * A domain SHOULD use SPF and MAY use TXT. The latter is only suitable if
>   SPF is impossible to publish.

This is the point where you abandon the installed base.  Particularly given 
the charter, I think this is an inappropriate approach.

> * If it is possible to use SPF as a result of having modern provisioning
>   systems, SPF MUST be used and consequently, TXT SHOULD NOT be used. (I'd
>   like MUST here, but I'm not certain it flies.) If SPF and TXT coexist,
>   they MUST agree wrt content.

draft-schlitt-spf-classic-02, which became RFC 4408, had this MUST when it was 
approved by the IESG.  Since at the time of IESG approval, the RRTYPE for SPF 
hadn't been allocated yet, they - by necessity - approved a paper design.  
Fortunately the RRTYPE was allocated sufficiently before AUTH48 that we were 
able to experiment with running code and determine that this MUST was 
operationally extremely problematic, so it was removed as part of the AUTH 48 
review.

> * The notion of a sunset date as introduced by Mark Andrews, is interesting.
> 
> Section 4.1.1 in 4408 should be altered to direct implementations to
> FIRST look for SPF and then _perhaps_ (I'm open for discussion) ask for
> TXT, thus creating an incentive to improve performance by serving SPF
> rather than TXT. After a possible sunset, TXT MUST NOT be queried for.

The performance implications are more generally constraining on the receive 
side in high volume mail systems.  Adding a second set of sequential DNS 
queries is a non-starter.  It's much more efficient to go straight to TXT where 
99%+ of the time I'll get a correct answer [there are a minute number of 
domains that publish SPF only, but virtually all type SPF publishers also 
publish TXT].  I think you're putting the performance implications on the 
wrong end of the conversation.

Let's say we get to this magical sunset date, whose behavior do you think it 
will influence if they are finding the TXT queries still useful (if they aren't, 
they won't do it and you don't need the sunset date)?

> The preference for SPF vs TXT that is present in 4408 is to be kept
> unaltered.

Here's a related conundrum that I haven't seen operationally (due to limited 
RRTYPE SPF deployment, but I have seen similarly for real in the fallback to 
v=spf1 records in the SenderID RFCs).  It's an example of why you can't ignore 
the payload.  One of the widely used features of SPF is the "include" 
mechanism.  It allows a sender to authorize the hosts of a third party to send 
mail on its behalf.  It also allows SPF records to be chained together to 
publish more information while staying in the standard UDP packet limit.  
Here's an example for the latter from Microsoft's current SPF record:

v=spf1 include:_spf-a.microsoft.com include:_spf-b.microsoft.com ...

A key aspect of "include" is that the targe domain MUST have an SPF record.  
If it doesn't, it's a "permerror" - permanent error.  Let's imagine for a 
moment that example.com has this record published in RRTYPE SPF:

v=spf1 a include:example.org -all

Then let's consider example.org and imagine that, like most SPF participants 
today, they have their record published in RRTYPE TXT only:

v=spf1 a -all

A receiver, as you suggest, checks RRTYPE SPF when they get mail from 
example.com.  Their SPF verifier processes the "include" mechanism and 
determines it needs to do a lookup for example.org's SPF record.  They query 
RRTYPE SPF and they get ANSWER: 0 in return.  Should this verifier:

1.  Return a "permerror" because the target domain of an "include" doesn't 
exist?

2.  Press on and query RRTYPE TXT, get an SPF record back, and finish the 
transaction without error?

RFC 4408 doesn't help us here because it's treatment of the TXT/SPF 
coexistence model is not complete.  

I have said before that I don't think an effective transition model exists nor 
can it be created.  I think Olafur Gudmundsson's suggestion that 4408bis 
document this use of TXT as an architectural wart and move on is a good one.

I think this is a symptom of the larger problem that most initial development 
work in this space is done outside the IETF and only brought to the IETF when 
it's reasonably well baked.  This is true for SPF, DK -> DKIM, and DMARC, all 
of which use TXT.  I would encourage those who want this to be different in the 
future to make contact with the people involved in DMARC (I wasn't) and ask 
them what it would have taken to get them to consider a new RRTYPE in their 
design.  Whatever those barriers are, that's what needs to be addressed.  
Focusing to trying to "fix" SPF shouldn't be the priority.  It is what it is.

Scott K