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

From: Douglas Otis <[email-masked]>
Date: Fri, 23 Aug 2013 13:07:51 -0700

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-string>cdr-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 "AAAA" 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 (distance) value followed by an MTA hostname.  

A DNS MX reply may offer A records for the hostnames in the Additional Section however per:
Per RFC2181 Section 5.4:
,---
Servers must never merge RRs from a response with RRs in their
cache to form an RRSet.  If a response contains data that would form
an RRSet with data in a server's cache the server must either ignore
the RRs in the response, or discard the entire RRSet currently in the
cache, as appropriate.
'---

This will not prove ideal for SPF with respect to effective use of DNS.

Also hostnames contained within MX resource record might be within any domain, and not necessarily the same domain as that of the base SPF record.

Per RFC2181 5.4.1. Ranking data
An authoritative answer from a reply should replace cached data that had been obtained from additional information in an earlier reply. However additional information from a reply will be ignored if the cache contains data from an authoritative answer or a zone file.

Mistake.

Section 3.4 

Second paragraph:

Similarly, the sizes for replies to all queries related to SPF have to be evaluated to fit in a single 512 octet UDP packet.

s/UDP packet/DNS message/

Per RFC1035 
Section 2.3.4. Size limits
UDP messages    512 octets or less

Section 4.2.1. UDP usage
Messages carried by UDP are restricted to 512 bytes (not counting the IP or UDP headers).

The DNS message size limitation is not the same as a UDP packet limit as suggested in Section 3.4.

The SPFbis WG charter permitted removal of unused protocol elements where the “ptr” mechanism was deprecated and the SPF resource type was removed. Use of SPF’s very dangerous macro feature currently has less than 0.053% of the domains making use of these macros and clearly falls below the WG removal threshold.  We have also been told by a few very large providers that SPF records containing any macro reference are ignored for reasons related to both efficiency and security.  Marcos also inhibit the primary use by large providers which is to compile the domain’s IP address list.

The WG should have been told to focus on security and at better insuring interchange to achieve a safer stance moving forward.

Regards,
Douglas Otis

---

From: S Moonesamy <[email-masked]>
Date: Sat, 24 Aug 2013 03:16:30 -0700

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

>resolutions exceeds 10, check_host() MUST produce a "permerror"
>result.
>

I'll list the above as not addressed yet.

>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.

>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.

>exchange that will impose a SIGNIFICANT reflected amplification risk.

draft-ietf-spfbis-4408bis-19 does not have any DNSSEC requirement.

>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.

I welcome comments from other IETF participants about the above.

>Also hostnames contained within MX resource record might be within 
>any domain, and not necessarily the same domain as that of the base SPF record.
>
>An authoritative answer from a reply should replace cached data that 
>had been obtained from additional information in an earlier reply. 
>However additional information from a reply will be ignored if the 
>cache contains data from an authoritative answer or a zone file.

I agree that MX resource records do not contain IP addresses.  There 
is a thread at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03305.html 
about reasonable DNS error limits.  I could not spot the problem in 
the paragraph that is described as misleading.  An example to 
illustrate the problem might make it clearer.

>Mistake.
>
>Section 3.4
>
>Second paragraph:
>
>Similarly, the sizes for replies to all queries related to SPF have 
>to be evaluated to fit in a single 512 octet UDP packet.
>

My understanding of the working group discussion is that the intent 
is to have the DNS reply fit within a UDP packet.

>limit as suggested in Section 3.4.

I am not sure whether the above refers to the "450 octets".  I'll 
note a comment from Andrew Sullivan ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03103.html ) 
so that I don't have to search for it again.

>The SPFbis WG charter permitted removal of unused protocol elements 
>where the "ptr" mechanism was deprecated and the SPF resource type 
>was removed. Use of SPF's very dangerous macro feature currently has 
>less than 0.053% of the domains making use of these macros and 
>clearly falls below the WG removal threshold.  We have also been 
>told by a few very large providers that SPF records containing any 
>macro reference are ignored for reasons related to both efficiency 
>and security.  Marcos also inhibit the primary use by large 
>providers which is to compile the domain's IP address list.

There was an appeal about the meaning of the word "unused" ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02167.html 
).  I'll highlight a comment from Pete Resnick:

   "There's also the comment from Doug Otis about the local-part
    macro. I'm inclined to declare that out of scope, maybe after a
    recharter. That's not documenting current practice, but is an overt
    change."

There are some threads about local part macros:

http://www.ietf.org/mail-archive/web/spfbis/current/msg00911.html
http://www.ietf.org/mail-archive/web/spfbis/current/msg01870.html

There is a short thread and a few other threads about the "ptr" 
mechanism ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00808.html 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00811.html 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03184.html ).

There is the following text in the write-up:

    "There was some controversy about whether the use of macros was a
     security risk and whether to deprecate the PTR feature.  There was a
     formal appeal of the SPFBIS WG chair' interpretation of the charter,
     specifically regarding the removal of "unused" features.  The two
     features in particular which drove the appeal were the PTR feature
     and the local-part macro feature.  These features were not removed
     from the document given that the appeal was denied by the Responsible
     Area Director."

I hope that the above explains the decision.

>The WG should have been told to focus on security and at better 
>insuring interchange to achieve a safer stance moving forward.

The working group was reminded about BCP 72.

Regards,
S. Moonesamy (as document shepherd)

---

From: Douglas Otis <[email-masked]>
Date: Mon, 26 Aug 2013 15:42:41 -0700

On Aug 24, 2013, at 3:16 AM, S Moonesamy <[email-masked]> wrote:

> 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.

> There are other messages on the Last Call about the SPF Resource Record.  I'll take up the above together with the other 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.  

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. 

