On Aug 24, 2013, at 3:16 AM, S Moonesamy <sm+ietf(_at_)elandsys(_dot_)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 eliminates the effect of the void
response limit while also increasing the amount of the resulting traffic.
<random-string>cdr-ds.metric.gstatic.com
<random-string>.g.vm.akamaistream.net
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.
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 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.
This timeout is not likely problematic after ensuring against macros where then
caching can be effective at overcoming this constraint.
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.
That does not mean DNSSEC will not be used. One hopes just the opposite is
true.
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.
I welcome comments from other IETF participants about the above.
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.
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.
s/UDP packet/DNS message/
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.
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.
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'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."
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
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)