Subject: Conclusions of Last Call for draft-ietf-spfbis-4408bis

From: Pete Resnick <[email-masked]>
Date: Sat, 7 Sep 2013 08:31:48 -0500

Below is the list of issues brought up during Last Call of 
draft-ietf-spfbis-4408bis. I have tried to collect together the common 
issues and tease out the ones that are slightly different. Below each 
issue, I've given what I take to be the answer to the issue (either the 
change that needs to be made, or the explanation of why no change is 
necessary). I've not put names to the objections or the answers, simply 
because multiple people gave different versions of the same objections 
or the same answers, and sorting that out seemed useless.

Issues:

1. Overloading of the TXT RR for this use is bad.
     - As far as I can tell, there is nobody that disagrees with this 
statement. However, it is also not in-and-of-itself an objection to the 
document: Nobody seems to have argued that this document should forbid 
use of the TXT RR completely in SPF. The only question is whether the 
document should provide a transition mechanism to the SPF RR or whether 
it is reasonable to go forward with this protocol using only the TXT RR. 
There is the "precedent"objection I will discuss in 2 below, but the 
specific technical objections seem mostly *not* to be about forbidding 
TXT RR use from the get-go. Some of the specific objections could be 
taken as arguments against the document going forward if it has no 
transition mechanism, but I believe all of those have either been 
addressed or can be addressed with clarifying language in the document:
     - The only complete solution to many of the problems that fall 
under this category is if *all* misuse of TXT RR went away. There has 
been no convincing argument put forward that this is plausible in the 
foreseeable future.

     1a. TXT RR can cause large RDATA.
         - In theory, that's certainly true. But I have not seen an 
argument that SPF is causing a major problem to date, nor that there is 
an expectation that it will in the future.
         - There were some suggested text clarifications for section 3.4 
to make it clear which size limitations relate to DNS response size, UDP 
payload size, or MTU size. They seem reasonable and were not objected 
to. I'll work with the editor and others to clarify that text.

     1b. Use of TXT RR can cause collisions with other applications.
         - Again, there is no indication that this has caused a problem 
