Re: Macro Expansion (was: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)
Dear SM, See comments inline. On Sep 16, 2013, at 9:00 AM, S Moonesamy sm+i...@elandsys.com wrote: Hi Doug, At 21:55 11-09-2013, Douglas Otis wrote: Add to: 11.5.3. Macro Expansion ,--- It is not within SPF's purview whether IPv6 or DNSSEC is being used. IPv6 (RFC2460) increased the minimum MTU size to 1280 octets. DNSSEC is deployed with EDNS0 (RFC6891) to avoid TCP fallback. EDNS0 suggests an MTU increase between 1280 and 1410 octets offers a reasonable result starting from a request of 4096 octets. A 1410 MTU offers a 2.4 times payload increase over the assumed MTU of 576 octets and is widely supported by Customer Premise Equipment. With increased MTUs being used with DNS over UDP, network amplification concerns increase accordingly. SPF macros can utilize SPF parameters derived from email messages that can modulate the names being queried in several ways without publishing additional DNS resources. The SPF macro feature permits malefactors a means to covertly orchestrate directed DDoS attacks from an array of compromised systems while expending little of their own resources. Since SPF does not make use of a dedicated resource record type or naming convention, this leaves few solutions available to DNS operations in offering a means to mitigate possible abuse. This type of abuse becomes rather pernicious when used in conjunction with synthetic domains now popular for tracking users without using web cookies. However, email providers can mitigate this type of abuse by ignoring SPF records containing macros. Very few domains make use of macros, and ignoring these records result in neutral handling. Some large providers have admitted they make use of this strategy without experiencing any notable problem. AOL began their support of SPF by saying they would use SPF to construct whitelists prior to receipt of email. Clearly, such whitelisting practices tends to preclude benefits derived from macro use. '--- As background information I read draft-otis-spfbis-macros-nixed-01. I read the messages where EDNS0 was mentioned [1]. I read the messages on the thread starting with msg-id: 9884b9cd-0ed3-4d89-a100-58d05ea4b...@gmail.com. I have followed the discussions about macros ever since the SPFBIS WG was chartered. The above suggestion is to add text in the Security Considerations section of the draft. The problem being pointed out is, in simple terms, DNS amplification. The first (quoted) paragraph argues that there can be an acute problem because of EDNS0 as specified in the Internet Standard. The second paragraph starts with SPF macros can utilize SPF parameters derived from email messages. I do not understand that. From what I understand the rest of the second (quoted) paragraph argues that the SPF macro feature permits evildoers to use it as an attack vector. Since this was not understood, I'll attempt to clarify. An effort to keep these conversations fairly concise seems to lead to a level of confusion with those not familiar with DNS. DNS UDP traffic lacks congestion avoidance when used to covertly direct attacks. Residential systems represent a large component of compromised systems involved with email although data centers measured by overall traffic is increasing. Network amplification is measured by gains beyond exchanges initiating a higher volume of exchanges. DNS caching tends to reduce subsequent exchanges. SPFbis macros inhibit normal caching protections by imposing mechanisms not directly supported by DNS and having targets constructed from email message components. SPFbis mechanism names can be misleading since they are given a related manipulated DNS resource name. One SPFbis mechanism can represent more than 100 subsequent DNS transactions where normally resolving the resource would represent a single transaction. Publishing new targets within DNS resources to circumvent caching would normally be expensive and unlikely to provide remarkable gain. SPFbis macros change this equation significantly. SPFbis offers macros to translate code points, restructure host labels, build labels from the client IP address, make use of the local-part of the message return path or some label in the EHLO hostname, etc. In other words, SPFbis macros permit malefactors a means to modulate the target of their queries while still leveraging their own cached DNS records. This means a malefactors' DNS resources can be highly leveraged as a result of recipient SPFbis macro processing. Secondly, SPFbis also ignores the overall size of the resources being queried in many cases. The most egregious is perhaps that of the unlimited PTR RRsets which then results in a series of address RRset resolutions cascading down the hostname labels that happens for a maximum of 10 PTRs that might be offered on either a random or round robin basis. It would be extremely difficult to
Macro Expansion (was: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)
Hi Doug,
At 21:55 11-09-2013, Douglas Otis wrote:
Add to:
11.5.3. Macro Expansion
,---
It is not within SPF's purview whether IPv6 or DNSSEC is being
used. IPv6 (RFC2460) increased the minimum MTU size to 1280
octets. DNSSEC is deployed with EDNS0 (RFC6891) to avoid TCP
fallback. EDNS0 suggests an MTU increase between 1280 and 1410
octets offers a reasonable result starting from a request of 4096
octets. A 1410 MTU offers a 2.4 times payload increase over the
assumed MTU of 576 octets and is widely supported by Customer
Premise Equipment. With increased MTUs being used with DNS over
UDP, network amplification concerns increase accordingly.
SPF macros can utilize SPF parameters derived from email messages
that can modulate the names being queried in several ways without
publishing additional DNS resources. The SPF macro feature permits
malefactors a means to covertly orchestrate directed DDoS attacks
from an array of compromised systems while expending little of their
own resources.
Since SPF does not make use of a dedicated resource record type or
naming convention, this leaves few solutions available to DNS
operations in offering a means to mitigate possible abuse. This
type of abuse becomes rather pernicious when used in conjunction
with synthetic domains now popular for tracking users without using
web cookies.
However, email providers can mitigate this type of abuse by ignoring
SPF records containing macros. Very few domains make use of macros,
and ignoring these records result in neutral handling. Some large
providers have admitted they make use of this strategy without
experiencing any notable problem. AOL began their support of SPF by
saying they would use SPF to construct whitelists prior to receipt
of email. Clearly, such whitelisting practices tends to preclude
benefits derived from macro use.
'---
As background information I read
draft-otis-spfbis-macros-nixed-01. I read the messages where EDNS0
was mentioned [1]. I read the messages on the thread starting with
msg-id: 9884b9cd-0ed3-4d89-a100-58d05ea4b...@gmail.com. I have
followed the discussions about macros ever since the SPFBIS WG was chartered.
The above suggestion is to add text in the Security Considerations
section of the draft. The problem being pointed out is, in simple
terms, DNS amplification. The first (quoted) paragraph argues that
there can be an acute problem because of EDNS0 as specified in the
Internet Standard.
The second paragraph starts with SPF macros can utilize SPF
parameters derived from email messages. I do not understand
that. From what I understand the rest of the second (quoted)
paragraph argues that the SPF macro feature permits evildoers to use
it as an attack vector.
The argument in the third (quoted) paragraph is that it is not
possible to mitigate possible (DNS) abuse due to the SPF as it does
not have a dedicated resource record type.
The fourth (quoted) paragraph argues that macros should be
ignored. That paragraph also mentions that some large providers
admitted to using that strategy. I am not aware of any public
reports about that.
I read draft-otis-spfbis-macros-nixed-01 again to try and understand
the problem. It seems to be the:
'{%l}._spf.{%d} or exists:{%i}_spf.{%d} can be used in specialized
DNS servers able to understand encrypted local-parts'
which is discussed in Appendix E of draft-ietf-spfbis-4408bis-20.
Arthur Thisell commented about the specialized DNS server. He
mentioned that at the time that text was written two people came
forward to say that they were doing that. During the SPFBIS
discussions nobody stated that he or she has implemented or is using
a specialized DNS server.
I'll ask the person editing draft-ietf-spfbis-4408bis or the SPFBIS
WG to provide some publicly verifiable cases where these examples are used.
I assume that the SPFBIS WG and the Responsible Area Director have
understood the mathematics relating to EDNS0 and DNS
amplification. Anyone who has not understood that part is welcome to
raise the issue on the SPFBIS mailing list.
The discussion about the dedicated resource record type has led to
agreement. I'll describe the agreement as something people can live
with. In my opinion it is better not to start another discussion about that.
I hope that what I wrote above clearly explains what I have
understood and what I have not understood.
Regards,
S. Moonesamy (as document shepherd)
1. message-id of messages:
4ef10b1f.5050...@mail-abuse.org
4f0e7154.4080...@isdg.net
29fba028-5881-4a04-95d4-227582a38...@email.android.com
pine.gso.4.62.1201121350550.3...@spaz.oit.wmich.edu
20120425152326.ge60...@mail.yitter.info
1545953.Y9VaoKsXxF@scott-latitude-e6320
20120704015156.gb12...@crankycanuck.ca
1977893.MDoye0cYQa@scott-latitude-e6320
20130122231357.ga6...@mx1.yitter.info
3896517.k8tBVMT4Fi@scott-latitude-e6320
cd246081.bbd2f%fmar...@linkedin.com
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Hi Doug, At 21:55 11-09-2013, Douglas Otis wrote: Recommended text is as follows: Thanks for suggesting text. I'll take this up with the SPFBIS WG after the (IESG) DISCUSSes have been addressed. Here are some quick comments. Section 4.6.4 was reviewed again in response to the DISCUSS from Barry Leiba. I will take the new changes into consideration when making a suggestion to the SPFBIS WG about that part of the draft. I'll also review the text proposed in the message at http://www.ietf.org/mail-archive/web/ietf/current/msg82402.html before making that suggestion. There were also some text clarifications to Section 5 in response to comments from Barry Leiba. I'll see whether the addition of the one sentence which you propose fits in. Some text was proposed to address the DNS message issue in Section 3.4 ( http://www.ietf.org/mail-archive/web/spfbis/current/msg04104.html ). I'll use your suggestion and some of the other suggestions to get this issue resolved. It is my understanding that you consider the macro issue (Section 11.5.3 in the text which was proposed) as a major one. The argument in your message starts with IPv6 or DNSSEC not being in the purview of draft-ietf-spfbis-4408bis. It is followed by EDNS0 is used with DNSSEC, and there is a discussion about MTU after that. The next paragraph starts with the argument that the SPF macro feature can be used for attacks. The proposed text then argues that SPF records containing macros are to be ignored to mitigate such an attack. At the moment I do not know what I will suggest. I welcome any new input from anyone who has not commented about the macro issue. I suggest using the spf...@ietf.org mailing list only for any follow-up about the above instead of copying the message to the ietf@ietf.org. Regards, S. Moonesamy (as document shepherd)
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Recommended text is as follows: 4.6.4. DNS Lookup Limits Was: ,-- SPF implementations MUST limit the total number of mechanisms and modifiers (terms) that cause any DNS query to 10 during SPF evaluation. Specifically, the include, a, mx, ptr, and exists mechanisms as well as the redirect modifier count against this collective limit. The all, ip4, and ip6 mechanisms do not count against this limit. If this number is exceeded during a check, a permerror MUST be returned. The exp modifier does not count against this limit because the DNS lookup to fetch the explanation string occurs after the SPF record evaluation has been completed. '-- Change to: ,--- SPF does not directly limit the number of DNS lookup transactions. Instead, the number of mechanisms and the modifier term redirect MUST be limited to no more than 10 instances within the evaluation process. The mechanisms ip4, ip6, and all and the exp modifier are excluded from being counted in this instance limitation. If this instance limit is exceeded during the evaluation process, a permerror MUST be returned. '--- 5. Mechanism Definitions Was: ,-- Several mechanisms rely on information fetched from the DNS. For these DNS queries, except where noted, if the DNS server returns an error (RCODE other than 0 or 3) or the query times out, the mechanism stops and the topmost check_host() returns temperror. If the server returns domain does not exist (RCODE 3), then evaluation of the mechanism continues as if the server returned no error (RCODE 0) and zero answer records. ‘--- Add: ,--- See the recommended limits on void lookups defined in Section 4.6.4. DNS Lookup Limits. ‘--- 3.4. Record Size Was: ,--- Note that when computing the sizes for replies to queries of the TXT format, one has to take into account any other TXT records published at the domain name. Similarly, the sizes for replies to all queries related to SPF have to be evaluated to fit in a single 512 octet UDP packet. ‘--- Change to: ,--- Note that when computing the sizes for replies to queries of the TXT format, one has to take into account any other TXT records published at the domain name. Similarly, the sizes for replies to all queries related to SPF have to be evaluated to fit in a single 512 octet DNS Message. ‘--- Add to: 11.5.3. Macro Expansion ,--- It is not within SPF’s purview whether IPv6 or DNSSEC is being used. IPv6 (RFC2460) increased the minimum MTU size to 1280 octets. DNSSEC is deployed with EDNS0 (RFC6891) to avoid TCP fallback. EDNS0 suggests an MTU increase between 1280 and 1410 octets offers a reasonable result starting from a request of 4096 octets. A 1410 MTU offers a 2.4 times payload increase over the assumed MTU of 576 octets and is widely supported by Customer Premise Equipment. With increased MTUs being used with DNS over UDP, network amplification concerns increase accordingly. SPF macros can utilize SPF parameters derived from email messages that can modulate the names being queried in several ways without publishing additional DNS resources. The SPF macro feature permits malefactors a means to covertly orchestrate directed DDoS attacks from an array of compromised systems while expending little of their own resources. Since SPF does not make use of a dedicated resource record type or naming convention, this leaves few solutions available to DNS operations in offering a means to mitigate possible abuse. This type of abuse becomes rather pernicious when used in conjunction with synthetic domains now popular for tracking users without using web cookies. However, email providers can mitigate this type of abuse by ignoring SPF records containing macros. Very few domains make use of macros, and ignoring these records result in neutral handling. Some large providers have admitted they make use of this strategy without experiencing any notable problem. AOL began their support of SPF by saying they would use SPF to construct whitelists prior to receipt of email. Clearly, such whitelisting practices tends to preclude benefits derived from macro use. ‘--- Regards, Douglas Otis
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
On Sep 2, 2013, at 5:54 AM, Phillip Hallam-Baker hal...@gmail.com wrote: On Thu, Aug 29, 2013 at 12:30 PM, Dan Schlitt schl...@theworld.com wrote: As the manager of a modestly large network I found the TXT record as a useful tool in management of the network. Such a use was even suggested by other system managers. That was a time when the Internet was a friendlier place. Today I might do things differently and not make some of the TXT records visible on the public Internet. But they would still be useful for internal management. TXT records can be useful for ad-hoc local configs and the SPF use has made this harder. But it is hard to see how the SPF record makes that situation any better. Probably a better solution would be to take a chunk of the reserved RR code space and stipulate that these have TXT form records so folk have 10,16 or so records for this use. In the longer term, the problem with the SPF RR is that it is a point solution to 'fix' only one protocol. It is an MX record equivalent. Which was OK given the circumstances when it was developed. A shift from TXT to SPF records is not likely to happen for the niche SPF spec. But may well be practical for a wider client/initiator policy spec. Dear Phillip, It seems many of the larger providers are unwilling to process SPF macros due to inherent risks and inefficiency. Rather than accessing data using the DNS resource selectors of Name, Type, and Class, SPF uses mechanisms above DNS to utilize an additional domain, IP address, and email address input parameters merged with results generated from a series of proscribed DNS transactions. The macro feature was envisioned as leveraging these additional inputs to influence query construction. It seems lack of support by large providers has ensured scant few macros are published. in the beginning, there were several wanting a macro language to managing DNS processing with little idea where this would be headed. At the time there was already a dedicated binary resource record able to fully satisfied the information now obtained and used from SPF. Policy aspects of SPF are largely ignored due to exceptions often required. An SRV resource record resolving the location of a service could include an APL RR with CIDR information of all outbound IP addresses. This would offer load balancing and system priorities, while mapping outbound address space within two DNS transactions instead of the 111 recursive transactions expected by SPF. If one were starting over, DANE TLS or DTLS is a better solution that should be even easier to administer since it avoids a need to trust IP addresses and NATs. As with PKI, there are too many actors influencing routing's integrity. Regards, Douglas Otis
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Hello, This is a rough summary of the comments which have been made on the Last Call for draft-ietf-spfbis-4408bis-19 since I emailed Pete Resnick [1]. There were comments about the RFC 5507 concerns from Patrik Fältström [2], Dave Crocker [3], Mark Andrews [4] and John Klensin [5]. There were comments from Dan Schlitt [6] in which he provided his perspective of the SPFBIS discussions. In his opinion it is unwise to have a standards track protocol which overloads the TXT record. He suggested that the specification should be published as Informational. The comments provided by Dave Crocker [3] [7] and John Klensin [5][8] may also be related to the intended status of the specification. Phillip Hallam-Baker commented about the design objections [9]. I'll ask the Responsible Area Director for guidance about the above instead of suggesting that the SPFBIS WG address them. Joe Abley commented about the usage of messages sent over UDP [10]. This issue has been raised by Douglas Otis. My suggestion to the SPFBIS WG is to address this issue. Please email me if you consider your comments as not having been addressed correctly. I suggest waiting for Pete Resnicks to send a message to the mailing list if you sent Last Call comments before August 24. Regards, S. Moonesamy (as document shepherd) 1. http://www.ietf.org/mail-archive/web/ietf/current/msg81877.html 2. http://www.ietf.org/mail-archive/web/ietf/current/msg81887.html 3. http://www.ietf.org/mail-archive/web/ietf/current/msg81889.html 4. http://www.ietf.org/mail-archive/web/ietf/current/msg81891.html 5. http://www.ietf.org/mail-archive/web/ietf/current/msg81912.html 6. http://www.ietf.org/mail-archive/web/ietf/current/msg81939.html 7. http://www.ietf.org/mail-archive/web/ietf/current/msg81923.html 8. http://www.ietf.org/mail-archive/web/ietf/current/msg81924.html 9. http://www.ietf.org/mail-archive/web/ietf/current/msg81927.html 10. http://www.ietf.org/mail-archive/web/ietf/current/msg81862.html
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
On Thu, Aug 29, 2013 at 12:30 PM, Dan Schlitt schl...@theworld.com wrote: As the manager of a modestly large network I found the TXT record as a useful tool in management of the network. Such a use was even suggested by other system managers. That was a time when the Internet was a friendlier place. Today I might do things differently and not make some of the TXT records visible on the public Internet. But they would still be useful for internal management. TXT records can be useful for ad-hoc local configs and the SPF use has made this harder. But it is hard to see how the SPF record makes that situation any better. Probably a better solution would be to take a chunk of the reserved RR code space and stipulate that these have TXT form records so folk have 10,16 or so records for this use. In the longer term, the problem with the SPF RR is that it is a point solution to 'fix' only one protocol. It is an MX record equivalent. Which was OK given the circumstances when it was developed. A shift from TXT to SPF records is not likely to happen for the niche SPF spec. But may well be practical for a wider client/initiator policy spec. We are not going to get rid of the defective US style Edison screw lightbulb socket either, certainly not for incandescents even though the Swan bayonet design is clearly superior, less risk of damage to the bulb, safer and does not come undone. But that Edison screw style will eventually disappear as installation switches to low voltage (12V) DC distribution etc. The engineering solution to this deployment problem is to generalize the problem and use a new record for that. -- Website: http://hallambaker.com/
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
The engineering solution to this deployment problem is to generalize the problem and use a new record for that. Either that or figure out how to make it easy enough to deploy new RRTYPEs that people are willing to do so. The type number is 16 bits, after all. We're not in any danger of running out. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
John, Either that or figure out how to make it easy enough to deploy new RRTYPEs that people are willing to do so. The type number is 16 bits, after all. We're not in any danger of running out. We have been told on numerous occasions that one of the primary reasons for continued use of TXT is because middleboxes, etc., do not allow new RR types (something deprecation of the SPF RR would seem to only encourage). The number of bits in the type field would not seem to be particularly relevant to this. Regards, -drc
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
On Mon, Sep 2, 2013 at 9:56 AM, David Conrad d...@virtualized.org wrote: John, Either that or figure out how to make it easy enough to deploy new RRTYPEs that people are willing to do so. The type number is 16 bits, after all. We're not in any danger of running out. We have been told on numerous occasions that one of the primary reasons for continued use of TXT is because middleboxes, etc., do not allow new RR types (something deprecation of the SPF RR would seem to only encourage). The number of bits in the type field would not seem to be particularly relevant to this. Regards, -drc Which is a problem that I think can only be solved if there is a general solution of the policy distribution problem and an expectation that at least new middle boxen will support it. I have been pushing for some sort of 'Internet 2.0' branding for equipment that meets a comprehensive set of nextgen needs, i.e. IPv6, port forwarding, DNSSEC, border policy enforcement for that very reason. But it has to be a two way street. The reason DNS Choices fell flat is that it just told people what not to do to solve their problems, it did not provide a proposal that actually solved their problems. -- Website: http://hallambaker.com/
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
I did not participate in the original working group that developed SPF. However I had a number of long phone conversations with one of the folks who was active in the group. A good part of those conversations involved the use of the TXT record. I objected to overloading that RR. In response there was a bit of disparagement of namedroppers folks who joined in the discussions. In the end I was told that TXT worked and that was that. I did join in the current working group and when the subject of the TXT and SPF records came up I commented that I believed it was inappropriate to overload the TXT record and that the SPF record was the correct way to go and a transition plan should be worked out. It became clear that there was a group that were determined to use the TXT record and get rid of the SPF record. So I didn't see much benefit in pushing my view in the WG. As the manager of a modestly large network I found the TXT record as a useful tool in management of the network. Such a use was even suggested by other system managers. That was a time when the Internet was a friendlier place. Today I might do things differently and not make some of the TXT records visible on the public Internet. But they would still be useful for internal management. The discussions in the working group made it clear that there were design problems with SPF. It would have benefited from a well focused problem statement and a related requirements statement. Most of the problems are internal to the framework. It is a sender policy and there is no corresponding receiver policy framework. There were those who wished to add in things that essentially were a receiver policy. The design feature that has a wider impact on the Internet is the use of the DNS. The working group was dominated by the internals of the framework and had little concern with broader questions. Internally the TXT record was their choice. I believe that it is unwise to have a standards track protocol which overloads the TXT record. It is this last call which has a broader look at the proposed standard that is the place to make this judgment. As far as the current use of the SPF RR is concerned I have the feeling that the members of the working group had a rather optimistic view of the actual use of the sender policy. It is not on the standards track. Having a standards track version should encourage more use of the framework. If the standard said use the SPF record that would increase its use. A transition plan which allowed the current installed base to continue on would allow a standard with out disruption. It would be a shame to lose all the other work on the framework so, if the current version of the document can't for some reason be changed, it should be published as informational. It should be edited so that it describes the current use of the framework with suggestions for improved opperation. I do think that the folks who were tasked with leading the working group should be given credit for the job that they did. It was not the easiest working group to deal with. There were time when I feared that it would drop into the disfunctional state as, for example usefor. They avoided that and got the work back on track. /dan -- Dan Schlitt schl...@theworld.com
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
--On Wednesday, August 28, 2013 07:21 -0700 Dave Crocker d...@dcrocker.net wrote: RFC 5507 primarily raises three concerns about TXT records: RFC 5507 is irrelevant to consideration of the SPFbis draft. Really. RFC 5507 concerns approaches to design. However the SPFbis draft is not designing a new capability. It is documenting a mechanism that has existed for quite a long time, is very widely deployed, and has become an essential part of Internet Mail's operational infrastructure that works to counter abuse. ... Dave. I may be violating my promise to myself to stay out of SPF-specific issues, but this does not seem to me to be an SPF-specific issue. I suggest to you that the notions of IETF change control and consensus of the IETF community are very important to the integrity of how the IETF does things. The question of where and how the IETF adds value comes in there too. If some group --whether an IETF WG or some external committee or body-- comes to the IETF and says we have this protocol, it is well-tested and well-deployed, and we think the community would benefit from the IETF publishing its description that is great, we publish as Informational RFC (or the ISE does), and everyone is happy. If that group can get IETF community consensus for the idea that the spec should get a gold star, someone writes an Applicability Statement that points to the other document and says Recommended, we push any quibbles about downrefs out of the way, and we move on. However, it seems to me that, for anything that is proposed to be a normal standards track document, the community necessarily ought to be able to take at least one whack at it on IETF LC. That one whack principle suggests that one cannot say this was developed and deployed elsewhere and is being published as Experimental (which is what, IIR, was one thing that happened in the discussion of 4408) and then say now the design quality of SPF is not a relevant consideration because it has been considered elsewhere and widely deployed. If the IETF doesn't get a chance to evaluate design quality and even, if appropriate, to consider the tradeoffs between letting a possibly-odious specification be standardized and causing a fork between deployed-SPF and IETF-SPF, then the IETF's statements about what its standards mean become meaningless (at least in this particular type of case). Now I think it is perfectly reasonable to say, as you nearly did later in your note, that SPF-as-documented-in-4408bis is sufficiently deployed and would be sufficiently hard to change that the community should swallow its design preferences and standardize the thing. One can debate that position, but it is at least a reasonable position to take.Modulo some quibbles, it probably the position I'd take at this point if I were willing to take a position, but it is different from saying can't discuss the design choices. Things would also be very different if the present question involved updating or replacing an existing Proposed Standard. If design decisions were made in that earlier version (and that went through IETF LC and got consensus), I think it would be perfectly reasonable to say the IETF community looked at that before and it is now too late. You've done that before, I've done it before, and I don't think anyone who isn't prepared to explain why, substantively and in terms of deployment, it isn't too late should be able to object. But, in the absence of demonstrated and documented IETF consensus --independent of WG consensus, implementation consensus, deployment consensus, silent majority consensus, or any other type of claim about broader community consensus-- I don't think one can exclude a discussion of a specification's relationship to various design considerations, if only because that may be deployed but the IETF should not endorse it in that form by standardizing it or even if the community that is advocating this won't allow design issues to be discussed, then there is no IETF value-added and the IETF should decline to standardize on that basis have got to be possible IETF community responses. To consider RFC 5507 with respect to SPFbis is to treat the current draft as a matter of new work, which it isn't. No, it is to treat the current draft as a matter of work that the IETF is being asked to standardize for the first time... which, as far as I can tell, it is. I think those distinctions about standardization (including the value-added and change control ones) and what can reasonably be raised on IETF LC are important to the IETF, even for those who agree with you (entirely or in part) about what should happen with this particular specification at this particular point. YMMD. best, john
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
On 8/29/2013 9:31 AM, John C Klensin wrote: I may be violating my promise to myself to stay out of SPF-specific issues, Probably not, since your note has little to do with the realities of the SPFbis draft, which is a chartered working group product. You might want to review its charter: http://datatracker.ietf.org/wg/spfbis/charter/ Note the specified goal of standards track and the /very/ severe constraints on work to be done. Please remember that this is a charter that was approved by the IESG. The working group produced was it was chartered to produce, for the purpose that was chartered. More broadly, you (and others) might want to review that actual criteria the IETF has specified for Proposed in RFC2026. Most of us like to cite all manner of personal criteria we consider important. Though appealing, none of them is assigned formal status by the IETF, with respect to the Proposed Standards label; I believe in fact that there is nothing that we can point to, for such other criteria, represents IETF consensus for them. The claim that we can't really document our criteria mostly means that we think it's ok to be subjective and whimsical. Also for the broader topic, you also might want to reevaluate much of what your note does say, in light of the realities of Individual Submission (on the IETF track) which essentially never conforms to the criteria and concerns you seem to be asserting. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
--On Thursday, August 29, 2013 12:28 -0700 Dave Crocker d...@dcrocker.net wrote: On 8/29/2013 9:31 AM, John C Klensin wrote: I may be violating my promise to myself to stay out of SPF-specific issues, Probably not, since your note has little to do with the realities of the SPFbis draft, which is a chartered working group product. You might want to review its charter: http://datatracker.ietf.org/wg/spfbis/charter/ Note the specified goal of standards track and the /very/ severe constraints on work to be done. Please remember that this is a charter that was approved by the IESG. The working group produced was it was chartered to produce, for the purpose that was chartered. I have reviewed the charter, Dave. THe reasons I've wanted to stay out of this discussion made me afraid to make a posting without doing so. But the last I checked, WG charters are approved by the IESG after reviewing whatever comments they decide to solicit. They are not IETF Consensus documents. Even if this one was, the WG co-chair and document shepherd have made it quite clear that the WG carefully considered the design issue and alternatives at hand. I applaud that but, unless you are going to argue that the charter somehow allows the WG to consider some issues that cannot be reviewed on IETF Last Call, either the design issue is legitimate or the WG violated its charter. I, at least, can't read the charter that way. More broadly, you (and others) might want to review that actual criteria the IETF has specified for Proposed in RFC2026. Most of us like to cite all manner of personal criteria we consider important. Though appealing, none of them is assigned formal status by the IETF, with respect to the Proposed Standards label; I believe in fact that there is nothing that we can point to, for such other criteria, represents IETF consensus for them. The claim that we can't really document our criteria mostly means that we think it's ok to be subjective and whimsical. The statement to which I objected was one in which you claimed (at least as I understood it) that it was inappropriate to raise a design consideration because the protocol was already widely deployed. Your paragraph above makes an entirely different argument. As I understand it, your argument above is that it _never_ appropriate to object during IETF Last Call on the basis of design considerations (whether it is desirable to evaluate design considerations in a WG or not). I believe that design issues and architectural considerations can sometimes be legitimate examples of known technical defects. If they were not, then I don't know why the community is willing to spend time on such documents (or even on having an IAB). Again, it think it is perfectly reasonable to argue that a particular design or architectural consideration should not be applied to a particular specification. My problem arises only when it is claimed that such considerations or discussions are a priori inappropriate. Also for the broader topic, you also might want to reevaluate much of what your note does say, in light of the realities of Individual Submission (on the IETF track) which essentially never conforms to the criteria and concerns you seem to be asserting. If that were the case, either you are massively misunderstanding what I am asserting or I don't see your point. I believe that my prior note, and this one, assert only one thing, which is that it is inappropriate to bar any discussion --especially architectural or design considerations-- from IETF Last Call unless it addresses a principle that has already been established for the particular protocol by IETF Consensus. I remain completely comfortable, modulo the various rude language topics, with a discussion of why some architectural principle is irrelevant to a particular specification or even that trying to apply that principle would be stupid. But a discussion along those lines is still a discussion, not an attempt to prevent a discussion. And, yes, I believe that Individual Submissions should generally be subject to a much higher degree of scrutiny on IETF Last Call than WG documents. I also believe that, if there appears to be no community consensus one way or the other, that the IESG should generally defer to the WG on WG documents but default to non-approval of Individual Submissions. But, unless I'm completely misunderstanding the point you are trying to make, I don't see what that has to do with this topic. Dave, we had these sorts of discussions before. If there are a common patterns about them, they are that neither of us is likely to convince the other and that both of us soon get to the point of either muttering he just doesn't get it (or worse) into our beards or getting really short-tempered. I suggest that we not subject the community to that. By all means respond to this note if you feel a need to do (I'm not trying to get the last word and, if I
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
On Thu, Aug 29, 2013 at 12:31 PM, John C Klensin john-i...@jck.com wrote: --On Wednesday, August 28, 2013 07:21 -0700 Dave Crocker d...@dcrocker.net wrote: RFC 5507 primarily raises three concerns about TXT records: RFC 5507 is irrelevant to consideration of the SPFbis draft. Really. RFC 5507 concerns approaches to design. However the SPFbis draft is not designing a new capability. It is documenting a mechanism that has existed for quite a long time, is very widely deployed, and has become an essential part of Internet Mail's operational infrastructure that works to counter abuse. ... Dave. However, it seems to me that, for anything that is proposed to be a normal standards track document, the community necessarily ought to be able to take at least one whack at it on IETF LC. +1 That one whack principle suggests that one cannot say this was developed and deployed elsewhere and is being published as Experimental (which is what, IIR, was one thing that happened in the discussion of 4408) and then say now the design quality of SPF is not a relevant consideration because it has been considered elsewhere and widely deployed. That is something that seems to me to happen rather a lot. When I made private comments on the CBOR draft I was told that the authors felt free to ignore them because they were not engaged in an official IETF standards action. Then when I complained about the Proposed Standard status I was told that I was being rude for implying improper use of process. My view is that if an AD is going to sponsor an individual submission as standards track then this should be because the issue involved is of such narrow interest that only the individual submitter and a few others are interested in that type of proposal. If the IETF doesn't get a chance to evaluate design quality and even, if appropriate, to consider the tradeoffs between letting a possibly-odious specification be standardized and causing a fork between deployed-SPF and IETF-SPF, then the IETF's statements about what its standards mean become meaningless (at least in this particular type of case). I think that is a fair point but I don't think it is a fair characterization of the nature of the design objections being raised at the time which were: 1) 'Policy is hard so we should't do it' 2) Receivers must not infringe the rights of email senders I don't have a lot of tolerance for either objection. The first in particular led me to tell several people that if they don't consider themselves competent to solve a problem won't they kindly shut up and leave it to the people who do. But the outcome of the objections was that whether with justification or not, it was decided that these are objections that would be fully answered by running code. SPF was deployed and it works pretty much as the creators expected. And one of the reasons it was a good idea to get SPF dispatched quickly as Experimental was so that the rest of us could concentrate on DKIM. I think it is entirely reasonable to demand that when the IETF assists parties trying to deploy a proposal by endorsing it as a Proposed Standard then there should be an IETF consensus that the design is good. But that isn't the case here. Meng and co achieved deployment of their scheme without IETF endorsement. So what the IETF is now being asked to do is to recognize the fact that if you want to send email reliably on the Internet then you had better configure your systems for SPF and/or DKIM. -- Website: http://hallambaker.com/
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Hello, It's difficult, some might say impossible, to get agreement on draft-ietf-spfbis-4408bis. I would like to ask each of you, and anyone else, to provide your opinion about the following: RFC 5507 primarily raises three concerns about TXT records: 1. The data in TXT is unstructured and subject to misinterpretation by other applications. 2. Wildcard issues. 3. Size issues. The draft addresses (3) by discussing size considerations, and tangentially addresses (1) in Section 3.4. I would like to ask everyone not to turn this into a debate by not discussing about the opinion stated by someone else. Regards, S. Moonesamy (as document shepherd)
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
On 28 aug 2013, at 14:24, S Moonesamy sm+i...@elandsys.com wrote:
It's difficult, some might say impossible, to get agreement on
draft-ietf-spfbis-4408bis. I would like to ask each of you, and anyone else,
to provide your opinion about the following:
RFC 5507 primarily raises three concerns about TXT records:
As the main editor of RFC5507 I might have a different view of what RFC 5507
says than others...but...that said, here are my comments.
RFC5507 first of all lists a number of prerequisites that should always be
taken into account when extending the functionality of the domain name system.
The intention was that the alternatives in section 3 where to be taken
seriously as a way to solve the main problem, that the client when querying the
DNS should be able to do a selection of what records the client needs by
including the selector inside the triple {owner, type, class}. To solve that,
there are a number of possible solutions.
Then there are specific discussions about the TXT resource record as you say,
and those issues are included in the three issues you list below.
1. The data in TXT is unstructured and subject to misinterpretation by other
applications.
The data is in fact structured, in the form of a series of strings, each one of
them max 255 bytes long. But you are correct in the fact that RFC5507 does not
go into those details. But, the SPF specification do not use this structuring
that do exist, although it do (which is good) explicitly say that multiple such
strings should first be concatenated before progressing with parsing the SPF
record.
There is though no registry for the various formal uses of TXT records, and
because of that there might be confusion among the various uses. Note that I am
not saying that it is harder to write parsers, as for example an attacker can
intentionally try to feed whatever data into whatever format a resource record
do have. The parser must be robust regardless of the format.
Whether the SPF format itself is too complicated (I see various theoretical
calculations on hundreds of RRSets be needed to get one SPF resolution correct)
or not, that is *NOT* something I am evaluating here.
2. Wildcard issues.
Correct.
3. Size issues.
Correct, in two ways. It explicitly talks about the size of the TXT record, but
RFC5507 also talks about the size of a Resource Record Set, which is what is
returned to the client that queries. One also have to think about the size of
the transaction, and specifically the complete response sent from the server,
that contain multiple resource record sets.
I.e. we have:
3.1. The size limit 255 bytes for one string in the TXT record
3.2. The size of one TXT resource record (because the data is stored as text
and not binary)
3.3. The size of a resource record set with the same owner, type and class
3.4. The size of a response to a query for a specific owner, type and class
The draft addresses (3) by discussing size considerations, and tangentially
addresses (1) in Section 3.4.
If we take the size issue first (3) it sort of looks at all of (3.1)-(3.4)
above but not in a very clear way. The discussion in specifically section 3.4
is very confusing. It mixes up DNS response size with UDP payload size with MTU
size. Because the text is not clear in its assumptions, it is very hard to say
whether one agree or not with the conclusions. In turn, that leads to it being
even harder to decide whether one agree or not with the conclusions on being as
backward compatible with old implementations as is claimed being a necessity.
I.e. there are a lot of claims in 3.4 based on unclear assumptions.
Further, if 3.4 is looking at the full response size, then it should also look
at the response size in a similar way that has been done for DNSSEC, where also
DNSSEC material is part of the response size (but then of course EDNS0 is in
use).
Regarding the structure of the data, (1) above, it touches on it in section 3.3
and 3.4, but in reality the structure is really up to the parser and I think
that is for this discussion sort of a non-issue.
I am more worried over (3.3) above, which is the core of RFC5507 that is really
a problem, specifically together with the lack of a registry for the selectors
that is part of the RDATA. If we compare with the other experience we do have,
NAPTR, where this problem is a fact, we at least have a registry for the
selectors so that we do know there will not be any collisions.
Yes, I do know SPF syntax do have an ability to refer to a record with a
prefix, but that does not really help as the large RRSet is sent back in the
response already to the first query.
I would like to ask everyone not to turn this into a debate by not discussing
about the opinion stated by someone else.
Regards,
S. Moonesamy (as document shepherd)
Patrik
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
On 8/28/2013 5:24 AM, S Moonesamy wrote: It's difficult, some might say impossible, to get agreement on draft-ietf-spfbis-4408bis. I would like to ask each of you, and anyone else, to provide your opinion about the following: RFC 5507 primarily raises three concerns about TXT records: RFC 5507 is irrelevant to consideration of the SPFbis draft. Really. RFC 5507 concerns approaches to design. However the SPFbis draft is not designing a new capability. It is documenting a mechanism that has existed for quite a long time, is very widely deployed, and has become an essential part of Internet Mail's operational infrastructure that works to counter abuse. Internet Mail already relies on SPF and has for many years. To consider RFC 5507 with respect to SPFbis is to treat the current draft as a matter of new work, which it isn't. No one is arguing that SPF's use of the TXT record is preferable. All newer uses of the TXT record use a scoping mechanism (through an underscore-based node name) to avoid all of the classic TXT record ambiguity concerns. My professional assessment of SPF is that there are many ways it could have been designed better. My other professional assessment is that the design quality of SPF ceased to be a relevant consideration, as soon as it gained widespread traction. Wide deployment equals very large-scale consensus and quite a lot of running code. The IETF says it cares about those two attributes. If IETF technical work is to have any relation to the operational Internet, it needs to treat solid, real-world deployment as having higher priority than theoretical technical perfection. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
On Wednesday, August 28, 2013 07:21:13 Dave Crocker wrote: On 8/28/2013 5:24 AM, S Moonesamy wrote: It's difficult, some might say impossible, to get agreement on draft-ietf-spfbis-4408bis. I would like to ask each of you, and anyone else, to provide your opinion about the following: RFC 5507 primarily raises three concerns about TXT records: RFC 5507 is irrelevant to consideration of the SPFbis draft. Really. RFC 5507 concerns approaches to design. However the SPFbis draft is not designing a new capability. It is documenting a mechanism that has existed for quite a long time, is very widely deployed, and has become an essential part of Internet Mail's operational infrastructure that works to counter abuse. Internet Mail already relies on SPF and has for many years. To consider RFC 5507 with respect to SPFbis is to treat the current draft as a matter of new work, which it isn't. No one is arguing that SPF's use of the TXT record is preferable. All newer uses of the TXT record use a scoping mechanism (through an underscore-based node name) to avoid all of the classic TXT record ambiguity concerns. My professional assessment of SPF is that there are many ways it could have been designed better. My other professional assessment is that the design quality of SPF ceased to be a relevant consideration, as soon as it gained widespread traction. Wide deployment equals very large-scale consensus and quite a lot of running code. The IETF says it cares about those two attributes. If IETF technical work is to have any relation to the operational Internet, it needs to treat solid, real-world deployment as having higher priority than theoretical technical perfection. Yes. Please. Scott K
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
In message 6.2.5.6.2.20130828044224.06ee3...@resistor.net, S Moonesamy writes : Hello, It's difficult, some might say impossible, to get agreement on draft-ietf-spfbis-4408bis. I would like to ask each of you, and anyone else, to provide your opinion about the following: RFC 5507 primarily raises three concerns about TXT records: 1. The data in TXT is unstructured and subject to misinterpretation by other applications. 2. Wildcard issues. 3. Size issues. The draft addresses (3) by discussing size considerations, and tangentially addresses (1) in Section 3.4. I would like to ask everyone not to turn this into a debate by not discussing about the opinion stated by someone else. Regards, S. Moonesamy (as document shepherd) I would start by saying that the list of issues identified by RFC 5507 is not complete. RFC 5507 addresses selection of data to be returned by the nameserver. It fails to address the issues of updating data in the server using RFC 2136 + RFC 2845. For prefix, suffix and a new types this is pretty straight forward as you have a name,type,class tuple that is unique to the application and nameservers have access control mechanisms that are designed to allow / disallow updates at this level so you can hand out the ability to update records without having unintended consequences. When you place selectors inside records which have a shared purpose you lose the ability to hand out selective update without risking unintended consequences or you require nameserver vendors to develop new access control mechanisms which work on the record contents in addition to the name,type,class tuple. You can't say delete all records of this type at this name then add this replacement set in a single transaction. It becomes read the data at the tuple, workout what to delete, send a update message that selectively deletes then adds records. This introduces race conditions etc. As for wildards. Spf is often used to say that names generated by wildcards do not send email. This essentially precludes the use of a prefix. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Overloaded TXT harmful (was 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)
--On Monday, August 26, 2013 10:49 -0400 John R Levine jo...@taugh.com wrote: Sorry if that last one came across as dismissive. Until such time, I'd personally prefer to see some explicit notion that the odd history of the SPF TXT record should not be seen as a precedent and best practice, rather than hope that this is implicit. I'd have thought that the debate here and elsewhere already documented that. Since it's not specific to SPF, perhaps we could do a draft on overloaded TXT considered harmful to get it into the RFC record. With the help of a few others, I've got a I-D in the pipe whose function is to create an IANA registry of structured protocol uses for TXT RR data and how to recognize them. I hope it will be posted later this week. Its purpose is to lower the odds of overloaded sliding into different uses for forms that are not easily distinguished. Other than inspiration, its only relationship to the current SPF discussion is that some SPF-related information is a candidate for registration (whether as an active use or as a deprecated one). It already contains some text that warns that overloading TXT is a bad idea but that, because it happens and has happened, identifying those uses is appropriate. Once it is posted, I/we would appreciate any discussion that would lead to consensus about just how strong that warning should be and how it should be stated. best, john
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
On 2013-08-26, at 22:28, S Moonesamy sm+i...@elandsys.com wrote: The permitted size of the UDP packet is NOT 512 octets. That is the permitted size of the DNS Message. DNS Message is not the same thing as a UDP packet. Per RFC1035 Section 2.3.4. Size limits UDP messages512 octets or less I'll suggest UDP message. The consistent word for this in 1035 is simply message. DNS Message is in more common use today, I would say. The text you quoted from 1035 is most usefully interpreted as a contraction of messages sent over UDP; UDP message really doesn't have a well-understood meaning, and is easily conflated with UDP datagram which does not have a size limitation of 512 bytes. Joe
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Hi Joe, At 08:59 27-08-2013, Joe Abley wrote: The consistent word for this in 1035 is simply message. DNS Message is in more common use today, I would say. The text you quoted from 1035 is most usefully interpreted as a contraction of messages sent over UDP; UDP message really doesn't have a well-understood meaning, and is easily conflated with UDP datagram which does not have a size limitation of 512 bytes. Thanks for explaining this. Please note that I personally agree with what you wrote. My understanding is that the text in Section 3.4 is trying to say DNS messages over UDP. There was some discussion about that (see http://www.ietf.org/mail-archive/web/spfbis/current/msg03088.html http://www.ietf.org/mail-archive/web/spfbis/current/msg03090.html http://www.ietf.org/mail-archive/web/spfbis/current/msg03109.html ). Regards, S. Moonesamy (as document shepherd)
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
I probably should have sent out this message over the weekend, but I was hoping I would complete a bigger message soon. Since I'm still working on that, a quick note to level set: I have been reading all of the Last Call responses as they have come in. I am in the process of reviewing the comments and making a summary of the issues and responses. I have asked SM as document shepherd to do the same. (Being far more diligent than I, SM has completed his review already and is waiting on me.) We will be comparing notes and posting a summary of the issues and how they were addressed, along with whether we think they are resolved. That will give folks who disagree with my assessment one last chance to say, Pete, you completely misunderstood what my objection / response was saying and you should re-evaluate your consensus determination on this issue. After that all shakes out, I'll make the final call on consensus. An important thing to note is that I am seeing scant little I would call a new argument since late last week, so I would suggest that you are probably not adding to my understanding of the consensus by continuing to post. I'd like to think that everyone would be able to notice that things have gotten repetitive, both the folks who are repeating things as well as the folks who think they have to keep answering, but there does seem to be a bit of getting the last word in going on. Doing so isn't likely to add to my understanding or sway my opinion of the consensus (since I'm making a list of independent issues and their answers, not counting posts), but it does make it take longer for me to get through my review. So I'd recommend posting judiciously, at least until you see my summary. Thanks, pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478
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
On 08/23/2013 04:34 PM, John Levine wrote: I don't know of any (at least ones that are used in the global dns namespace), and I would like to still not know of any in 2033. Since we agree that the issue you're worried about has not arisen even once in the past decade, could you clarify what problem needs to be solved here? prevented, not solved. I would like to prevent someone from having to submit a draft specifying that in the case of TXT, the (name, class, type)-tuple should be extended with the first X octets from the RDATA fields, somewhere in the future, because client-side demuxing is getting too buggy and it seems like a good idea to select specific records in the DNS itself. Jelte
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
prevented, not solved. I would like to prevent someone from having to submit a draft specifying that in the case of TXT, the (name, class, type)-tuple should be extended with the first X octets from the RDATA fields, somewhere in the future, because client-side demuxing is getting too buggy and it seems like a good idea to select specific records in the DNS itself. Could you point to anyone, anywhere, who has ever said that the odd history of the SPF TXT record means that it is perfectly fine to do something similar in the future? On the other hand, please look at all of the stuff that people outside of the IETF do with apex TXT records, and try and say with a straight face that SPF as as much as 1% of the multiplexing problem. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY I dropped the toothpaste, said Tom, crestfallenly.
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
On 08/26/2013 04:08 PM, John R Levine wrote: Could you point to anyone, anywhere, who has ever said that the odd history of the SPF TXT record means that it is perfectly fine to do something similar in the future? Three of the four points on the list that triggered my first message in this particular thread were: - no this new rrtype support in my provisioning system - no this new rrtype support in my firewall - no this new rrtype support in my DNS Library Those aren't things that'll magically disappear, even with universal deployment of 3597. Some, and maybe all of these, might be generally solved if draft-levine-dnsextlang takes off, though I have serious doubts about the second, and some doubts about the first. Until such time, I'd personally prefer to see some explicit notion that the odd history of the SPF TXT record should not be seen as a precedent and best practice, rather than hope that this is implicit. On the other hand, please look at all of the stuff that people outside of the IETF do with apex TXT records, and try and say with a straight face that SPF as as much as 1% of the multiplexing problem. There may be a reason those are not standardized. And not just because there are too many grumpy people here shouting 'get off my lawn'. Or at least not all of them :) Jelte
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
Sorry if that last one came across as dismissive. Until such time, I'd personally prefer to see some explicit notion that the odd history of the SPF TXT record should not be seen as a precedent and best practice, rather than hope that this is implicit. I'd have thought that the debate here and elsewhere already documented that. Since it's not specific to SPF, perhaps we could do a draft on overloaded TXT considered harmful to get it into the RFC record. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY I dropped the toothpaste, said Tom, crestfallenly. smime.p7s Description: S/MIME Cryptographic Signature
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
On 08/26/2013 04:49 PM, John R Levine wrote: Sorry if that last one came across as dismissive. Until such time, I'd personally prefer to see some explicit notion that the odd history of the SPF TXT record should not be seen as a precedent and best practice, rather than hope that this is implicit. I'd have thought that the debate here and elsewhere already documented that. Since it's not specific to SPF, perhaps we could do a draft on overloaded TXT considered harmful to get it into the RFC record. It certainly documents there are some persistent people walking around the dns world ;) That draft may not be a bad idea. Jelte
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
On 08/26/2013 04:55 PM, Jelte Jansen wrote: I'd have thought that the debate here and elsewhere already documented that. Since it's not specific to SPF, perhaps we could do a draft on overloaded TXT considered harmful to get it into the RFC record. That draft may not be a bad idea. It has been pointed out to me that rfc5507 already exists. I'll shut up now. Jelte
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
On Aug 24, 2013, at 3:16 AM, S Moonesamy sm+i...@elandsys.com wrote: Hi Doug, At 13:07 23-08-2013, Douglas Otis wrote: The SPFbis document improperly conflates DNS terminology with identical terms invented by this document. Examples are terms used to describe mechanisms having the same identifier differentiated between mechanisms and DNS resource records by using lower and upper case respectively. References to SPF records are differentiated by a textual prefix and not by TYPE as defined by DNS. Could you provide some examples of the above as I would like to clearly understand the argument? Dear SM, Thank you for your questions. Sorry for the delay while helping a sick friend and colleague. When the SPF document refers to Sender Policy Framework (SPF) records or SPF records this conflicts with DNS's record definition. It is wrong to refer to these as records. RFC1034 defines resource records as TTL and RDATA that is selected by Owner (domain), Type (16 bit value), and Class (16 bit value). No such selection is possible for SPF. SPF uses a subclass of TXT resource records using a non-standard prefix that has no registry, nor is a registry practical at this point. Terminology used by SPF sounds as if it refers directly to DNS elements. It does not. This poor terminology is misleading and makes properly expressing security concerns difficult where this confusion seems to be by design. In addition, the MARID WG NEVER reached consensus. A follow-on group operating outside of the IETF required a promise of support to subscribe to their mailing list. When one looks at how SPF is commonly used, the pre-existing APL resource record offered an effective alternative, but was oppose by a particular vendor unwilling to fully implement DNS. Currently this vendor is seldom used to directly interface with MTAs on the Internet and no longer justifies the use of the TXT records. As such, the SPF Resource Record should not have been deprecated. There are other messages on the Last Call about the SPF Resource Record. I'll take up the above together with the other comments. This draft should be made Informational and not Standards Track. I suggest providing arguments for that. The SPF protocol was an effort that ignored concerns expressed within the DNS community about the effect of overloading TXT and use of dynamic macro query names modified by email elements wholly unconstrained by a sender's infrastructure. The SPF macro scheme can greatly amplify the impact of an already large number of DNS transactions. By overloading TXT, updating SPF is improbable. By rarely being the target of a DDoS attack, it becomes easy to speak in derogatory terms as this issue being the fault of DNS. The primary use of SPF today is to define email outbound address space. The policy aspects related to the all mechanism is largely ignored due to a high number of required exceptions. Rather than using the existing APL Resource Record in the form of _email.domain APL CIDRs in binary form, the group devised a macro language to authorize various email elements using text to accommodate a vendor that since became practically irrelevant for Internet email exchange. Although most large providers now ignore SPF macros, very few domains publish them as well. Macros interfere with a provider's effort at mapping a domain's address space. Most consider the authorization for email-address local parts the sender's role. Nevertheless, the WG failed to warn of this issue by either deprecating or advising against macro publication. Macros inhibit effective caching, imperil SMTP server security, and degrade interchange. This is not a good candidate for standardization if this category is expected to retain any value or the IETF is to offer helpful guidance. Simply because SPF did not stipulate DNSSEC does not mean DNSSEC can be ignored. Not considering DNSSEC is an example of a failed consideration. Must the world wait for SPF to change before DNSSEC can be safely deployed? Overloading of TXT resource records at the zone apex along with macro scripts able to leverage email elements to direct reflected attacks from cached resource records is an example why this document should not be deemed a standard. Section 4.6.4 fails to offer a sufficiently clear warning about potential magnitudes of DNS transactions initiated by a single SPF evaluation where two are recommended to occur one for the separate identifiers. In fact, this section appears to make assurances no more that 10 DNS queries will result and is widely misunderstood. There is a discussion about Section 4.6.4 at http://www.ietf.org/mail-archive/web/spfbis/current/msg03305.html There is a trend by large providers to switch over to using wildcards on enormous networks to track users instead of using cookies. The impact this has on the past conversations is enormous. This
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
On Monday, August 26, 2013 15:42:41 Douglas Otis wrote: Please also note that the PTR RR is not constrained in the current specification and can create erratic results. It would be far safer to Perm error when overflowing on the number of PTR records. There is no upper limit as some represent web farms hosting thousands of domains. This exact issue was the subject of working group discussion. Since the number of PTR records is an attribute of the connect IP, it is under the control of the sending party, not the domain owner. A cap that resulted in an error would, as a result, enable the sender to arbitrarily get an SPF permerror in place of a fail if desired. The WG considered that not a good idea. Scott K
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
On Aug 26, 2013, at 3:48 PM, Scott Kitterman sc...@kitterman.com wrote: On Monday, August 26, 2013 15:42:41 Douglas Otis wrote: Please also note that the PTR RR is not constrained in the current specification and can create erratic results. It would be far safer to Perm error when overflowing on the number of PTR records. There is no upper limit as some represent web farms hosting thousands of domains. This exact issue was the subject of working group discussion. Since the number of PTR records is an attribute of the connect IP, it is under the control of the sending party, not the domain owner. A cap that resulted in an error would, as a result, enable the sender to arbitrarily get an SPF permerror in place of a fail if desired. The WG considered that not a good idea. Dear Scott, It is within the control of the Domain owner about whether to make use of the ptr mechanism in their SPF TXT. Random ordering or responses is also controlled by the IP address owner and not the Domain owner. The ptr mechanism may offer intermittent results that will be difficult to troubleshoot. By offering a Perm error on a ptr overflow, the domain owner is quickly notified this mechanism should not be used and are not fooled by it working some of the time. The greater concern is in regard to the over all response sizes when DNSSEC is used. In that case, response sizes can grow significantly. Allowing large responses to occur without producing an error seems like a risky strategy from the DDoS perspective. That is also another reason for worrying about the use of TXT RRs. How many large wildcard TXT RR exist, and if they do, who would be at fault when this becomes a problem for SPF? Regards, Douglas Otis
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
On Monday, August 26, 2013 16:28:03 Douglas Otis wrote: On Aug 26, 2013, at 3:48 PM, Scott Kitterman sc...@kitterman.com wrote: On Monday, August 26, 2013 15:42:41 Douglas Otis wrote: Please also note that the PTR RR is not constrained in the current specification and can create erratic results. It would be far safer to Perm error when overflowing on the number of PTR records. There is no upper limit as some represent web farms hosting thousands of domains. This exact issue was the subject of working group discussion. Since the number of PTR records is an attribute of the connect IP, it is under the control of the sending party, not the domain owner. A cap that resulted in an error would, as a result, enable the sender to arbitrarily get an SPF permerror in place of a fail if desired. The WG considered that not a good idea. Dear Scott, It is within the control of the Domain owner about whether to make use of the ptr mechanism in their SPF TXT. Random ordering or responses is also controlled by the IP address owner and not the Domain owner. The ptr mechanism may offer intermittent results that will be difficult to troubleshoot. By offering a Perm error on a ptr overflow, the domain owner is quickly notified this mechanism should not be used and are not fooled by it working some of the time. The greater concern is in regard to the over all response sizes when DNSSEC is used. In that case, response sizes can grow significantly. Allowing large responses to occur without producing an error seems like a risky strategy from the DDoS perspective. That is also another reason for worrying about the use of TXT RRs. How many large wildcard TXT RR exist, and if they do, who would be at fault when this becomes a problem for SPF? Your conclusion is different than the one the working group reached. Scott K
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
On Aug 26, 2013, at 4:29 PM, Scott Kitterman sc...@kitterman.com wrote: On Monday, August 26, 2013 16:28:03 Douglas Otis wrote: On Aug 26, 2013, at 3:48 PM, Scott Kitterman sc...@kitterman.com wrote: On Monday, August 26, 2013 15:42:41 Douglas Otis wrote: Please also note that the PTR RR is not constrained in the current specification and can create erratic results. It would be far safer to Perm error when overflowing on the number of PTR records. There is no upper limit as some represent web farms hosting thousands of domains. This exact issue was the subject of working group discussion. Since the number of PTR records is an attribute of the connect IP, it is under the control of the sending party, not the domain owner. A cap that resulted in an error would, as a result, enable the sender to arbitrarily get an SPF permerror in place of a fail if desired. The WG considered that not a good idea. Dear Scott, It is within the control of the Domain owner about whether to make use of the ptr mechanism in their SPF TXT. Random ordering or responses is also controlled by the IP address owner and not the Domain owner. The ptr mechanism may offer intermittent results that will be difficult to troubleshoot. By offering a Perm error on a ptr overflow, the domain owner is quickly notified this mechanism should not be used and are not fooled by it working some of the time. The greater concern is in regard to the over all response sizes when DNSSEC is used. In that case, response sizes can grow significantly. Allowing large responses to occur without producing an error seems like a risky strategy from the DDoS perspective. That is also another reason for worrying about the use of TXT RRs. How many large wildcard TXT RR exist, and if they do, who would be at fault when this becomes a problem for SPF? Your conclusion is different than the one the working group reached. Dear Scott, Do you recall whether DNSSEC had been considered? Regards, Douglas Otis
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Douglas Otis doug.mtv...@gmail.com wrote: On Aug 26, 2013, at 4:29 PM, Scott Kitterman sc...@kitterman.com wrote: On Monday, August 26, 2013 16:28:03 Douglas Otis wrote: On Aug 26, 2013, at 3:48 PM, Scott Kitterman sc...@kitterman.com wrote: On Monday, August 26, 2013 15:42:41 Douglas Otis wrote: Please also note that the PTR RR is not constrained in the current specification and can create erratic results. It would be far safer to Perm error when overflowing on the number of PTR records. There is no upper limit as some represent web farms hosting thousands of domains. This exact issue was the subject of working group discussion. Since the number of PTR records is an attribute of the connect IP, it is under the control of the sending party, not the domain owner. A cap that resulted in an error would, as a result, enable the sender to arbitrarily get an SPF permerror in place of a fail if desired. The WG considered that not a good idea. Dear Scott, It is within the control of the Domain owner about whether to make use of the ptr mechanism in their SPF TXT. Random ordering or responses is also controlled by the IP address owner and not the Domain owner. The ptr mechanism may offer intermittent results that will be difficult to troubleshoot. By offering a Perm error on a ptr overflow, the domain owner is quickly notified this mechanism should not be used and are not fooled by it working some of the time. The greater concern is in regard to the over all response sizes when DNSSEC is used. In that case, response sizes can grow significantly. Allowing large responses to occur without producing an error seems like a risky strategy from the DDoS perspective. That is also another reason for worrying about the use of TXT RRs. How many large wildcard TXT RR exist, and if they do, who would be at fault when this becomes a problem for SPF? Your conclusion is different than the one the working group reached. Dear Scott, Do you recall whether DNSSEC had been considered? My recollection is that it was discussed. I believe it was concluded that SPF would benefit from the enhanced security associated with DNSSEC. SPF doesn't seem to suffer from any unique problems associated with the potential for a larger payload. Scott K
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Hi Doug, At 15:42 26-08-2013, Douglas Otis wrote: When the SPF document refers to Sender Policy Framework (SPF) records or SPF records this conflicts with DNS's record definition. It is wrong to refer to these as records. RFC1034 defines resource records as TTL and RDATA that is selected by Owner (domain), Type (16 bit value), and Class (16 bit value). No such selection is possible for SPF. SPF uses a subclass of TXT resource records using a non-standard prefix that has no registry, nor is a registry practical at this point. Terminology used by SPF sounds as if it refers directly to DNS elements. It does not. This poor terminology is misleading and makes properly expressing security concerns difficult where this confusion seems to be by design. As there is an ongoing Last Call the IETF can comment about the above. I'll leave it to the IESG to evaluate whether the terminology used in the draft needs to be reconsidered if there aren't any comments. The SPF protocol was an effort that ignored concerns expressed within the DNS community about the effect of overloading TXT and use of dynamic macro query names modified by email elements wholly unconstrained by a sender's infrastructure. The SPF macro scheme can greatly amplify the impact of an already large number of DNS transactions. By overloading TXT, updating SPF is improbable. By rarely being the target of a DDoS attack, it becomes easy to speak in derogatory terms as this issue being the fault of DNS. There has been comments about overloading TXT during the Last Call. I'll keep it separate from the use of dynamic macro query names. The primary use of SPF today is to define email outbound address space. The policy aspects related to the all mechanism is largely ignored due to a high number of required exceptions. Rather than using the existing APL Resource Record in the form of _email.domain APL CIDRs in binary form, the group devised a macro language to authorize various email elements using text to accommodate a vendor that since became practically irrelevant for Internet email exchange. Although most large providers now ignore SPF macros, very few domains publish them as well. Macros interfere with a provider's effort at mapping a domain's address space. Most consider the authorization for email-address local parts the sender's role. Nevertheless, the WG failed to warn of this issue by either deprecating or advising against macro publication. Macros inhibit effective caching, imperil SMTP server security, and degrade interchange. This is not a good candidate for standardization if this category is expected to retain any value or the IETF is to offer helpful guidance. Simply because SPF did not stipulate DNSSEC does not mean DNSSEC can be ignored. Not considering DNSSEC is an example of a failed consideration. Must the world wait for SPF to change before DNSSEC can be safely deployed? Overloading of TXT resource records at the zone apex along with macro scripts able to leverage email elements to direct reflected attacks from cached resource records is an example why this document should not be deemed a standard. Thanks for providing the arguments. I'll leave the question of whether the document should or should not be a good candidate for standardization to IESG evaluation. There is a trend by large providers to switch over to using wildcards on enormous networks to track users instead of using cookies. The impact this has on the past conversations is enormous. This eliminates the effect of the void response limit while also increasing the amount of the resulting traffic. random-stringhttp://cdr-ds.metric.gstatic.com/cdr-ds.metric.gstatic.com random-string.http://g.vm.akamaistream.net/g.vm.akamaistream.net The above can be considered together with the other arguments about the TXT RR. Please also note that the PTR RR is not constrained in the current specification and can create erratic results. It would be far safer to Perm error when overflowing on the number of PTR records. There is no upper limit as some represent web farms hosting thousands of domains. The title of Section 5.5 is: ptr (do not use). There is a note in Section 5.5 about the mechanism. There is some discussion of PTR at http://www.ietf.org/mail-archive/web/spfbis/current/msg01883.html This timeout is not likely problematic after ensuring against macros where then caching can be effective at overcoming this constraint. I'll list this one as a non-issue. That does not mean DNSSEC will not be used. One hopes just the opposite is true. I took a quick look at draft-ietf-spfbis-4408bis-19. I did not see any mention of DNSSEC. The permitted size of the UDP packet is NOT 512 octets. That is the permitted size of the DNS Message. DNS Message is not the same thing as a UDP packet. Per RFC1035 Section 2.3.4. Size limits UDP messages512 octets or less I'll
Re: Rude responses (Was: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)
I experienced rude respondings in IETF list and in one WG list, I don't beleive that it is culture of IETF participants, but it seems that some people should understand to be polite and reasonable in such organisation business. Finally, the rude responding is not controled by the chair of thoes lists, therefore, thoes lists can be rude lists from time to time. AB On Thu, Aug 22, 2013 at 5:46 AM, Pete Resnick presn...@qti.qualcomm.comwrote: On 8/21/13 2:17 PM, Dave Crocker wrote: On 8/21/2013 11:58 AM, Pete Resnick wrote: AD hat squarely on my head. On 8/21/13 1:29 PM, Dave Crocker wrote: Oh. Now I understand. You are trying to impose new requirements on the original work, many years after the IETF approved it. Thanks. Very helpful. That's not an appropriate response. It is certainly not helpful to me as the consensus caller. And it is rude. Since you've made this a formal process point, I'll ask you to substantiate it carefully and also formally. The implication of your assessment is that IETF participants must not comment on the utility of comments by others. That's not what I said, and in fact if you look at the line immediately following what you quoted, you will see that I said: It's perfectly reasonable to say, This would constitute a new requirement and I don't think there is a good justification to pursue that line. It is not your complaint about the imposition of new requirements that is problematic, or your point that it is not useful to continue that line of discussion. Talk about the utility of a comment all that you want. It is the sarcasm and the rudeness that I am saying is unreasonable. Especially coming from a senior member of the community, the only purpose it seems to serve is to bully others into not participating in the conversation. If you think that the conversation has gone on too long, you're perfectly within rights to ask the manager of the thread (in this case, myself or the chairs), in public if you like, to make a call and say that the issue is closed. But again, the tactics displayed above are not professional and not reasonable rhetorical mode. I don't recall that being a proscribed behavior, since it has nothing to do with personalities. So, please explain this in a way that does not sound like Procrustean political correctness. I am not sure what the first sentence means. And I'm sorry that you believe that my stance on this is Procrustean. But the fact is that rude comments of this sort do not contribute to consensus-building in the least. For the record, I entirely acknowledge that my note has an edge to it and yes, of course alternate wording was possible. However the thread is attempting to reverse extensive and careful working group effort and to ignore widely deployed and essential operational realities, including published research data. I appreciate your input that you believe that some or all of the objectors are ignoring operational realities. Perhaps they are. But the fact is that Last Call is a time for the community to take a last look at WG output. If senior members of the community (among which there are several in this thread) are suspicious of the output, it *is* important to make sure that their concerns are addressed. Maybe they simply don't have all of the information. But maybe the WG has missed something essential in all that careful work. Both have historically happened many times. A bit of edge is warranted for such wasteful, distracting and destabilizing consumption of IETF resources. In fact an important problem with the alternate wording, such as you offered, is that it implies a possible utility in the thread that does not exist. It is far more distracting and destabilizing for the IETF to come out of a Last Call with experienced members of the community suspicious that a bad result has occurred, especially if the tactic used to end the discussion was sarcasm to chase people away from the discussion. You are looking at only the little picture. The consensus might end up on the rough side, but having the conversation has utility in and of itself. I find your edge much more disruptive to the conversation, making it much more adversarial than explanatory, and damaging the consensus that might be built. I think that lowers the utility of the output tremendously. pr -- Pete Resnickhttp://www.qualcomm.**com/~presnick/http://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Hi Doug, At 13:07 23-08-2013, Douglas Otis wrote: The SPFbis document improperly conflates DNS terminology with identical terms invented by this document. Examples are terms used to describe mechanisms having the same identifier differentiated between mechanisms and DNS resource records by using lower and upper case respectively. References to SPF records are differentiated by a textual prefix and not by TYPE as defined by DNS. Could you provide some examples of the above as I would like to clearly understand the argument? In addition, the MARID WG NEVER reached consensus. A follow-on group operating outside of the IETF required a promise of support to subscribe to their mailing list. When one looks at how SPF is commonly used, the pre-existing APL resource record offered an effective alternative, but was oppose by a particular vendor unwilling to fully implement DNS. Currently this vendor is seldom used to directly interface with MTAs on the Internet and no longer justifies the use of the TXT records. As such, the SPF Resource Record should not have been deprecated. There are other messages on the Last Call about the SPF Resource Record. I'll take up the above together with the other comments. This draft should be made Informational and not Standards Track. I suggest providing arguments for that. Section 4.6.4 fails to offer a sufficiently clear warning about potential magnitudes of DNS transactions initiated by a single SPF evaluation where two are recommended to occur one for the separate identifiers. In fact, this section appears to make assurances no more that 10 DNS queries will result and is widely misunderstood. There is a discussion about Section 4.6.4 at http://www.ietf.org/mail-archive/web/spfbis/current/msg03305.html 4.6.4. DNS Lookup Limits Was: ,-- SPF implementations MUST limit the total number of mechanisms and modifiers (terms) that cause any DNS query to 10 during SPF evaluation. '-- Change to: ,--- SPF evaluation must limit the number of mechanisms, and the modifier term 'redirect' to occur in no more than10 instances within the evaluation process. The mechanisms 'ip4', ip6', and 'all' are excluded from this instance limitation. Each mechanism is permitted to resolve subsequent resource record sets (RRsets) that MUST not contain more than 10 resource records to complete a match check. When the number of instances exceeds 10, or when subsequent resolutions exceeds 10, check_host() MUST produce a permerror result. The maximum number of DNS transactions initiated by an SPF evaluation is therefore 1 for the initial SPF resource record, 10 for each mechanism times 10 transactions needed to complete a matching process for a total of 111 DNS transactions. This number excludes those required by DNS to fulfill a request and those required by an EXP modifier. I'll list the above as not addressed yet. The recommended 20 second evaluation timeout imposes a maximum network distance of less than 27,000 kilometers or a little more than half the circumference of the Earth. Even a 60 millisecond delay can result in more than a 6.6 seconds consumed by the round trip overhead needed for each SPF evaluation. During the WGLC Murray Kucherawy asked a question about the 20 second evaluation timeout ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03700.html ). The answer was that the timeout is already in RFC 4408. The overall resulting maximum number of DNS transactions for both HELO and MAIL FROM is 222 DNS transactions. Since check_host() introduces macros and name expansions that combine mechanisms and modifiers in a manner not directly supported by DNS, the entire set and sequence of SPF based DNS transactions is required for each evaluation. While SPF now has a 2 limit of void lookups, use of synthetic domains has become a popular technique for tracking traffic which can be used by malefactors to overcome this SPF void lookup limit. The draft agenda for the IETF 83 session was posted to the SPFBIS mailing list on March 14, 2012. One of the items on that agenda was DNS amplification attacks ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01021.html ). It would have been good more discussion of the issue (Issue #24) from a DNS perspective. As there has been numerous comments about the DNS angle during this Last Call, maybe an IETF participant will be able to provide some input about the above. Once DNSsec becomes a requirement, SPF will have created an inordinate number of transactions and overall traffic per message exchange that will impose a SIGNIFICANT reflected amplification risk. draft-ietf-spfbis-4408bis-19 does not have any DNSSEC requirement. '--- Related information: random-stringcdr-ds.metric.gstatic.com random-string.g.vm.akamaistream.net are domains on sizable networks that act as a wildcards. In the second instance, the wildcard points to a CNAME that then resolves an A record. Such
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
On 08/22/2013 07:18 PM, John Levine wrote: In article 5215cd8d.3080...@sidn.nl you write: 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? SPF is ten years old now. It would be helpful if you could give us a list of other protocols that have had a similar issue with a TXT record at the apex during the past decade. I don't know of any (at least ones that are used in the global dns namespace), and I would like to still not know of any in 2033. SPF may be a lost cause, let's try and make that the only one. Jelte
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
SPF is ten years old now. It would be helpful if you could give us a list of other protocols that have had a similar issue with a TXT record at the apex during the past decade. I don't know of any (at least ones that are used in the global dns namespace), and I would like to still not know of any in 2033. SPF may be a lost cause, let's try and make that the only one. Since we agree that the issue you're worried about has not arisen even once in the past decade, could you clarify what problem needs to be solved here? R's, John
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
Hello, This message has a Bcc to an IETF participant. In my write-up for the Responsible Area Director I mentioned that: There was an intermediate conclusion about the topic of whether the SPF protocol should use the SPF RRTYPE or the TXT resource record. It was followed by an objection. After discussion of the topic at the IETF 83 SPFBIS WG session the conclusion reached was that the decision would be not to publish RRTYPE 99 and and not to query RRTYPE 99. The WG consensus about the RRTYPE can be described as particularly rough. The topic of obsoleting the SPF RRTYPE generated a lot of controversy near the end of the WGLC. There were a very high number of messages about the topic on the SPFBIS mailing list and the DNSEXT mailing list as some DNSEXT WG participants were not aware of RFC 6686. The WGLC announcement [1] for draft-ietf-spfbis-4408bis-14 was sent on April 9, 2013 and it was mentioned that the WGLC will close on April 24. I posted my review as document shepherd on April 23 [2] and looked into the IANA Considerations Section of the draft as there is a question in the write-up about whether the IANA Considerations are clear and complete. Something unusual occurred. A very high number of messages were posted about on a thread about the DNS Parameters registry [3]. Most of the comments were submitted after the end of the WGLC. On April 25, the Responsible Area Director [4] commented that: This discussion should have happened at SPFBIS *chartering* time, as it is crystal clear from the charter that existing features currently in use in SPF are not going away. Indeed, the TXT record was specifically mentioned in the charter. In another message he commented [5] that: If you think SPFBIS was being superficial in its treatment of this topic and can identify an argument that was missed, fine. The thread was left to run in case an argument was missed. The SPFBIS WG Chairs [6] posted a message on April 30 about the planned deprecation of the SPF RRTYPE and whether TXT is an appropriate thing to use and if it is whether the SPF use of it is ok. There is the following text in the write-up: Some WG participants have mentioned that they may express extreme discontent about the decision to obsolete the SPF RRTYPE during the Last Call. That is a notification to the Responsible Area Director and the other members of the IESG about the matter. I reviewed the discussion about the RRTYPE several times in doing the write-up and after that to determine whether the following is correct: The WG consensus about the RRTYPE can be described as particularly rough. I did not find any problem in the process followed to reach that conclusion. I read the messages posted on the IETF mailing list [7]; there are around a 100 messages. I didn't notice any messages about an issue with the above statement. Regards, S. Moonesamy (as document shepherd) 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg03347.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg03414.html 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg03412.html 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg03497.html 5. http://www.ietf.org/mail-archive/web/spfbis/current/msg03507.html 6. http://www.ietf.org/mail-archive/web/spfbis/current/msg03681.html 7. http://www.ietf.org/mail-archive/web/ietf/current/msg81609.html
Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
The SPFbis document improperly conflates DNS terminology with identical terms invented by this document. Examples are terms used to describe mechanisms having the same identifier differentiated between mechanisms and DNS resource records by using lower and upper case respectively. References to SPF records are differentiated by a textual prefix and not by TYPE as defined by DNS. In addition, the MARID WG NEVER reached consensus. A follow-on group operating outside of the IETF required a promise of support to subscribe to their mailing list. When one looks at how SPF is commonly used, the pre-existing APL resource record offered an effective alternative, but was oppose by a particular vendor unwilling to fully implement DNS. Currently this vendor is seldom used to directly interface with MTAs on the Internet and no longer justifies the use of the TXT records. As such, the SPF Resource Record should not have been deprecated. This draft should be made Informational and not Standards Track. Section 4.6.4 fails to offer a sufficiently clear warning about potential magnitudes of DNS transactions initiated by a single SPF evaluation where two are recommended to occur one for the separate identifiers. In fact, this section appears to make assurances no more that 10 DNS queries will result and is widely misunderstood. 4.6.4. DNS Lookup Limits Was: ,-- SPF implementations MUST limit the total number of mechanisms and modifiers (terms) that cause any DNS query to 10 during SPF evaluation. '-- Change to: ,--- SPF evaluation must limit the number of mechanisms, and the modifier term 'redirect' to occur in no more than10 instances within the evaluation process. The mechanisms 'ip4', ip6', and 'all' are excluded from this instance limitation. Each mechanism is permitted to resolve subsequent resource record sets (RRsets) that MUST not contain more than 10 resource records to complete a match check. When the number of instances exceeds 10, or when subsequent resolutions exceeds 10, check_host() MUST produce a “permerror” result. The maximum number of DNS transactions initiated by an SPF evaluation is therefore 1 for the initial SPF resource record, 10 for each mechanism times 10 transactions needed to complete a matching process for a total of 111 DNS transactions. This number excludes those required by DNS to fulfill a request and those required by an EXP modifier. The recommended 20 second evaluation timeout imposes a maximum network distance of less than 27,000 kilometers or a little more than half the circumference of the Earth. Even a 60 millisecond delay can result in more than a 6.6 seconds consumed by the round trip overhead needed for each SPF evaluation. The overall resulting maximum number of DNS transactions for both HELO and MAIL FROM is 222 DNS transactions. Since check_host() introduces macros and name expansions that combine mechanisms and modifiers in a manner not directly supported by DNS, the entire set and sequence of SPF based DNS transactions is required for each evaluation. While SPF now has a 2 limit of void lookups, use of synthetic domains has become a popular technique for tracking traffic which can be used by malefactors to overcome this SPF void lookup limit. Once DNSsec becomes a requirement, SPF will have created an inordinate number of transactions and overall traffic per message exchange that will impose a SIGNIFICANT reflected amplification risk. '--- Related information: random-stringcdr-ds.metric.gstatic.com random-string.g.vm.akamaistream.net are domains on sizable networks that act as a wildcards. In the second instance, the wildcard points to a CNAME that then resolves an A record. Such use compared against http://tools.ietf.org/html/draft-otis-spf-dos-exploit-01 produces a much larger amplification than the x320 gain estimated. Use of DNSsec further increases this gain estimate. Although details differ from case to case, the synthetic domain technique is seeing greater use. One of the initial reasons for using TXT records without any prefix was to permit use of wildcards. This dangerous feature means SPF allows malefactors to leverage any large TXT resource record that otherwise would not have been problematic. Again this risk increases when DNSsec becomes required and represents another reason for not deprecating the SPF resource record type. Remove this misleading paragraph within section 4.6.4: ,--- When evaluating the mx mechanism, the number of MX resource records queried is included in the overall limit of 10 mechanisms/ modifiers that cause DNS lookups described above. The evaluation of each MX record MUST NOT result in querying more than 10 address records, either A or resource records. If this limit is exceeded, the mx mechanism MUST produce a permerror result. '--- MX resource records do not contain IP addresses. Per RFC1035 the structure for an MX record is roughly as follows: A 16 bit PREFERENCE
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
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: Thu, Aug 22, 2013 at 12:23:56AM -0400 Quoting Scott Kitterman (scott@kitterma On Thursday, August 22, 2013 00:26:35 Måns Nilsson wrote: ... SPF is a flagship case for the use a TXT record and continue to IPO fast and sloppy crowd. It needs correcting. Badly. Which IPO was that? BTW, in 2003 the choice was use TXT or nothing. So it was a crowd that wanted to accomplish something and did it the only way it was possible. Considering use of TXT wasn't an important factor in the DKIM last call, I conclude that this isn't really about using TXT. It indeed is -- but SPF is as I wrote above a flagship case. SPF was the first, is the most deployed (as its supporters repeatedly assert, wringing their hands, trying to sound apologetical and/or defaîtistic) case of tragedy in the commons that is automated data processing of content in comments and when its proponents try to codify the behaviour of stampeding into the commons by removing the SPF rrtype, enough is enough. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Are we THERE yet? signature.asc Description: Digital signature
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
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? 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
Re: Rude responses (Was: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)
On 8/21/13 4:40 PM, Dave Crocker wrote: On 8/21/2013 12:46 PM, Pete Resnick wrote: It is not your complaint about the imposition of new requirements that is problematic, or your point that it is not useful to continue that line of discussion. Talk about the utility of a comment all that you want. It is the sarcasm and the rudeness that I am saying is unreasonable. Especially coming from a senior member of the community, OK. No sarcasm in IETF postings. Good luck with that. Luckily, again, that's not what I said or intended. Some evidence to the contrary, the IETF is a human endeavor. It involves interactions among people. So there will be sarcasm, and humor, and loss of temper, and comments with all sorts of embedded meanings. Sometimes these things lighten the mood, make the conversation more interesting, cause people to think about things in different ways, and contribute to the interaction. Sometimes they can have seriously problematic effects. Sometimes it will be unclear. And, even though some of our ranks appear to want it to be otherwise, there are no nice engineering specs for this. It's all very contextual, and is going to depend on the speakers and the listeners and the topic of conversation. Social interactions are complicated that way. But there is something going on in the present thread, and in particular the mode of communication I objected to here, that I think warrants pushback: More seriously... You might have noticed that there have been a variety of folk making unrealistic or misguided suggestions and that they have been receiving entirely muted and exploratory -- albeit negative -- responses. The implication that I think you've missed here is the obligation that should hold for a 'senior' participant who is lodging concerns. The current thread is being tenaciously pursued by another senior member and former AD and the line of objections and requirements being put forward are studiously ignoring the considerable efforts of the working group and the considerable practical field history. As such, they represent their own form of disrespect. I used the word bullying with regard to your particular message for a very specific reason. Bullying is normally using one's position of power to intimidate. I want to circle back a bit to the particulars of the SPF discussion: The SPFBIS WG came to the conclusion regarding deprecating the use of RR 99 through a very long discussion. There was an extensive review of data. (Indeed, there was some initial reluctance in the WG to do as much research into the numbers as was eventually done, and I think in the end everyone was glad that the WG did do as much work as it did on the topic.) There was an extensive discussion of the implications of all of the choices. And, with some rough edges, the WG pretty solidly convinced itself that it had chosen the right path. And not just that: The WG convinced both chairs that they had chosen the right path (one of the chairs being the chair of DNSEXT). And they convinced the responsible AD. And during WGLC they even convinced the responsible AD for DNSEXT, who was originally quite opposed, that the decision was well-considered and the correct one in the end. And I believe none of these folks were convinced because opposing views were kicked out of the conversation; data was presented and explanations were made, and they were convinced. Solid consensus was reached, such that as the eventual consensus caller, I am quite sure that I'm going to have to see a very carefully reasoned new argument in order for me to think that something was missed by this WG. Anyone currently outside of the consensus has a pretty high bar to clear; they are at a significant disadvantage in the conversation if they have an important point to make. So, now at the point of IETF LC, the correct thing to happen is to let folks make their objections, point them to places in the prior conversation where the WG, the chairs, the ADs, and assorted other folks became convinced, and see if their arguments have some new subtlety that was missed earlier. And try to explain. Remember, these folks are already at a disadvantage; they've got an uphill climb to convince anyone else (especially, me and the rest of the IESG) that this long-considered conclusion is incorrect. IMO, that's the time to cut them as much slack as possible, because if they do have a serious objection hidden in among things that we've seen before, we *all* should want to hear it. But that's not what's gone on. Some folks have simply dismissively said, Go read the archive, without pointers. I found that less-than-collegial, and the more dismissive folks I dropped a private note asking them to cool it. The dismissiveness AFAICT simply encourages people to post more comments without looking at the previous conversation. But your note went above and beyond. The sarcasm was sharp and directed. It seemed
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
On Aug 22, 2013, at 4:36 AM, Jelte Jansen jelte.jan...@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
Re: Rude responses (Was: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)
On Thu, Aug 22, 2013 at 10:22 AM, Pete Resnick presn...@qti.qualcomm.comwrote: Some folks have simply dismissively said, Go read the archive, without pointers. Pete, I like your position, but I believe go read the archive or the equivalent will continue to be a standard response unless someone is responsible for giving a more thorough response. Who do you think that should be?
Re: Rude responses (Was: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)
Barry Leiba barryle...@computer.org writes: The general point is that the new people whom we want to draw in as productive participants will be watching how we treat each other and deciding whether they want to wade into that pool. It's not just new people watching and being turned off. There are plenty of old timers who get turned off and I doubt I'm alone in thinking very carefully these days whether I want to wade into any particular discussion. Thomas
Re: Rude responses (Was: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)
OK, direct question; I'll take the (short) time to give a direct answer. On 8/22/13 9:53 AM, Scott Brim wrote: Pete, I like your position, but I believe go read the archive or the equivalent will continue to be a standard response unless someone is responsible for giving a more thorough response. Who do you think that should be? It would be a bummer if it is entirely left to the AD/consensus caller or the chair/shepherd, but unfortunately the buck stops here, as they say. Eventually, it should be everyone's responsibility to help their colleagues. But obviously my rose-colored glasses are especially rosy today, other evidence to the contrary notwithstanding. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478
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
On Thu, Aug 22, 2013 at 1:36 AM, Jelte Jansen jelte.jan...@sidn.nl wrote: 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. With or without SPF, we're long past the point where worrying about that is worthwhile. Try a TXT lookup for ut.edu or banctec.com, for example. When I did one of the surveys for RFC6686, it recorded the TXT RRs returned for various domain queries. The top ten in terms of record counts returned back then (most have been cleaned up now): +---+--+ | count(id) | domain | +---+--+ |43 | wncy.com | |43 | b93radio.com | |43 | wtaq.com | |29 | dealdirectsendz.info | |23 | voamn.org| |18 | ut.edu | |15 | aaronline.com| |10 | dwgsecurity.com | | 9 | emergogroup.com | | 9 | banctec.com | +---+--+ The top three were loaded with google-site-verification=hash records. ut.edu and banctec.com have a mix of things. -MSK
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
In article 5215cd8d.3080...@sidn.nl you write: 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? SPF is ten years old now. It would be helpful if you could give us a list of other protocols that have had a similar issue with a TXT record at the apex during the past decade. R's, John
Re: Rude responses (Was: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)
Pete, I like your position, but I believe go read the archive or the equivalent will continue to be a standard response unless someone is responsible for giving a more thorough response. Who do you think that should be? If you've had the most fleeting look at this: https://datatracker.ietf.org/doc/draft-leiba-extended-doc-shepherd/ ... then you'll know what *my* answer to that question is. Happily, this document has an excellent shepherd (see the Most Excellent(tm) shepherd report: https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/shepherdwriteup/ ), who has been posting summaries and pointers throughout the conversation. Perhaps said shepherd could give even better pointers; if so, a quiet message to him asking for specifics would surely be met with cheerful diligence. Barry
RE: Rude responses (Was: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)
I can't myself think of a good justification for sarcasm, (well, maybe [1]:-) good sarcasm is like good protocol design - many can recognise it, some can appreciate it, few can truly understand its nuances, and even fewer can create it. You're just not one of them. Lloyd Wood http://sat-net.com/L.Wood/
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
On Aug 20, 2013, at 9:00 PM, Andrew Sullivan a...@anvilwalrusden.com wrote: The WG had a hard time coming up with really good data about what validators look for, ... If someone else with some busy nameservers wants to provide different evidence now, it wouldn't hurt. Out of morbid curiosity, I just looked at the logs from my name server (which has both TXT and SPF RRs but which is very, very far from being busy) with a quick perl hack: 2011/07/30 08:07:51 spf: 2, txt: 1, 200.00% 2011/08/10 21:28:41 spf: 4, txt: 121, 3.305785% 2011/08/14 21:30:11 spf: 1, txt: 45, 2.22% 2011/08/16 17:20:40 spf: 0, txt: 5, 0.00% 2011/08/17 00:53:42 spf: 1, txt: 1, 100.00% 2011/08/19 01:10:53 spf: 0, txt: 6, 0.00% 2011/08/21 03:09:09 spf: 27, txt: 45, 60.00% 2011/09/13 04:25:21 spf: 30, txt: 113, 26.548673% 2011/09/15 16:19:41 spf: 3, txt: 16, 18.75% 2011/09/15 17:16:35 spf: 0, txt: 3, 0.00% 2011/09/22 18:35:07 spf: 6, txt: 22, 27.272727% 2011/09/26 19:08:48 spf: 0, txt: 7, 0.00% 2011/09/30 01:02:42 spf: 1, txt: 7, 14.285714% 2011/10/10 03:53:19 spf: 42, txt: 157, 26.751592% 2011/10/20 00:39:06 spf: 2, txt: 14, 14.285714% 2011/10/31 19:08:55 spf: 5, txt: 141, 3.546099% 2011/11/02 20:37:05 spf: 0, txt: 16, 0.00% 2011/11/15 17:15:38 spf: 8, txt: 196, 4.081633% 2011/11/30 19:04:48 spf: 47, txt: 335, 14.029851% 2011/12/12 22:18:55 spf: 1, txt: 294, 0.340136% 2011/12/25 16:04:50 spf: 16, txt: 611, 2.618658% 2011/12/29 17:58:19 spf: 1, txt: 2, 50.00% 2012/01/12 01:15:17 spf: 2, txt: 52, 3.846154% 2012/01/18 22:24:14 spf: 0, txt: 60, 0.00% 2012/01/30 00:45:27 spf: 2, txt: 121, 1.652893% 2012/02/02 17:18:54 spf: 54, txt: 288, 18.75% 2012/02/10 23:59:02 spf: 0, txt: 102, 0.00% 2012/02/23 00:52:47 spf: 20, txt: 201, 9.950249% 2012/03/19 03:17:46 spf: 118, txt: 580, 20.344828% 2012/03/24 18:33:15 spf: 2, txt: 46, 4.347826% 2012/04/13 16:41:10 spf: 121, txt: 1743, 6.942054% 2012/05/19 18:20:14 spf: 54, txt: 631, 8.557845% 2012/06/07 13:52:26 spf: 82, txt: 961, 8.532778% 2012/07/05 02:48:39 spf: 26, txt: 339, 7.669617% 2012/07/05 18:24:30 spf: 0, txt: 4, 0.00% 2012/07/07 19:21:02 spf: 3, txt: 25, 12.00% 2012/07/17 14:48:32 spf: 3, txt: 156, 1.923077% 2012/08/07 18:19:36 spf: 7, txt: 269, 2.602230% 2012/08/19 04:38:08 spf: 23, txt: 198, 11.616162% 2012/08/31 21:23:20 spf: 27, txt: 190, 14.210526% 2012/10/21 07:45:13 spf: 185, txt: 1285, 14.396887% 2012/12/07 21:59:04 spf: 74, txt: 704, 10.511364% 2012/12/11 18:28:28 spf: 0, txt: 24, 0.00% 2012/12/31 07:51:05 spf: 52, txt: 436, 11.926606% 2013/01/08 00:30:31 spf: 10, txt: 119, 8.403361% 2013/02/02 01:30:47 spf: 22, txt: 341, 6.451613% 2013/02/16 06:44:53 spf: 20, txt: 143, 13.986014% 2013/02/28 01:58:33 spf: 11, txt: 153, 7.189542% 2013/03/05 02:38:51 spf: 5, txt: 75, 6.67% 2013/03/08 23:47:17 spf: 0, txt: 99, 0.00% 2013/03/09 02:21:46 spf: 1, txt: 1, 100.00% 2013/03/20 01:29:03 spf: 46, txt: 1232, 3.733766% 2013/03/24 06:22:59 spf: 15, txt: 212, 7.075472% 2013/03/26 06:03:50 spf: 0, txt: 11, 0.00% 2013/03/31 23:17:16 spf: 8, txt: 208, 3.846154% 2013/04/06 05:19:48 spf: 37, txt: 587, 6.303237% 2013/04/07 21:53:19 spf: 1, txt: 37, 2.702703% 2013/04/16 18:50:43 spf: 13, txt: 279, 4.659498% 2013/04/22 05:52:43 spf: 3, txt: 163, 1.840491% 2013/04/29 17:56:04 spf: 14, txt: 440, 3.181818% 2013/05/22 16:26:40 spf: 20, txt: 606, 3.300330% 2013/05/23 12:08:25 spf: 1, txt: 9, 11.11% 2013/05/23 12:30:12 spf: 0, txt: 1, 0.00% 2013/05/28 19:14:02 spf: 21, txt: 380, 5.526316% 2013/07/01 02:29:15 spf: 51, txt: 2246, 2.270703% 2013/07/01 15:02:05 spf: 2, txt: 16, 12.50% 2013/07/07 04:50:19 spf: 0, txt: 109, 0.00% 2013/07/24 01:09:39 spf: 36, txt: 1395, 2.580645% totals: spf: 1389, txt: 19435, 7.146900% (the numbers are queries since the name server last restarted/dumped stats) Will look for better data than my measly little name server. Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail
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
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: Tue, Aug 20, 2013 at 10:30:41AM -0700 Quoting S Moonesamy (sm+ietf@elandsys.c My reading of the SPFBIS Charter is that the working group was not tasked to work on the future of DNS servers. That does not mean that arguments about the future of DNS servers are not relevant. The codification of a pessimistic view of the ability of the DNS installed base to adapt to new RRtypes is - in itself - a statement that influences the future of DNS. That this was not completely understood in terms of influence weight is one of the reasons for this debate. There are several questions: (a) Was there an error in RFC 4408? Yes. (b) What was the error in RFC 4408? The TXT rrtype was not properly decommissioned; it lacked definitiveness, and neither publication instructions nor selection/query algorithm satisfy this (originally intended, I suppose and believe) sunset view of the TXT record rôle vis à vis SPF. (c) Why was there an error in RFC 4408? (d) What should be done about the error? 4408bis needs a better defined depreciation statement for TXT, accompanied by publication and query methods that will ensure the continous phasing-out of SPF data in TXT records. A clarification here will help in making DNS UI vendors doing the right thing. I'm quite confident that presently, the UI vendors sleep soundly after reading 4408 and continuing to ignore SPF/99. That is not desirable. There isn't anything that can be done about question (c) except not to repeat the same mistake. Is there disagreement on the answers to questions (a) and (b)? Apparently. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I'm using my X-RAY VISION to obtain a rare glimpse of the INNER WORKINGS of this POTATO!! signature.asc Description: Digital signature
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
On 21 aug 2013, at 09:17, David Conrad d...@virtualized.org wrote: On Aug 20, 2013, at 9:00 PM, Andrew Sullivan a...@anvilwalrusden.com wrote: The WG had a hard time coming up with really good data about what validators look for, ... If someone else with some busy nameservers wants to provide different evidence now, it wouldn't hurt. Out of morbid curiosity, I just looked at the logs from my name server (which has both TXT and SPF RRs but which is very, very far from being busy) with a quick perl hack: : : : totals: spf: 1389, txt: 19435, 7.146900% (the numbers are queries since the name server last restarted/dumped stats) Will look for better data than my measly little name server. I have been looking at the queries to one of the nameservers that Frobbit runs (which is authoritative for quite a number of zones, although not GoDaddy), and a tcpdump for a while today gives the following data: $ /usr/sbin/tcpdump -nr dns.pcap | grep 'SPF?' | wc -l reading from file dns.pcap, link-type EN10MB (Ethernet) tcpdump: pcap_loop: truncated dump file; tried to read 271 captured bytes, only got 95 1105 $ /usr/sbin/tcpdump -nr dns.pcap | grep 'TXT?' | wc -l reading from file dns.pcap, link-type EN10MB (Ethernet) tcpdump: pcap_loop: truncated dump file; tried to read 94 captured bytes, only got 18 2819 I.e. 2819 queries for TXT while there was 1105 for SPF resource record. Now, I have no idea whether all of those queries for TXT was only for the SPF usage of TXT of course, but this gives it was at least 28% of (TXT+SPF)-queries that was for SPF. Deprecating something that is in use that much just does not make any sense. Patrik signature.asc Description: Message signed with OpenPGP using GPGMail
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
Patrik, First, I appreciate that you and Dave are bringing data to the table. However, in this case, it is not in dispute that queries are happening. What *is* in dispute is whether there are answers. I must admit I am having a difficult time understanding the logic, even so. The *hard* part about this was supposed to be implementation of the record in the application software. Can the shepherd answer this question: * To what extent has that happened? The easy part was supposed to be people actually using the SPF record, once it was out there. And so your data doesn't indicate what sort of answers you're getting. And another thing. Randy, is it your position that WGs shouldn't create new TXT records due to transition issues? Eliot On 8/21/13 12:15 PM, Patrik Fältström wrote: On 21 aug 2013, at 09:17, David Conrad d...@virtualized.org wrote: On Aug 20, 2013, at 9:00 PM, Andrew Sullivan a...@anvilwalrusden.com wrote: The WG had a hard time coming up with really good data about what validators look for, ... If someone else with some busy nameservers wants to provide different evidence now, it wouldn't hurt. Out of morbid curiosity, I just looked at the logs from my name server (which has both TXT and SPF RRs but which is very, very far from being busy) with a quick perl hack: : : : totals: spf: 1389, txt: 19435, 7.146900% (the numbers are queries since the name server last restarted/dumped stats) Will look for better data than my measly little name server. I have been looking at the queries to one of the nameservers that Frobbit runs (which is authoritative for quite a number of zones, although not GoDaddy), and a tcpdump for a while today gives the following data: $ /usr/sbin/tcpdump -nr dns.pcap | grep 'SPF?' | wc -l reading from file dns.pcap, link-type EN10MB (Ethernet) tcpdump: pcap_loop: truncated dump file; tried to read 271 captured bytes, only got 95 1105 $ /usr/sbin/tcpdump -nr dns.pcap | grep 'TXT?' | wc -l reading from file dns.pcap, link-type EN10MB (Ethernet) tcpdump: pcap_loop: truncated dump file; tried to read 94 captured bytes, only got 18 2819 I.e. 2819 queries for TXT while there was 1105 for SPF resource record. Now, I have no idea whether all of those queries for TXT was only for the SPF usage of TXT of course, but this gives it was at least 28% of (TXT+SPF)-queries that was for SPF. Deprecating something that is in use that much just does not make any sense. Patrik
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
So your point is that their conclusions that nobody has the record installed is false? Eliot On 8/21/13 12:42 PM, Patrik Fältström wrote: On 21 aug 2013, at 12:26, Eliot Lear l...@cisco.com wrote: The easy part was supposed to be people actually using the SPF record, once it was out there. And so your data doesn't indicate what sort of answers you're getting. These are logs on one of my authoritative servers, and the queries you see are the queries sent _TO_ the server. So of course I also have the responses I give to the one those queries. Patrik
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
On Wednesday, August 21, 2013 12:00:56 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: Tue, Aug 20, 2013 at 10:30:41AM -0700 Quoting S Moonesamy (sm+ietf@elandsys.c My reading of the SPFBIS Charter is that the working group was not tasked to work on the future of DNS servers. That does not mean that arguments about the future of DNS servers are not relevant. The codification of a pessimistic view of the ability of the DNS installed base to adapt to new RRtypes is - in itself - a statement that influences the future of DNS. That this was not completely understood in terms of influence weight is one of the reasons for this debate. There are several questions: (a) Was there an error in RFC 4408? Yes. (b) What was the error in RFC 4408? The TXT rrtype was not properly decommissioned; it lacked definitiveness, and neither publication instructions nor selection/query algorithm satisfy this (originally intended, I suppose and believe) sunset view of the TXT record rôle vis à vis SPF. (c) Why was there an error in RFC 4408? (d) What should be done about the error? 4408bis needs a better defined depreciation statement for TXT, accompanied by publication and query methods that will ensure the continous phasing-out of SPF data in TXT records. A clarification here will help in making DNS UI vendors doing the right thing. I'm quite confident that presently, the UI vendors sleep soundly after reading 4408 and continuing to ignore SPF/99. That is not desirable. There isn't anything that can be done about question (c) except not to repeat the same mistake. Is there disagreement on the answers to questions (a) and (b)? 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. Scott K
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
I object to the removal of the SPF record. Name servers already have access controls down to the granuality of TYPE. If this draft proceeds as currently described it is forcing name server vendors to access controls at the sub TYPE granuality. With SPF lookup first I can specify the SPF policy using SPF and leave TXT free for other uses without having to worry about the records being misinterpeted. SPF validators MUST NOT proceed to a TXT lookup on SERVFAIL for SPF. This is similar to not proceeding to A/ lookups on MX lookup failures. I would also suggest that there be a sunset date published for the use of TXT for SPF. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
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
No hat On Wed, Aug 21, 2013 at 12:26:51PM +0200, Eliot Lear wrote: However, in this case, it is not in dispute that queries are happening. Actually, that _was_ in question. Remember, part of the justification for ditching TYPE99 is not only that publishers don't use it, but also that if they did there'd be no benefit. The evidence the WG produced was that there were hardly any validators querying for SPF. The WG originally had somewhat stronger claims in the draft, and I objected because I felt our sample wasn't good enough. The data that Patrik and David have presented suggest that there might indeed be more to the story, but again there are some issues with the samples. There are two additional things that would help make sense of these numbers. First, the raw number of queries isn't very interesting, if mail transactions all turn out to be with the same parties. We can't count the same party asking for TYPE99 twice as two validators. Second, how many of these TYPE99 queries arrive within the same time frame (yes, I'm waving my hands)? If the TYPE99 queries are being issued at the same time as the TXT record, that's an indication that the query source actually has no preference, and just wants the answer that comes fastest. The evidence that the WG looked at suggested that really only Yahoo preferred TYPE99, and that they stopped preferring it. There was one large mail system (I can't recall who) that sent TYPE99 queries, but actually sent both SPF and TXT at the same time in an effort to get the quickest response possible. As Scott has noted elsewhere in this thread, the SPF processing is often a blocking operation for mail systems, so latency added by two lookups in that processing is a big deal (particularly for very large systems). * To what extent has that happened? I'm not the shepherd, but it is undeniable that most current-era shipping DNS servers support RRTYPE 99. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com
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
On 08/21/2013 03:44 PM, Andrew Sullivan wrote: Speaking as the SPFBIS co-chair… On Wed, Aug 21, 2013 at 04:55:33AM -0700, manning bill wrote: to see if the trend has changed (modulo PAFs observations that not all TXT == SPF). In the mean time, declare a suspension of last call to gauge if the presumption of failure of the SPF RR merits this drastic action. I think this would have been a fair request for the LC of RFC 6686, which was presenting data about the state of the world at the time. We had a heck of a time getting people to review that document, to provide data, or to analyse the data. I think it's unfair to the WG to have refused to pitch in, and now to tell the WG that it has to sit on its hands and then do some more work later, particularly because these two data sets are hardly representative ones. If we're going to undertake a large scale data gathering experiment, I'll be all for it as soon as we have some really large mail system operators involved. (We did have those in SPFBIS, please note.) Just wondering, could OARC's recent DITL data help? (perhaps if only to see whether another large-scale targeted effort is needed) I definitely see TYPE=99 queries on our servers, but I can't see the answers. Jelte
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
On Tue 20/Aug/2013 07:27:12 +0200 David Conrad wrote: On Aug 19, 2013, at 10:14 PM, Randy Bush ra...@psg.com wrote: one lesson i might take from this is, if i want to deploy a new hack which needs an rrtype, not to use txt in the interim. Nor the same format, IMHO. My personal belief is that the rationale to migrate away from TXT remains valid and the appropriate course of action is to fix the migration strategy, not permanently encode what everyone agrees is a hack into a proposed standard. Normally, it's easier to have new births than to revive dead horses. The proposed standard is what currently works. By the time DKIM keys are transmitted in binary, SPF will have a better spec too.
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
On Aug 21, 2013, at 7:17 AM, Patrik Fältström p...@frobbit.se wrote: My conclusion is that a statement that nobody queries for it is false. I am curious if the folks who did the analysis of query rates know the answers to the following questions: 1. Per unit of mail delivered (as opposed to per domain), for what percentage of delivered mail for which SPF TXT records exist do SPF RRtype records _also_ exist? I wasn't clear on whether an attempt was made to come up with an answer to this question. 2. Per unit of mail received, for what percentage of received mail does the receiver currently issue SPF RRtype queries. The reason I ask these questions is that the rationale for the decision made by the working group was that the data supported it, and I think that was a good rationale, but only if the data _actually_ supports it. But I don't think that the data was analyzed on the basis of units of mail delivered, but rather on the basis of number of queries seen. The reason I think the distinction is important is that as several people have observed, there are some heavy hitters in this discussion—Yahoo and Google, for example. If the heavy hitters all already publish the SPF RRtype, that might make a difference. Actually, I just checked. Right now, none of them seem to publish SPF RRtype records. Yahoo doesn't even publish a TXT record containing SPF information. An argument could be made that if we really wanted to push the adoption of SPF RRtypes, getting Google, Yahoo and Hotmail to publish SPF RRtype records would actually make it worthwhile to query SPF first, because most queries probably go to those domains. I think the people who are pushing for a different outcome than the spfbis working group arrived at would do a lot to make their case if they could use their collective influence to get these three domain owners to publish SPF RRtype records. This is a really easy thing to do; if it can't be done, that's a pretty clear indication that the SPF RRtype is doomed.
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
On Wednesday, August 21, 2013 09:39:28 Andrew Sullivan wrote: ... * To what extent has that happened? I'm not the shepherd, but it is undeniable that most current-era shipping DNS servers support RRTYPE 99. The operational issues I've encountered with actually trying to use RRTYPE99 in the wild weren't caused by a lack of support in current-era shipping DNS servers. Sometimes it's not even anything directly related to the DNS. I recall cases where it appeared that firewalls were the root of the problem (I don't recall details, sorry). Solving the DNS servers must support unknown RRTYPE/SPF type problem only gets you started. Scott K
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
On Wednesday, August 21, 2013 23:32:33 Mark Andrews wrote: I object to the removal of the SPF record. This is not a shock. You were in the rough when we discussed it in the WG too. Name servers already have access controls down to the granuality of TYPE. If this draft proceeds as currently described it is forcing name server vendors to access controls at the sub TYPE granuality. It's primarily an issue for applications. To the DNS, it's exactly what it is, a TXT record. With SPF lookup first I can specify the SPF policy using SPF and leave TXT free for other uses without having to worry about the records being misinterpeted. Unless you have some specific reason to be concerned about accidentally starting an unrelated TXT record with v=spf1 , I can't imagine you don't have more important things to worry about. This being a problem is a great theory, but it just doesn't happen in practice. SPF validators MUST NOT proceed to a TXT lookup on SERVFAIL for SPF. This is similar to not proceeding to A/ lookups on MX lookup failures. Except that it's quite common for a SERVFAIL on TYPESPF to occur for a domain that has an actual SPF record due to various operational issues. SERVFAIL on type SPF doesn't reliably tell you anything about what a type TXT lookup would produce. So it's similar, but only superficially so. I would also suggest that there be a sunset date published for the use of TXT for SPF. Do you also suggest creation of an Internet police force to enforce this? What would be be mandatory minimum sentence? Scott K
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
Eliot Lear wrote: Patrik, First, I appreciate that you and Dave are bringing data to the table. However, in this case, it is not in dispute that queries are happening. What *is* in dispute is whether there are answers. I must admit I am having a difficult time understanding the logic, even so. The *hard* part about this was supposed to be implementation of the record in the application software. Can the shepherd answer this question: * To what extent has that happened? The easy part was supposed to be people actually using the SPF record, once it was out there. And so your data doesn't indicate what sort of answers you're getting. Eliot, we will add SPF type support in our implementation once the infrastructure is ready. For us, as a windows shop, namely Microsoft DNS servers. So the better question I believe would be: If the DNS servers begin to support RFC 3597, would you add or enable SPF type99 support? Would you support new RR types based on this support presumption? Of course, the existing base would be low or marginal simply because for optimization and lower overhead reasons, it was not added or disabled in existing packages. But I believe the interest was and still is there to support in general new RR types once the infrastructure is ready, especially in the DNS community. The question to ask is if it is reasonable to believe DNS servers will be improved to support this industry desire or need. If not, then its reasonable to remove SPF type in RFC 4408bis, and for that matter, forget about all future new RR type proposals. TXT will be the fast entry record of choice. All recent mail related DNS protocols have been TXT, including the new DMARC and I don't see that changing (the same folks are producing them). -- HLS
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
At 04:55 21-08-2013, manning bill wrote: regarding adoption it would be interesting to take a second snapshot from each of these servers in about six months to see if the trend has changed (modulo PAFs observations that not all TXT == SPF). In the mean time, declare a suspension of last call to gauge if the presumption of failure of the SPF RR merits this drastic action. The IETF chartered the SPFBIS WG to deliver: (i) A document describing the SPF/Sender-ID experiment and its conclusions to the IESG for publication. (ii) A standards track document defining SPF, based on RFC4408 and as amended above, to the IESG for publication. There is a message from the Responsible Area Director ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00331.html ) and the SPFBIS Chairs ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00355.html ) about (i). The SPFBIS WG was asked to make a good-faith effort and that is what the working group did. The editor of RFC 6686 did a good job. The IESG approved the publication of the draft. The working group worked on its second deliverable (ii) after that. There wasn't any concern about the TXT RR as the matter was considered as resolved in RFC 6686. I asked DNSEXT about the SPF RRTYPE in the (IANA) DNS Parameters registry ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03412.html ). It generated long threads on several IETF mailing lists. It was unusual to have that amount of comments after the end of a WGLC. Suspending the Last Call for six months is a drastic action. I would ask the Responsible Area Director to consider that if the SPFBIS WG did not make a good-faith effort or if there is an issue with the process that was followed. My opinion is that the SPFBIS WG made a good-faith effort. There are at least three Area Directors reading the SPFBIS mailing list. They did not flag any process-related issue. At 07:03 21-08-2013, Jelte Jansen wrote: Just wondering, could OARC's recent DITL data help? (perhaps if only to see whether another large-scale targeted effort is needed) Yes. Someone also has to do the work. Regards, S. Moonesamy (as document shepherd)
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
Patrik, On 8/21/2013 7:17 AM, Patrik Fältström wrote: My conclusion is that a statement that nobody queries for it is false. Assuming that your conclusion is based on pragmatics and not mathematical purity -- that is, that it is concerned with significant operational effort, rather than a stray implementation here or there, which counts as noise in any legitimate statistical analysis -- what is the basis for your conclusion? In other words, please explain how your objection is based on real-world utility rather than something more abstract and detached from practical operations. From your posting to the dnsext working group: On 8/20/2013 11:58 AM, Patrik Fältström wrote: In general I do believe, for example when looking at IPv6 and DNSSEC and similar technologies, that the lifetime of RFC 4408 is too short to deprecate any of the proposed records that are in use, specifically as RFC 4408 explicitly do allow use of both. On its face, this sort of thinking means that, in practical terms, nothing can ever be deprecated. It also requires a rather willful ignorance of the essential community operations differences between SPF and IPv6 and DNSSec. There is massive effort to increase use of the latter. There is massive apathy about the former. That is, the metric of essentially no adoption or use is matched by no vector of change. So if you really insist on pursuing your objection, please find some arguments that are anchored in relevant, real-world analytic legitimacy. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
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
On 21 aug 2013, at 19:31, Dave Crocker d...@dcrocker.net wrote: Assuming that your conclusion is based on pragmatics and not mathematical purity -- that is, that it is concerned with significant operational effort, rather than a stray implementation here or there, which counts as noise in any legitimate statistical analysis -- what is the basis for your conclusion? As I did show, the numbers comes directly from tcpdump on my auth DNS server, where I checked how many do query for TXT and SPF(*). I do not understand the question. What else do you want? As a few others have said, 4408 do have an error that makes it impossible to use RFC 4408 for migration from TXT to SPF which was the original intent. I do not understand how the conclusion, given the number of SPF queries that is made, on how to fix the problem with RFC 4408 is to deprecate the SPF RRtype. And to your question on deprecation, yes, to me one do need much more arguments to deprecate something. Specifically when originally the intent was to migrate to what is now to be deprecated. And this is why I am objecting to 4408bis to be published as an RFC. If you had an RFC without issues that really did talk about a migration strategy (including having examples using SPF records and not TXT which one should migrate from) and still people did not migrate, then we would have a different discussion. But we are not there. A proper migration strategy to SPF has not been published. Patrik (*) I have now removed TXT version of the SPF record for frobbit.se to see whether the number of queries for SPF RRType go up or not.
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
On 8/21/2013 11:13 AM, Patrik Fältström wrote: But we are not there. A proper migration strategy to SPF has not been published. Oh. Now I understand. You are trying to impose new requirements on the original work, many years after the IETF approved it. Thanks. Very helpful. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
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
On Aug 19, 2013, at 5:41 PM, Andrew Sullivan a...@anvilwalrusden.com wrote: I'm not going to copy the spfbis WG list on this, because this is part of the IETF last call. No hat. On Mon, Aug 19, 2013 at 02:04:10PM -0700, Murray S. Kucherawy wrote: On Mon, Aug 19, 2013 at 1:59 PM, Dave Crocker d...@dcrocker.net wrote: From earlier exchanges about this concern, the assertion that I recall is that 7 years is not long enough, to determine whether a feature will be adopted. What is the premise for seven years being not long enough? And what does constitute long enough? And upon what is that last answer based? I have two observations about this. First, EDNS0, which is of significantly greater benefit to DNS operators than the mere addition of an RRTYPE, took well over 10 years to get widespread adoption. Second, we all know where IPv6 adoption stands today, and that has certainly been around longer than 7 years. So I think it _is_ fair to say that adoption of features in core infrastructure takes a very long time, and if one wants to add such features one has to be prepared to wait. But, second, I think all of that is irrelevant anyway. The plain fact is that, once 4408 offered more than one way to publish a record, the easiest publication approach was going to prevail. That's the approach that uses a TXT record. For the record I think SPF RRtype retirement is not in the good-idea category, but nor is it in the bad-idea category, it falls in the we need-to-do-something-that-works. 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. Olafur
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
On 21 aug 2013, at 20:29, Dave Crocker d...@dcrocker.net wrote: On 8/21/2013 11:13 AM, Patrik Fältström wrote: But we are not there. A proper migration strategy to SPF has not been published. Oh. Now I understand. You are trying to impose new requirements on the original work, many years after the IETF approved it. Thanks. Very helpful. Dave, I do not appreciate the tone of your message. I explain as part of a last call of a message to the IETF mailing list why I object to publication of an I-D as an RFC. If the IESG comes to the conclusion that the document should be published fine. If they say it should not. Fine. That is the IETF process. I should have staid on the DNS mailing list as I said originally, where I promised people I should not discuss SPF anymore on the main IETF list because I knew the pushback from you and a few others would be exactly like this. I was convinced to give my view on SPF to the IETF list so that it was known correctly to the last call process. A process I have always trusted and believed it. And still trust and still believe in. This is my last posting in this thread. Patrik
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
On Wednesday, August 21, 2013 14:44:41 Olafur Gudmundsson wrote: On Aug 19, 2013, at 5:41 PM, Andrew Sullivan a...@anvilwalrusden.com wrote: I'm not going to copy the spfbis WG list on this, because this is part of the IETF last call. No hat. On Mon, Aug 19, 2013 at 02:04:10PM -0700, Murray S. Kucherawy wrote: On Mon, Aug 19, 2013 at 1:59 PM, Dave Crocker d...@dcrocker.net wrote: From earlier exchanges about this concern, the assertion that I recall is that 7 years is not long enough, to determine whether a feature will be adopted. What is the premise for seven years being not long enough? And what does constitute long enough? And upon what is that last answer based? I have two observations about this. First, EDNS0, which is of significantly greater benefit to DNS operators than the mere addition of an RRTYPE, took well over 10 years to get widespread adoption. Second, we all know where IPv6 adoption stands today, and that has certainly been around longer than 7 years. So I think it _is_ fair to say that adoption of features in core infrastructure takes a very long time, and if one wants to add such features one has to be prepared to wait. But, second, I think all of that is irrelevant anyway. The plain fact is that, once 4408 offered more than one way to publish a record, the easiest publication approach was going to prevail. That's the approach that uses a TXT record. For the record I think SPF RRtype retirement is not in the good-idea category, but nor is it in the bad-idea category, it falls in the we need-to-do-something-that-works. 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. I'm a bit unsure that continue is the right word. DKIM moved to the TXT with underscore approach and, IIRC, never considered a new RRTYPE, nor did anyone ever suggest they should. DMARC, which has had a BoF and for which a WG is being considered will do the same (there's no variant of proposed charter text floating around that would allow them to consider otherwise). I agree with that the notion of a statement that SPF is what it is for a variety of reasons and shouldn't be considered as a precedent for the future might be a reasonable thing to add. I don't think the IETF has been very consistent about what one ought to do instead. Scott K
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
AD hat squarely on my head. On 8/21/13 1:29 PM, Dave Crocker wrote: Oh. Now I understand. You are trying to impose new requirements on the original work, many years after the IETF approved it. Thanks. Very helpful. That's not an appropriate response. It is certainly not helpful to me as the consensus caller. And it is rude. It's perfectly reasonable to say, This would constitute a new requirement and I don't think there is a good justification to pursue that line. The sarcasm is not reasonable. Please stop. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478
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
On 8/21/2013 11:58 AM, Pete Resnick wrote: AD hat squarely on my head. On 8/21/13 1:29 PM, Dave Crocker wrote: Oh. Now I understand. You are trying to impose new requirements on the original work, many years after the IETF approved it. Thanks. Very helpful. That's not an appropriate response. It is certainly not helpful to me as the consensus caller. And it is rude. Since you've made this a formal process point, I'll ask you to substantiate it carefully and also formally. The implication of your assessment is that IETF participants must not comment on the utility of comments by others. I don't recall that being a proscribed behavior, since it has nothing to do with personalities. So, please explain this in a way that does not sound like Procrustean political correctness. For the record, I entirely acknowledge that my note has an edge to it and yes, of course alternate wording was possible. However the thread is attempting to reverse extensive and careful working group effort and to ignore widely deployed and essential operational realities, including published research data. A bit of edge is warranted for such wasteful, distracting and destabilizing consumption of IETF resources. In fact an important problem with the alternate wording, such as you offered, is that it implies a possible utility in the thread that does not exist. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Rude responses (Was: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)
On 8/21/13 2:17 PM, Dave Crocker wrote: On 8/21/2013 11:58 AM, Pete Resnick wrote: AD hat squarely on my head. On 8/21/13 1:29 PM, Dave Crocker wrote: Oh. Now I understand. You are trying to impose new requirements on the original work, many years after the IETF approved it. Thanks. Very helpful. That's not an appropriate response. It is certainly not helpful to me as the consensus caller. And it is rude. Since you've made this a formal process point, I'll ask you to substantiate it carefully and also formally. The implication of your assessment is that IETF participants must not comment on the utility of comments by others. That's not what I said, and in fact if you look at the line immediately following what you quoted, you will see that I said: It's perfectly reasonable to say, This would constitute a new requirement and I don't think there is a good justification to pursue that line. It is not your complaint about the imposition of new requirements that is problematic, or your point that it is not useful to continue that line of discussion. Talk about the utility of a comment all that you want. It is the sarcasm and the rudeness that I am saying is unreasonable. Especially coming from a senior member of the community, the only purpose it seems to serve is to bully others into not participating in the conversation. If you think that the conversation has gone on too long, you're perfectly within rights to ask the manager of the thread (in this case, myself or the chairs), in public if you like, to make a call and say that the issue is closed. But again, the tactics displayed above are not professional and not reasonable rhetorical mode. I don't recall that being a proscribed behavior, since it has nothing to do with personalities. So, please explain this in a way that does not sound like Procrustean political correctness. I am not sure what the first sentence means. And I'm sorry that you believe that my stance on this is Procrustean. But the fact is that rude comments of this sort do not contribute to consensus-building in the least. For the record, I entirely acknowledge that my note has an edge to it and yes, of course alternate wording was possible. However the thread is attempting to reverse extensive and careful working group effort and to ignore widely deployed and essential operational realities, including published research data. I appreciate your input that you believe that some or all of the objectors are ignoring operational realities. Perhaps they are. But the fact is that Last Call is a time for the community to take a last look at WG output. If senior members of the community (among which there are several in this thread) are suspicious of the output, it *is* important to make sure that their concerns are addressed. Maybe they simply don't have all of the information. But maybe the WG has missed something essential in all that careful work. Both have historically happened many times. A bit of edge is warranted for such wasteful, distracting and destabilizing consumption of IETF resources. In fact an important problem with the alternate wording, such as you offered, is that it implies a possible utility in the thread that does not exist. It is far more distracting and destabilizing for the IETF to come out of a Last Call with experienced members of the community suspicious that a bad result has occurred, especially if the tactic used to end the discussion was sarcasm to chase people away from the discussion. You are looking at only the little picture. The consensus might end up on the rough side, but having the conversation has utility in and of itself. I find your edge much more disruptive to the conversation, making it much more adversarial than explanatory, and damaging the consensus that might be built. I think that lowers the utility of the output tremendously. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478
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
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. * 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. * 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 preference for SPF vs TXT that is present in 4408 is to be kept unaltered. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I'm gliding over a NUCLEAR WASTE DUMP near ATLANTA, Georgia!! signature.asc Description: Digital signature
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
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
Re: Rude responses (Was: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)
On 8/21/2013 12:46 PM, Pete Resnick wrote: It is not your complaint about the imposition of new requirements that is problematic, or your point that it is not useful to continue that line of discussion. Talk about the utility of a comment all that you want. It is the sarcasm and the rudeness that I am saying is unreasonable. Especially coming from a senior member of the community, OK. No sarcasm in IETF postings. Good luck with that. More seriously... You might have noticed that there have been a variety of folk making unrealistic or misguided suggestions and that they have been receiving entirely muted and exploratory -- albeit negative -- responses. The implication that I think you've missed here is the obligation that should hold for a 'senior' participant who is lodging concerns. The current thread is being tenaciously pursued by another senior member and former AD and the line of objections and requirements being put forward are studiously ignoring the considerable efforts of the working group and the considerable practical field history. As such, they represent their own form of disrespect. The alternative phrasing you suggest makes sense for average, random, problematic criticism. But as I indicated in the previous note, the phrasing suffers from implying a degree of legitimacy that is not warranted for this thread, from another 'senior' participant. I realize you don't agree with that view, but I'll again note that I'm not aware of any formal rule that my posting violated and certainly not any pattern of IETF practice. (Of course I can read the Code of Conduct to the contrary, but having done that, I felt that each of its relevant points had a counter in this case.) I, too, preferred a far more constructive tone to the thread, and attempted to contribute that initially. But persistent unreasonableness, when it can't be attributed to ignorance, warrants an explicit note. So I gave it. Taking this thread seriously, even to the extent of treating it with a cautiously respectful tone, encourages a persistent silliness in the IETF that is strategically destructive, because it communicates our tolerance for having experienced participants waste people's time and effort. the only purpose it seems to serve is to bully others into not participating in the conversation. You think I could bully Patrik? Good luck with that, too. If you think that the conversation has gone on too long, you're perfectly within rights to ask the manager of the thread (in this case, myself or the chairs), in public if you like, to make a call and say that the issue is closed. But again, the tactics displayed above are not professional and not reasonable rhetorical mode. The thread itself does not have a professional premise, Pete. The record needs to reflect at least one comment to that effect. I don't recall that being a proscribed behavior, since it has nothing to do with personalities. So, please explain this in a way that does not sound like Procrustean political correctness. I am not sure what the first sentence means. And I'm sorry that you believe that my stance on this is Procrustean. But the fact is that rude comments of this sort do not contribute to consensus-building in the least. The thread has its own responsibility to attempt consensus building. It wasn't doing that. In fact, in its way, it has represented a classic, continuing of bullying against DNS pragmatics. For the record, I entirely acknowledge that my note has an edge to it and yes, of course alternate wording was possible. However the thread is attempting to reverse extensive and careful working group effort and to ignore widely deployed and essential operational realities, including published research data. I appreciate your input that you believe that some or all of the objectors are ignoring operational realities. I didn't say that. This current exchange is about a specific thread. It is now your turn to be more careful in what you assert. Perhaps they are. But the fact is that Last Call is a time for the community to take a last look at WG output. If senior members of the community (among which there are several in this thread) are suspicious of the output, it *is* important to make sure that their concerns are addressed. Only after determining that their concerns are reasonable. Maybe they simply don't have all of the information. But maybe the WG has missed something essential in all that careful work. Both have historically happened many times. Again, you are missing the point that we'd already done through quite a bit of that, with no apparent effect. It is far more distracting and destabilizing for the IETF to come out of a Last Call with experienced members of the community suspicious that a bad result has occurred, As an abstraction, your point is of course entirely valid. But your premise is that a reasonable discussion is possible and that
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
In message 7917527.VmCQD3a6Q3@scott-latitude-e6320, Scott Kitterman writes:
On Wednesday, August 21, 2013 23:32:33 Mark Andrews wrote:
I object to the removal of the SPF record.
This is not a shock. You were in the rough when we discussed it in the WG
too.
Name servers already have access controls down to the granuality
of TYPE. If this draft proceeds as currently described it is forcing
name server vendors to access controls at the sub TYPE granuality.
It's primarily an issue for applications. To the DNS, it's exactly what it
is, a TXT record.
No. It isn't. By overloading TXT you prevent thing like this which
existed before SPF was even dreamed up.
update-policy {
grant key-one subdomain example.net ANY
deny key-two domain example.net SPF
grant key-two domain example.net ANY
};
or
update-policy {
grant key-one subdomain example.net ANY
grant key-two domain example.net TXT
};
Overloading a type is bad on so many levels which is why it was
argued that SPF needed its own type. TXT is good for prototyping
and that is about all.
update-policy {
grant key-one subdomain example.net ANY
deny key-two domain example.net TXT/v=spf1
grant key-two domain example.net ANY
};
update-policy {
grant key-one subdomain example.net ANY
deny key-two domain example.net TXT/v=spf1
grant key-two domain example.net TXT!v=spf1
};
With SPF lookup first I can specify the SPF policy using SPF and
leave TXT free for other uses without having to worry about the
records being misinterpeted.
Unless you have some specific reason to be concerned about accidentally
starting an unrelated TXT record with v=spf1 , I can't imagine you don't
have more important things to worry about. This being a problem is a great
theory, but it just doesn't happen in practice.
It's about being able to hand someone update control and not having to
worry about them stuffing up the SPF records.
SPF validators MUST NOT proceed to a TXT lookup on SERVFAIL for SPF.
This is similar to not proceeding to A/ lookups on MX lookup
failures.
Except that it's quite common for a SERVFAIL on TYPESPF to occur for a domain
that has an actual SPF record due to various operational issues. SERVFAIL on
type SPF doesn't reliably tell you anything about what a type TXT lookup
would
produce. So it's similar, but only superficially so.
And the worst that happens is that you let some *additional*
potentially spoofed email through. This WG seems to treat this
as a catastrophic errror when it isn't. This whole debate is
because this working group treats not stopping one additional
forgery as a catastrophic errror.
Note also that it will be the publishing site to blame for having
a non RFC 1034 compliant server (it didn't respond to SPF queries)
or misconfigured zone (returns wrong SOA in the negative response
which can't happen when they have a SPF record).
I would also suggest that there be a sunset date published for the
use of TXT for SPF.
Do you also suggest creation of an Internet police force to enforce this?
What would be be mandatory minimum sentence?
You just code the cut off date into the code that does the verification
and stop making TXT queries. You code the date into the code that
checks for missing SPF records and change the complaint.
Scott K
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Rude responses (Was: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)
In this conversation between Pete and Dave, there's one point that's come up which has come up often enough that I want to call it out separately for comment: the only purpose it seems to serve is to bully others into not participating in the conversation. You think I could bully Patrik? Good luck with that, too. Let's take this out of the context of the discussion at hand, and be more general -- because, as I said, I'm reacting not to the statement as it stands, but to how often I've seen it made (twice within the last few weeks alone). The form is this: Point: You behaved badly toward [person X]. Counterpoint: Well, [person X] has been around, he can handle it. Often, there's a further response that agrees that, indeed, [person X] can take it, so all is OK. No. All is not OK. What this argument leaves out is consideration of everyone *else* who's reading this exchange and putting themselves in the shoes of [person X]. Many of them are looking at what to expect from engaging in IETF discussions, many of them are not old-timers with thick skins and an understanding of IETF rhetoric, and many of them will be put off of participating because they see how we treat those who do participate. Again, remember: I'm not talking about this particular discussion, so let's not fixate on whether or not being abrupt, sarcastic, abusive, offensive, profane, or whatever... is appropriate for this conversation. The general point is that the new people whom we want to draw in as productive participants will be watching how we treat each other and deciding whether they want to wade into that pool. Barry
Re: Rude responses (Was: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)
On 08/21/2013 11:13 PM, Barry Leiba wrote: The general point is that the new people whom we want to draw in as productive participants will be watching how we treat each other and deciding whether they want to wade into that pool. Yes, that is a factor that merits attention. But not the only nor an always-overriding one. For example brevity matters, technical correctness wins, humour is important and can be cruel. I can't myself think of a good justification for sarcasm, (well, maybe [1]:-) but I can understand that sometimes people make mistakes. And sometimes the same people make the same mistakes many times. We're not here to make them better though. Calling 'em on it is a good way to handle it I think. Generalising to the point where we are all expected to be politically correct clones would not. (Yes, I'm exaggerating what you're saying there:-) S. [1] https://en.wikipedia.org/wiki/List_of_Father_Ted_characters and search for sarcastic:-)
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
In message 20130821214832.1c92538c0...@drugs.dv.isc.org, Mark Andrews writes: It's primarily an issue for applications. To the DNS, it's exactly what it is, a TXT record. I can hand update of A and records to the machine. I can hand update of MX records to the mail adminstrator. I can hand update of SPF records to the mail adminstrator. I can hand update of TXT records to ?? -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
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
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 04:52:59PM -0400 Quoting Scott Kitterman (scott@kitterma 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. As I'm thinking about migration here, let's be generous. Allow publication of TXT too, even if SPF is possible, but then not alone. * 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. Hence my comment about perhaps flying. * 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. Why? There is caching. DNS queries are cheap. The problem of overloading TXT is IMNSHO so bad that it is worth the cost of additional queries; especially if we can collaborate on text to stimulate migration by constructing and specifying algorithms that are faster when using SPF rrtype only. It's much more efficient to go straight to TXT where (ITYM TODAY it is much more efficient and that might change) 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
Re: Rude responses (Was: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)
Hello, Lars Eggert mentioned [1] the following: cool off, take the intensity out of the discussion, and try to provide data/facts for your different standpoints, so the rest of us who are sitting on the sidelines watching the fireworks can form an opinion. Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/diversity/current/msg00222.html
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
Mark Andrews ma...@isc.org wrote: In message 20130821214832.1c92538c0...@drugs.dv.isc.org, Mark Andrews writes: It's primarily an issue for applications. To the DNS, it's exactly what it is, a TXT record. I can hand update of A and records to the machine. I can hand update of MX records to the mail adminstrator. I can hand update of SPF records to the mail adminstrator. I can hand update of TXT records to ?? No one because it has multiple uses. This is true whether SPF exists or not. SPF use of RRTYPE TXT for SPF records makes that neither better nor worse. You could publish: example.com IN TXT v=spf1 redirect=_spf.example.com _spf.example. com IN TXT v=spf1 [actual content here] Then delegate _spf.example.com to the mail administrator. Problem solved. Scott K
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
Mark Andrews ma...@isc.org wrote:
In message 7917527.VmCQD3a6Q3@scott-latitude-e6320, Scott Kitterman
writes:
On Wednesday, August 21, 2013 23:32:33 Mark Andrews wrote:
I object to the removal of the SPF record.
This is not a shock. You were in the rough when we discussed it in
the WG
too.
Name servers already have access controls down to the granuality
of TYPE. If this draft proceeds as currently described it is
forcing
name server vendors to access controls at the sub TYPE granuality.
It's primarily an issue for applications. To the DNS, it's exactly
what it
is, a TXT record.
No. It isn't. By overloading TXT you prevent thing like this which
existed before SPF was even dreamed up.
update-policy {
grant key-one subdomain example.net ANY
deny key-two domain example.net SPF
grant key-two domain example.net ANY
};
or
update-policy {
grant key-one subdomain example.net ANY
grant key-two domain example.net TXT
};
Overloading a type is bad on so many levels which is why it was
argued that SPF needed its own type. TXT is good for prototyping
and that is about all.
update-policy {
grant key-one subdomain example.net ANY
deny key-two domain example.net TXT/v=spf1
grant key-two domain example.net ANY
};
update-policy {
grant key-one subdomain example.net ANY
deny key-two domain example.net TXT/v=spf1
grant key-two domain example.net TXT!v=spf1
};
This can be solved other ways. See my repky to your later message.
With SPF lookup first I can specify the SPF policy using SPF and
leave TXT free for other uses without having to worry about the
records being misinterpeted.
Unless you have some specific reason to be concerned about
accidentally
starting an unrelated TXT record with v=spf1 , I can't imagine you
don't
have more important things to worry about. This being a problem is
a great
theory, but it just doesn't happen in practice.
It's about being able to hand someone update control and not having to
worry about them stuffing up the SPF records.
SPF validators MUST NOT proceed to a TXT lookup on SERVFAIL for
SPF.
This is similar to not proceeding to A/ lookups on MX lookup
failures.
Except that it's quite common for a SERVFAIL on TYPESPF to occur for
a domain
that has an actual SPF record due to various operational issues.
SERVFAIL on
type SPF doesn't reliably tell you anything about what a type TXT
lookup would
produce. So it's similar, but only superficially so.
And the worst that happens is that you let some *additional*
potentially spoofed email through. This WG seems to treat this
as a catastrophic errror when it isn't. This whole debate is
because this working group treats not stopping one additional
forgery as a catastrophic errror.
I prefer to design things for reliability rather than ignore interoperability
problems.
Note also that it will be the publishing site to blame for having
a non RFC 1034 compliant server (it didn't respond to SPF queries)
or misconfigured zone (returns wrong SOA in the negative response
which can't happen when they have a SPF record).
Or some firewall in a box in between. Blame is not so easy to determine.
I would also suggest that there be a sunset date published for the
use of TXT for SPF.
Do you also suggest creation of an Internet police force to enforce
this?
What would be be mandatory minimum sentence?
You just code the cut off date into the code that does the verification
and stop making TXT queries. You code the date into the code that
checks for missing SPF records and change the complaint.
Is there an example of this kind of approach working?
Scott K
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
Hi Eliot, At 03:26 21-08-2013, Eliot Lear wrote: First, I appreciate that you and Dave are bringing data to the table. However, in this case, it is not in dispute that queries are happening. What *is* in dispute is whether there are answers. I must admit I am having a difficult time understanding the logic, even so. The *hard* part about this was supposed to be implementation of the record in the application software. Can the shepherd answer this question: To what extent has that happened? There is a thread about libspf2 querying for RRTYPE 99 first ( https://lists.exim.org/lurker/message/20110812.094310.3a53c0f6.gl.html#exim-users ). I'll also mention http://support.godaddy.com/groups/domains-management-and-services/forum/topic/spf-type-99/ and http://features.cpanel.net/responses/ability-to-create-spf-type-99-records Here are a few messages on the SPFBIS mailing list about RRTYPE 99: http://www.ietf.org/mail-archive/web/spfbis/current/msg00555.html http://www.ietf.org/mail-archive/web/spfbis/current/msg03778.html http://www.ietf.org/mail-archive/web/spfbis/current/msg03781.html The SPFBIS WG Chair asked a question about what to conclude given the SPFBIS Charter ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03779.html ). Regards, S. Moonesamy (as document shepherd)
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
In message 0c3746c3-dac1-471f-bd07-8faf20481...@email.android.com, Scott Kitterman writes: Mark Andrews ma...@isc.org wrote: In message 20130821214832.1c92538c0...@drugs.dv.isc.org, Mark Andrews writes: It's primarily an issue for applications. To the DNS, it's exactly what it is, a TXT record. I can hand update of A and records to the machine. I can hand update of MX records to the mail adminstrator. I can hand update of SPF records to the mail adminstrator. I can hand update of TXT records to ?? No one because it has multiple uses. This is true whether SPF exists or not. SPF use of RRTYPE TXT for SPF records mak es that neither better nor worse. You could publish: example.com IN TXT v=spf1 redirect=_spf.example.com _spf.example. com IN TXT v=spf1 [actual content here] Then delegate _spf.example.com to the mail administrator. Problem solved. No, it is NOT solved. You have to trust *everyone* with the ability to update TXT not to remove / alter that record. You can't give someone you don't trust the ability to update TXT. With a published SPF record and SPF lookup first stopping on success or lookup failure (SERVFAIL) you can give update control of TXT to someone you don't trust enough to not remove / alter the SPF TXT record. You keep telling us the TXT is just another record in the DNS. Well the DNS is managed at the granuality of the TYPE. 4408bis is forcing sub-type management to be developed and deployed to maintain the status quo. TXT is no longer just another record in the DNS with 4408bis as it currently stands. And to Google your motto is Do No Evil. Publishing a TXT SPF record without publish a SPF SPF record is Evil as it encourages other to do the same. Mark Scott K -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
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 wrote: On Wednesday, August 21, 2013 14:44:41 Olafur Gudmundsson wrote: 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. I'm a bit unsure that continue is the right word. DKIM moved to the TXT with underscore approach and, IIRC, never considered a new RRTYPE, nor did anyone ever suggest they should. DMARC, which has had a BoF and for which a WG is being considered will do the same (there's no variant of proposed charter text floating around that would allow them to consider otherwise). Consider that those specifications were written by the same author and group of folks. In no special meaning in any way, they all have had the same engineering mindset when it came the DKIM, VBR, ADSP and now even yet another DMARC proposed protocol. Same engineers, same engineering synergism. Thats not a negative commentary. This is desirable in an integrated world, but it can also locked down certain views as it has this case. DKIM learned from the SPF success with TXT. I specifically recall the WG decision discussion and it made practical sense. It allowed for an immediate entry point and fast proof of concept industry wide by using a TXT-based protocol, not only for DKIM but also for its original companion protocol ADSP (formerly SSP). Overall, I had sense a growing change in TXT-based protocol acceptability with many folks who otherwise were against it and this was quite apparent to me being highly considerate and cognizant of the technical design issue. It was for this reason I asked the question in the DNSEXT list and IETF before LC about where the industry stood in regards to TXT based solutions. I always had several ideas of my own for TXT-based DNS proposals such as DSAP (DKIM Signature Authorization Protocol) and a few others and if the IETF/DNS community was going to changed its belief and now endorse the TXT ideas, I didn't want to propose anything that would be controversial such as a new RR type, although that would most likely appease the DNS folks. I agree with that the notion of a statement that SPF is what it is for a variety of reasons and shouldn't be considered as a precedent for the future might be a reasonable thing to add. I don't think the IETF has been very consistent about what one ought to do instead. I don't agree with the SPF exception. If you believe in the future infrastructure to support new RR types, then there is no sensible reason to remove the SPF type and migration path from an updated RFC-4408BIS document. I don't see any harm in keeping the migration path IFF there is confidence a supportive infrastructure will be available in the future. -- HLS
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, On Aug 21, 2013, at 4:07 PM, Scott Kitterman sc...@kitterman.com wrote: You could publish: example.com IN TXT v=spf1 redirect=_spf.example.com _spf.example. com IN TXT v=spf1 [actual content here] Then delegate _spf.example.com to the mail administrator. Problem solved. Wouldn't this cause an extra lookup that you were arguing was prohibitive for large scale mail providers? Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail
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
NB: I have read the rest of the thread; but this is what deserves a reply: Dave Crocker d...@dcrocker.net wrote: On 8/21/2013 11:58 AM, Pete Resnick wrote: AD hat squarely on my head. (There may have been a miscommunication here -- what particular AD function Pete was speaking in; but to me, at least, it becomes clear in context.) On 8/21/13 1:29 PM, Dave Crocker wrote: Oh. Now I understand. You are trying to impose new requirements on the original work, many years after the IETF approved it. Thanks. Very helpful. That's not an appropriate response. Dave has every right to disagree on that; but I quite agree with Pete. It is decidedly not helpful, not productive, and tends towards escalating a discussion which has no need of escalation. It is certainly not helpful to me as the consensus caller. Dave has no right to disagree with this. We pay Pete the big bucks to call consensus on difficult issues like this. We need to understand it will be hard sometimes. I'm sure Dave has read Pete's draft on the meaning of consensus. I'm less sure he remembered it as he responded here. If this is the sort of response given to somewhat-valid questions raised about the draft being proposed, Pete will eventually have to say there _is_ no consensus. :^( And it is rude. Pete's opinion. (I happen to share it.) Consensus process works _much_ better if we respect the opinions of others -- even when we know they're wrong. Since you've made this a formal process point, Pete has _not_ done this. I'll ask you to substantiate it carefully and also formally... I see no reason Pete has any obligation to do so. If he chooses to, I ask him to not do it on this list. (Please don't feed the troll comes to mind.) A bit of edge is warranted for such wasteful, distracting and destabilizing consumption of IETF resources... Dave's opinion. (I happen to not share it.) Consensus process _also_ works better if we respect Dave's opinion here. I suggest we all remember that we don't have to change others' opinions here (were such a thing possible). We have only to bring them to the point where they agree they can live with the result. -- John Leslie j...@jlc.net
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
On Thursday, August 22, 2013 09:31:03 Mark Andrews wrote: In message 0c3746c3-dac1-471f-bd07-8faf20481...@email.android.com, Scott Kitterman writes: Mark Andrews ma...@isc.org wrote: In message 20130821214832.1c92538c0...@drugs.dv.isc.org, Mark Andrews writes: It's primarily an issue for applications. To the DNS, it's exactly what it is, a TXT record. I can hand update of A and records to the machine. I can hand update of MX records to the mail adminstrator. I can hand update of SPF records to the mail adminstrator. I can hand update of TXT records to ?? No one because it has multiple uses. This is true whether SPF exists or not. SPF use of RRTYPE TXT for SPF records mak es that neither better nor worse. You could publish: example.com IN TXT v=spf1 redirect=_spf.example.com _spf.example. com IN TXT v=spf1 [actual content here] Then delegate _spf.example.com to the mail administrator. Problem solved. No, it is NOT solved. You have to trust *everyone* with the ability to update TXT not to remove / alter that record. You can't give someone you don't trust the ability to update TXT. With a published SPF record and SPF lookup first stopping on success or lookup failure (SERVFAIL) you can give update control of TXT to someone you don't trust enough to not remove / alter the SPF TXT record. You keep telling us the TXT is just another record in the DNS. Well the DNS is managed at the granuality of the TYPE. 4408bis is forcing sub-type management to be developed and deployed to maintain the status quo. TXT is no longer just another record in the DNS with 4408bis as it currently stands. And to Google your motto is Do No Evil. Publishing a TXT SPF record without publish a SPF SPF record is Evil as it encourages other to do the same. Your goal seems to be pretty much the opposite of the task the working group was given. You say so even more clearly here: http://www.ietf.org/mail-archive/web/spfbis/current/msg03948.html Unless you come with something new, I think I'm done. Scott K
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
Hi John, At 20:02 21-08-2013, John Leslie wrote: If this is the sort of response given to somewhat-valid questions raised about the draft being proposed, Pete will eventually have to say there _is_ no consensus. :^( An Area Director may say that. :-( Regards, S. Moonesamy
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
On Thursday, August 22, 2013 00:26:35 Måns Nilsson wrote: ... SPF is a flagship case for the use a TXT record and continue to IPO fast and sloppy crowd. It needs correcting. Badly. Which IPO was that? BTW, in 2003 the choice was use TXT or nothing. So it was a crowd that wanted to accomplish something and did it the only way it was possible. Considering use of TXT wasn't an important factor in the DKIM last call, I conclude that this isn't really about using TXT. Scott K
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
On 20 aug 2013, at 07:21, Dave Crocker d...@dcrocker.net wrote: The first is that there now a number of other apps using TXT records, with no problems, because they are stored under scoping nodes (underscore-prefaced names). This approach might be aesthetically displeasing, but it works just fine. That can not be said generally. Reason for this is that the RR with an underscored prefix MIGHT end up in a different zone than the record without. This implies that two records with the same owner and different RRType MUST be in the same zone, while a name without and one with prefix MIGHT NOT, where also one of the zones is signed and the other is not. Patrik
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
On 8/19/2013 11:33 PM, Patrik Fältström wrote: Reason for this is that the RR with an underscored prefix MIGHT end up in a different zone than the record without. Patrik, Please clarify. I don't know what you mean by the 'with' and 'without' references. And as long as I'm asking for more explanation, given the number of years of use the construct has had and for the number of different applications, where has the problem (whatever you mean specifically) been seen? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
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
On 20 aug 2013, at 09:14, Dave Crocker d...@dcrocker.net wrote: On 8/19/2013 11:33 PM, Patrik Fältström wrote: Reason for this is that the RR with an underscored prefix MIGHT end up in a different zone than the record without. Patrik, Please clarify. I don't know what you mean by the 'with' and 'without' references. The two following records MUST be in the same zone: foo.example. IN X RDATAX foo.example. IN Y RDATAY The two following MIGHT NOT be in the same zone: foo.example. IN X RDATAX _bar.foo.example. IN TXT RDATAY And as long as I'm asking for more explanation, given the number of years of use the construct has had and for the number of different applications, where has the problem (whatever you mean specifically) been seen? When using DNSSEC if the _bar.foo.example record in the 2nd example above is unsigned, while the foo.example in the first example is. Patrik
