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.
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 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,
S. Moonesamy (as document shepherd)