Hi Doug,
At 15:58 15-09-2013, Douglas Otis wrote:
This view is fully reasonable using the paradigm SPFbis is just
another protocol using DNS. If so, a reference to RFC4033 would be
logical and my response would seem off-topic. To clarify, the
strong response was aimed specifically at the suggestion this
referenced RFC offers a meaningful countermeasure. It does not and can not.
I set the subject in my message to you as "Messages to SPFBIS mailing
list". I assumed that it was clear that the topic being discussed in
the body of the message was about your messages to the SPFBIS mailing
list and the topics being discussed on different threads.
,---
> I'll suggest:
>
> and see RFC 4033 for a countermeasure.
'---
The above (see the two quoted paragraphs above) is not related to the
message at
http://www.ietf.org/mail-archive/web/spfbis/current/msg04182.html or
any other comments which you posted to the SPFBIS mailing list over
the last week. I see part of a message relating to a message from
Sean Turner being quoted (
http://www.ietf.org/mail-archive/web/spfbis/current/msg04157.html ).
The reasoning is as follows:
Nothing within RFC4033, or even other recently proposed mitigation
strategies, offer remedies or countermeasures that adequately
address risks introduced by SPFbis. SPFbis failed to acknowledge
some providers will not process macros and extremely few domains
publish SPF records containing macros. Adding any number of DNS
related references will NOT offer countermeasures able to address
network amplifications SPFbis permits for unknown entities. In
other words, SPFbis advocates a scheme where more than 222 automated
DNS macro driven transactions are to be made by message recipients
on behalf of unknown entities.
The message from Sean Turner was about "spoofed DNS". I suggested a
reference and Sean Turner mentioned that it would work for him. John
Levine also commented and mentioned that he is okay with that. There
wasn't anything in the messages about "macros".
The SPFbis process:
a) Fails to use dedicated resource records
b) Fails to use naming conventions
c) Does not limit a large sequence of resource record sizes
d) Uses macro selected email terms to modify targets which--
1) inhibits effective caching
2) increases network amplification potentials (>>3x)
3) increases the number of indirect DNS threat vectors (any
system sending email)
From any practical measure, macros have already been
deprecated. SPFbis should reflect this reality since not doing so
will greatly impact interchange. SPFbis should also go one step
further and return "permerror" when resource record sizes are
larger than necessary to better ensure against reflected network
amplification threats that would imperil DNSSEC/ENDS0.
I previously asked for input about the "macro" issue from anyone who
has not commented about it (
http://www.ietf.org/mail-archive/web/ietf/current/msg82405.html ). I
did not receive any input and I did not see any messages relating to
what I asked on the SPFBIS mailing list; the latter can be easily
verified by reading the SPFBIS mailing list archives.
Regards,
S. Moonesamy