for SPF (or others) to date, and SPF requires rejection of TXT RR data 
that does not conform to the spec, so I see no evidence of the existing 
harm, nor of a solid reason to believe there will be future harm. 
(Again, I'm leaving aside the "precedent" arguments until 2.)
         - There appears to be an effort underway to document (via an 
IANA registry) such uses to minimize the potential for these sorts of 
collision problems in the future.

     1c. Use of TXT RR for multiple purposes makes it impossible to do 
access control based on type of data (i.e., to allow delegation of the 
management for TXT RRs that are solely for SPF use).
         - Many organizations have been managing these records already; 
no reasoning was given that this fine-grained management is necessary.
         - Delegation is possible by pointing a TXT RR of (e.g.) 
example.com to _spf.example.com, delegating the latter.

     - All of the above was discussed extensively in the WG and taken 
into consideration. Given the charter limitations, a reasonable choice 
was made.

2. Use of the TXT RR sets a bad precedent for future use.
     - Several people responded that some additional text in 3.1 or 
elsewhere (either by way of some sort of applicability guidance or an 
overt IESG Statement) would address this issue. I think an IESG 
Statement is unnecessary since I have not heard significant objection to 
including some guidance, and I think something reasonable along these 
lines can be crafted. I'll work with the editor and others to get such 
text in the document.
     - The impediments that caused SPF to use TXT RR in the first place 
are mostly gone. New protocols are unlikely to face the same challenges.

3. Removing SPF RR support is a charter violation.
     - Because the original spec has a non-interoperable mechanism for 
use, this constituted an "error" in the spec that was to be corrected.

4. A new transition mechanism from TXT RR to SPF RR should be put into 
the spec.
     - This was extensively considered by the WG.
     - Backward compatibility would require support of TXT RR for the 
forseeable future anyway.
     - The proposed transition mechanisms have technical issues: 
Doubling request traffic (e.g., doing queries in parallel), introducing 
delays (e.g., querying SPF RR first and running into firewalls, etc).
     - This would be a new, unchartered requirement for the WG.
     - The widely held conclusion was that such a transition plan would 
not be undertaken by implementers. (See also 5.)

5. That there will be a lack of adoption of SPF RR was based on RFC 
6686, which does not support the conclusion.

     5a. There is some current use of the SPF RR; it will increase if we 
put in a new transition mechanism.
         - 6686 showed only minimal use, and reports of those in the 
industry shows the use dropping (i.e., the momentum is in the other 
direction).
         - Bigger sites are conservative and will not transition for 
fear of breaking current usage.
         - No solid case was made for why to believe that the transition 
would occur.

     5b. Use of SPF RR is on the increase now.
         - Claims that use is increasing are only anecdotal, and 
disagree with the experience of those in the industry.

     5c. Things may have changed since 6686. We should do more data 
collection.
         - There's no reason to believe that the small amounts of 
recently presented data are representative.
         - Nobody presented any basis to doubt the folks working in the 
industry.
         - There has been ample opportunity (and motivation) for folks 
outside of the WG to do more data collection; none has been presented.
         - It is an unreasonable burden to place on the WG at this point.

There were a few smaller issues:
     6. The term "SPF records" is confusing because it could refer to 
SPF RR.
         - Because the document no longer uses SPF RR, this shouldn't be 
a problem in practice.
     7. Clarifications are needed regarding the number of lookups to do 
in 4.6.4.
         - This will be reviewed prior to publication.
     8. There should be a limit on PTR lookups.
         - This was already considered by the WG and rejected.

The only looming issue large issue is the architectural one:

9. Using TXT RR for this purpose violates the architecture of the DNS.

I list this separately because this is not about the immediate technical 
implications (like objection 1) or a claim about precedence setting 
(like objection 2), but appears to be a claim that violating the 
architecture is in and of itself a reason to not put something on the 
standards track. The problem I have with this is, short of actual 
technical harm, I'm not sure how to judge this. Our processes judge 
whether standards should be adopted on the basis of interoperability, 
deployment, and solving a useful problem. We have many examples of 
protocols that violate architectural principles, but standardize them 
nonetheless. (We can all name our most hated.) We have found it more 
useful to document how to interoperate with protocols that may not be 
ideal but are widely deployed rather than reject them on principle. I 
can't see how to treat this protocol differently.

[There were a number of "straw men": There were responses to objections 
that never got brought up during Last Call, and a number of followups to 
responses to objections where the response was not one offered. Examples 
of these included:
     - A response to the objection that we haven't let the Experiment 
run long enough. (Nobody ever argued that during Last Call.)
     - A followup denying the contention that there is limited server 
support for SPF RRs. (Nobody ever said that the reason to use TXT RR now 
was because of limited server support.)
I have ignored these threads.]

So, my conclusions in summary are:

- The document needs to make a statement in the document clarifying why 
the SPF RR is no longer used in the spec and making it clear that no 
precedent should be created by this protocol's continued use of TXT RR.

- A few clarifications are required in the text (size limitations, 
perhaps number of lookup limitations).

- The remainder of the objections were fully considered and understood 
by the WG, and were addressed to a reasonable extent, and therefore that 
there is rough consensus to go forward with this document.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Douglas Otis <[email-masked]>
Date: Mon, 9 Sep 2013 02:24:28 -0700

On Sep 7, 2013, at 6:31 AM, Pete Resnick <[email-masked]> wrote:

> Below is the list of issues brought up during Last Call of draft-ietf-spfbis-4408bis. I have tried to collect together the common issues and tease out the ones that are slightly different. Below each issue, I've given what I take to be the answer to the issue (either the change that needs to be made, or the explanation of why no change is necessary). I've not put names to the objections or the answers, simply because multiple people gave different versions of the same objections or the same answers, and sorting that out seemed useless.
> 
> Issues:
> 
>    - As far as I can tell, there is nobody that disagrees with this statement. However, it is also not in-and-of-itself an objection to the document: Nobody seems to have argued that this document should forbid use of the TXT RR completely in SPF. The only question is whether the document should provide a transition mechanism to the SPF RR or whether it is reasonable to go forward with this protocol using only the TXT RR. There is the "precedent"objection I will discuss in 2 below, but the specific technical objections seem mostly *not* to be about forbidding TXT RR use from the get-go. Some of the specific objections could be taken as arguments against the document going forward if it has no transition mechanism, but I believe all of those have either been addressed or can be addressed with clarifying language in the document:
>    - The only complete solution to many of the problems that fall under this category is if *all* misuse of TXT RR went away. There has been no convincing argument put forward that this is plausible in the foreseeable future.
> 
>        - In theory, that's certainly true. But I have not seen an argument that SPF is causing a major problem to date, nor that there is an expectation that it will in the future.
>        - There were some suggested text clarifications for section 3.4 to make it clear which size limitations relate to DNS response size, UDP payload size, or MTU size. They seem reasonable and were not objected to. I'll work with the editor and others to clarify that text.
> 
>        - Again, there is no indication that this has caused a problem for SPF (or others) to date, and SPF requires rejection of TXT RR data that does not conform to the spec, so I see no evidence of the existing harm, nor of a solid reason to believe there will be future harm. (Again, I'm leaving aside the "precedent" arguments until 2.)
>        - There appears to be an effort underway to document (via an IANA registry) such uses to minimize the potential for these sorts of collision problems in the future.
> 
>    1c. Use of TXT RR for multiple purposes makes it impossible to do access control based on type of data (i.e., to allow delegation of the management for TXT RRs that are solely for SPF use).
>        - Many organizations have been managing these records already; no reasoning was given that this fine-grained management is necessary.
>        - Delegation is possible by pointing a TXT RR of (e.g.) example.com to _spf.example.com, delegating the latter.
> 
>    - All of the above was discussed extensively in the WG and taken into consideration. Given the charter limitations, a reasonable choice was made.
> 
>    - Several people responded that some additional text in 3.1 or elsewhere (either by way of some sort of applicability guidance or an overt IESG Statement) would address this issue. I think an IESG Statement is unnecessary since I have not heard significant objection to including some guidance, and I think something reasonable along these lines can be crafted. I'll work with the editor and others to get such text in the document.
>    - The impediments that caused SPF to use TXT RR in the first place are mostly gone. New protocols are unlikely to face the same challenges.
> 
>    - Because the original spec has a non-interoperable mechanism for use, this constituted an "error" in the spec that was to be corrected.
> 
> 4. A new transition mechanism from TXT RR to SPF RR should be put into the spec.
>    - Backward compatibility would require support of TXT RR for the forseeable future anyway.
>    - The proposed transition mechanisms have technical issues: Doubling request traffic (e.g., doing queries in parallel), introducing delays (e.g., querying SPF RR first and running into firewalls, etc).
>    - The widely held conclusion was that such a transition plan would not be undertaken by implementers. (See also 5.)
> 
> 5. That there will be a lack of adoption of SPF RR was based on RFC 6686, which does not support the conclusion.
> 
>    5a. There is some current use of the SPF RR; it will increase if we put in a new transition mechanism.
>        - 6686 showed only minimal use, and reports of those in the industry shows the use dropping (i.e., the momentum is in the other direction).
>        - Bigger sites are conservative and will not transition for fear of breaking current usage.
>        - No solid case was made for why to believe that the transition would occur.
> 
>        - Claims that use is increasing are only anecdotal, and disagree with the experience of those in the industry.
> 
>    5c. Things may have changed since 6686. We should do more data collection.
>        - There's no reason to believe that the small amounts of recently presented data are representative.
>        - Nobody presented any basis to doubt the folks working in the industry.
>        - There has been ample opportunity (and motivation) for folks outside of the WG to do more data collection; none has been presented.
>    6. The term "SPF records" is confusing because it could refer to SPF RR.
>        - Because the document no longer uses SPF RR, this shouldn't be a problem in practice.
>    7. Clarifications are needed regarding the number of lookups to do in 4.6.4.
> I list this separately because this is not about the immediate technical implications (like objection 1) or a claim about precedence setting (like objection 2), but appears to be a claim that violating the architecture is in and of itself a reason to not put something on the standards track. The problem I have with this is, short of actual technical harm, I'm not sure how to judge this. Our processes judge whether standards should be adopted on the basis of interoperability, deployment, and solving a useful problem. We have many examples of protocols that violate architectural principles, but standardize them nonetheless. (We can all name our most hated.) We have found it more useful to document how to interoperate with protocols that may not be ideal but are widely deployed rather than reject them on principle. I can't see how to treat this protocol differently.
> 
> [There were a number of "straw men": There were responses to objections that never got brought up during Last Call, and a number of followups to responses to objections where the response was not one offered. Examples of these included:
>    - A response to the objection that we haven't let the Experiment run long enough. (Nobody ever argued that during Last Call.)
>    - A followup denying the contention that there is limited server support for SPF RRs. (Nobody ever said that the reason to use TXT RR now was because of limited server support.)
> - The document needs to make a statement in the document clarifying why the SPF RR is no longer used in the spec and making it clear that no precedent should be created by this protocol's continued use of TXT RR.
> 
> - A few clarifications are required in the text (size limitations, perhaps number of lookup limitations).
> 
> - The remainder of the objections were fully considered and understood by the WG, and were addressed to a reasonable extent, and therefore that there is rough consensus to go forward with this document.

Dear Pete,

You missed two concerns raised in the last call:

10. As DNSSEC becomes more broadly used with email, SPF is likely to introduce problems neither foreseen nor properly considered by the WG.   "Not a problem for SPF" does not mean SPF will not impose problems for DNS which may include DNSSEC.  It should be obvious which protocol SPF or DNS should receive greater consideration  The SPF protocol also ignores the number of PTR Resource Records returned by a query made by a recipient on behalf of unknown senders against various third-party domains.  These domains can be constructed and modulated by message elements via macro expansion greatly increasing the reflected amplification this protocol enables.  The same issue could occur with a series of otherwise innocent TXT resource records that the SPF protocol also permits. This "feature" could prove highly problematic and extremely difficult if not impossible to defend against.  Even limits on NX domains can be easily sidestepped by malefactors leveraging the practice of using synthetic domains to track users without the use of cookies.

11.  The continued specification of SPF macros inhibits interchange.  Because it is common for SPF records not to produce a pass, this issue is not likely to have been given adequate attention.  When SPF macros are not implemented by receivers for any number of very valid reasons, such as ensuring effective caching of DNS, their required use can and will lead to interchange issues.  SPF may impose complex macro handling over multiple DNS responses determined by a sequence of queries that can not be directly handled by DNS itself.  Even the operation of SPF macros represents security concerns threatening the integrity of the associated SMTP and DNS servers.   Since the publication of SPF macros is well below the level used to justify removal of the SPF RR record type, the same consideration should have been given SPF macros.  Use of SPF macros also interferes with forensic efforts at handling interchange problems.  As such, it is not surprising to find extremely few domains publish SPF records using macros and large providers not processing SPF macros.

The lack of consideration given DNS by the SPF protocol offers overwhelming justification not to consider this protocol suitable for endorsing as a standard.  Going from experimental to informational should not represent any hardship, but would serve as a warning protocols should pay attention to their impact on underlying infrastructure.  There are limits on making it easy to send messages since the Internet is not suffering from a message scarcity.

Regards,
Douglas Otis

---

From: Pete Resnick <[email-masked]>
Date: Mon, 9 Sep 2013 09:27:51 -0500

On 9/9/13 4:24 AM, Douglas Otis wrote:
> On Sep 7, 2013, at 6:31 AM, Pete Resnick<[email-masked]>  wrote:
>
>    
>> Below is the list of issues brought up during Last Call of draft-ietf-spfbis-4408bis.
>> [...]
> 10. As DNSSEC becomes more broadly used with email, SPF is likely to introduce problems neither foreseen nor properly considered by the WG.[...]
>
> 11.  The continued specification of SPF macros inhibits interchange.[...]
>    

I took your issue 10 to be covered under 8, and your issue 11 to be 
covered under 7. If this is not the case, you will need to explain more 
clearly. I will contact you offline with regard to why your messages 
were not clear and what you can do to help if you still believe these 
issues are not covered. Please do not write back to the IETF or SPFBIS 
list on these topics until you read that email.

pr

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 10 Sep 2013 13:04:05 +0200

>        - It is an unreasonable burden to place on the WG at this point.

FWIW, we at Netnod that run i-root have been looking at the queries we get to the root name server of ours.

We have been looking at the data collected during the DITL collection which is 30-48 hour collections of data that happens once a year.

What we did look at was first of all every query for an MX resource record. Then we look at +/-1 second from the timestamp of that MX query for TXT and/or SPF record for the same owner. We draw the conclusion that if there is a query for an MX record, and then either TXT or SPF (or both) within the approximately same timespan, then they are related queries.

We did look at 2011, 2012 and 2013.

The result is the following:

Date       MX        TXT      SPF     %TXT/MX %SPF/MX  %SPF/TXT

2011-06-07 148528658  7484035  784386  5.0%    0.5%    10.5%
2012-04-17  90779132  4839143  536467  5.3%    0.6%    11.1%
2013-05-28 114353838 11554391 1595777 10.1%    1.4%    13.8%

What we see is that the percentage of TXT queries per MX query has gone up from 5% to 10.1% and SPF queries went up from 0.5% to 1.4%. The percentage of SPF queries compared to TXT went up from 10.5% to 13.8%.

    Regards, Patrik Fältström

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Sep 2013 04:39:16 -0700

Hi Patrik,

On Tue, Sep 10, 2013 at 4:04 AM, Patrik Fältström <[email-masked]> wrote:

> What we did look at was first of all every query for an MX resource
> record. Then we look at +/-1 second from the timestamp of that MX query for
> TXT and/or SPF record for the same owner. We draw the conclusion that if
> there is a query for an MX record, and then either TXT or SPF (or both)
> within the approximately same timespan, then they are related queries.
>
>
I'm not sure that's a valid conclusion.  Since MX is needed only for a
sending system, a receiving system doing an SPF check of either type has no
reason to query for MX.  The exception to this might be a heuristic check
to see if the domain in the MAIL FROM has MX or A published such that a
reply appears to be possible, but I wouldn't expect a strong correlation in
your data.

-MSK

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 10 Sep 2013 14:32:21 +0200

On 10 sep 2013, at 13:39, "Murray S. Kucherawy" <[email-masked]> wrote:

> I'm not sure that's a valid conclusion.  Since MX is needed only for a sending system, a receiving system doing an SPF check of either type has no reason to query for MX.  The exception to this might be a heuristic check to see if the domain in the MAIL FROM has MX or A published such that a reply appears to be possible, but I wouldn't expect a strong correlation in your data.

True.

View my explanation just like it was, how we did our calculations. Conclusions can anyone draw from the data.

The problem is that if one look at just queries to a root server like this, there is lots of what I would call "junk". When looking at TLDs, we saw about 162 million different TLDs each 24h in the QNAME. We saw this time also for example queries for SPF and other RR Types where the QNAME was an IPv4 address (for example "10.2.3.4.").

So, we found _some_ algorithm was needed instead of "just" counting queries, and we did count the way I just explained.

   Patrik

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 12 Sep 2013 17:35:33 +0200

On 09/10/2013 01:39 PM, Murray S. Kucherawy wrote:
> Hi Patrik,
>
> On Tue, Sep 10, 2013 at 4:04 AM, Patrik Fältström <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     What we did look at was first of all every query for an MX
>     resource record. Then we look at +/-1 second from the timestamp of
>     that MX query for TXT and/or SPF record for the same owner. We
>     draw the conclusion that if there is a query for an MX record, and
>     then either TXT or SPF (or both) within the approximately same
>     timespan, then they are related queries.
>
>
> sending system, a receiving system doing an SPF check of either type 
> has no reason to query for MX.  The exception to this might be a 
> heuristic check to see if the domain in the MAIL FROM has MX or A 
> published such that a reply appears to be possible, but I wouldn't 
> expect a strong correlation in your data.

Well, if the TXT/SPF query precedes the MX query (so the case '-1 
second' of the '+/-1 second' described by Patrik) it might indicate an 
SPF record which includes an mx mechanism. In that case the queries are 
related.

/rolf