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-58D05EA4BC98@xxxxxxxxx. 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.5050406@xxxxxxxxxxxxxx
4F0E7154.4080208@xxxxxxxx
29fba028-5881-4a04-95d4-227582a3801e@xxxxxxxxxxxxxxxxx
Pine.GSO.4.62.1201121350550.3388@xxxxxxxxxxxxxxxxxx
20120425152326.GE60024@xxxxxxxxxxxxxxxx
1545953.Y9VaoKsXxF@scott-latitude-e6320
20120704015156.GB12452@xxxxxxxxxxxxxxx
1977893.MDoye0cYQa@scott-latitude-e6320
20130122231357.GA6921@xxxxxxxxxxxxxxx
3896517.k8tBVMT4Fi@scott-latitude-e6320
CD246081.BBD2F%fmartin@xxxxxxxxxxxx
20130123010120.GC7073@xxxxxxxxxxxxxxx
271785100.KEZggNLeh1@scott-latitude-e6320
CAL0qLwaW1-dQg-NhwBNWAppXjfsoacO1Q8gHdPPvEGDssEpJQA@xxxxxxxxxxxxxx
20130125143603.GA11573@xxxxxxxxxxxxxxx
7ab574aa-d13c-44e2-968e-4946bd05808c@xxxxxxxxxxxxxxxxx
20130430103940.GB32695@xxxxxxxxxxxxxxxx
517FBBCD.3010001@xxxxxxx
20130624212511.GB44803@xxxxxxxxxxxxxxx
686233851.4iQopu4Yll@scott-latitude-e6320
24624534.FuUVENZpXd@scott-latitude-e6320
24624534.FuUVENZpXd@scott-latitude-e6320
B8983E88-14A1-4741-99ED-F43962B2497A@xxxxxxxxx
BA4D9B3E-F9A6-46AF-BBA7-D6AD463020CA@xxxxxxxxx
5129719.PDZTiHcDZ6@scott-latitude-e6320
BD926F72-A6C3-4F0B-BBFB-A18668C9E4AF@xxxxxxxxx
38312086.HKzMeyOO04@scott-latitude-e6320
2137735.9LNiMWPY5V@scott-latitude-e6320