> 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 eliminates the effect of the void response limit while also increasing the amount of the resulting traffic.

> I'll list the above as not addressed yet.

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. 

> 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.

This timeout is not likely problematic after ensuring against macros where then caching can be effective at overcoming this constraint.

> 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.
> 

That does not mean DNSSEC will not be used.  One hopes just the opposite is true.

> I agree that MX resource records do not contain IP addresses.  There is a thread at http://www.ietf.org/mail-archive/web/spfbis/current/msg03305.html about reasonable DNS error limits.  I could not spot the problem in the paragraph that is described as misleading.  An example to illustrate the problem might make it clearer.
> 
>> Mistake.
>> 
>> Section 3.4
>> 
>> Second paragraph:
>> 
> My understanding of the working group discussion is that the intent is to have the DNS reply fit within a UDP packet.

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.

> I am not sure whether the above refers to the "450 octets".  I'll note a comment from Andrew Sullivan ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03103.html ) so that I don't have to search for it again.

A reduction to 450 octets would be a reasonable recommendation for the DNS _message_, not the UDP _packet_.  The packet still needs to carry the IP and UDP headers.

>> The SPFbis WG charter permitted removal of unused protocol elements where the "ptr" mechanism was deprecated and the SPF resource type was removed. Use of SPF's very dangerous macro feature currently has less than 0.053% of the domains making use of these macros and clearly falls below the WG removal threshold.  We have also been told by a few very large providers that SPF records containing any macro reference are ignored for reasons related to both efficiency and security.  Marcos also inhibit the primary use by large providers which is to compile the domain's IP address list.
> 
> There was an appeal about the meaning of the word "unused" ( http://www.ietf.org/mail-archive/web/spfbis/current/msg02167.html ).  I'll highlight a comment from Pete Resnick:
> 
> There is a short thread and a few other threads about the "ptr" mechanism ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00808.html http://www.ietf.org/mail-archive/web/spfbis/current/msg00811.html http://www.ietf.org/mail-archive/web/spfbis/current/msg03184.html ).
> 

There should be some type of warning at minimum as the macro issue is likely to affect interchange now and going forward.  The IETF should not consider protocols outside larger concerns of the well being of the Internet infrastructure and proper interchange.  This issue should not be controversial.  

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 26 Aug 2013 18:48:04 -0400

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

---

From: Douglas Otis <[email-masked]>
Date: Mon, 26 Aug 2013 16:28:03 -0700

> permerror in place of a fail if desired.  The WG considered that not a good 

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

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 26 Aug 2013 19:29:36 -0400

On Monday, August 26, 2013 16:28:03 Douglas Otis wrote:
> > 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

---

From: Douglas Otis <[email-masked]>
Date: Mon, 26 Aug 2013 16:32:25 -0700

Dear Scott, 

Do you recall whether DNSSEC had been considered?

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 26 Aug 2013 19:56:53 -0400

>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

---

From: S Moonesamy <[email-masked]>
Date: Mon, 26 Aug 2013 19:28:25 -0700

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-string><http://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.

>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 

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.

>>>UDP messages    512 octets or less

I'll suggest UDP message.

>A reduction to 450 octets would be a reasonable recommendation for 
>the DNS _message_, not the UDP _packet_.  The packet still needs to 
>carry the IP and UDP headers.

Yes.  I misunderstood your previous arguments.

>There should be some type of warning at minimum as the macro issue 
>is likely to affect interchange now and going forward.  The IETF 
>should not consider protocols outside larger concerns of the well 
>being of the Internet infrastructure and proper interchange.  This 
>issue should not be controversial.

I'll consider the "macro" issue as addressed.

Regards,

---

From: Joe Abley <[email-masked]>
Date: Tue, 27 Aug 2013 11:59:41 -0400

> 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

---

From: S Moonesamy <[email-masked]>
Date: Tue, 27 Aug 2013 09:43:49 -0700

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,

---

From: S Moonesamy <[email-masked]>
Date: Wed, 28 Aug 2013 05:24:48 -0700

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,

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 28 Aug 2013 15:47:51 +0200

On 28 aug 2013, at 14:24, S Moonesamy <[email-masked]> 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:
> 

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,

   Patrik

---

From: Dave Crocker <[email-masked]>
Date: Wed, 28 Aug 2013 07:21:13 -0700

On 8/28/2013 5:24 AM, S Moonesamy wrote:
> draft-ietf-spfbis-4408bis.  I would like to ask each of you, and anyone
> else, to provide your opinion about the following:
>

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

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 28 Aug 2013 10:39:10 -0400

> higher priority than theoretical technical perfection.

Yes.  Please.

Scott K

---

From: Mark Andrews <[email-masked]>
Date: Thu, 29 Aug 2013 00:52:20 +1000

In message <[email-masked]>, S Moonesamy writes
> 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: [email-masked]

---

From: John C Klensin <[email-masked]>
Date: Thu, 29 Aug 2013 12:31:31 -0400

--On Wednesday, August 28, 2013 07:21 -0700 Dave Crocker
<[email-masked]> wrote:

> 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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 29 Aug 2013 12:28:57 -0700

On 8/29/2013 9:31 AM, John C Klensin wrote:
> 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/

---

From: John C Klensin <[email-masked]>
Date: Thu, 29 Aug 2013 16:11:48 -0400

--On Thursday, August 29, 2013 12:28 -0700 Dave Crocker
<[email-masked]> wrote:

> 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:
> 
 
> 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 have misunderstood you, I'd like to be
better informed), but then I suggest that we leave the
discussion to others if they believe it to be of value.

best,
    john

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 29 Aug 2013 19:43:10 -0400

> ought to be able to take at least one whack at it on IETF LC.

+1

> 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

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/