ietf
[Top] [All Lists]

Re: Messages to SPFBIS mailing list (was: [spfbis] Benoit Claise's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT))

2013-09-15 17:58:54

On Sep 14, 2013, at 1:57 PM, S Moonesamy <sm+ietf(_at_)elandsys(_dot_)com> 
wrote:

Hi Doug,
At 20:56 13-09-2013, Douglas Otis wrote:
If I have said something offensive, allow me once again to assure you this 
was never my intent.

There isn't anything in your message which was offensive.  I'll try to 
explain the problem.  Your message was not even related to the topic being 
discussed.  It becomes a problem when it happens repeatedly.  People complain 
about it.  A WG Chair then has to decide what action to take.

If you are unsure about whether your message is on-topic you can contact the 
WG Chairs at spfbis-chairs(_at_)tools(_dot_)ietf(_dot_)org.  Please note that 
my intent is not to restrict your participation.

Dear SM,

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'll suggest:

  and see RFC 4033 for a countermeasure.
'---
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 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.

Regards,
Douglas Otis





<Prev in Thread] Current Thread [Next in Thread>