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

S Moonesamy <sm+ietf@elandsys.com> Mon, 16 September 2013 01:19 UTC

Return-Path: <sm@elandsys.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7791311E8189 for <ietf@ietfa.amsl.com>; Sun, 15 Sep 2013 18:19:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.308
X-Spam-Level:
X-Spam-Status: No, score=-102.308 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, GB_ABOUTYOU=0.5, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igj9h0zzXCYw for <ietf@ietfa.amsl.com>; Sun, 15 Sep 2013 18:19:49 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A011B11E8181 for <ietf@ietf.org>; Sun, 15 Sep 2013 18:19:49 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.224.159.70]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8G1JOMd029892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Sep 2013 18:19:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379294375; bh=xUsbowXtY8fyfITUDXNcmKkvCtv7psS9xWfLm8Da83M=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=oGC6yb4Oc5jwHuI5L8E6Gw7rLwmvifV20NvWFdWPJ3ejrUGmsK+6C5iJUY/RieKZo I8o8KFwn9Be1RD9EhP3COXJz7yuaWQeZwsvc0WDOJbCHQC5aXY0BOyCnDGOoNCVnfZ z1EGwoRI8N2gu9mxegAsXGFmXEpLvls7+T/hGrig=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379294375; i=@elandsys.com; bh=xUsbowXtY8fyfITUDXNcmKkvCtv7psS9xWfLm8Da83M=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=v7qDFIZzYiaBgqPt/VCmnbW4Bpwj8fQw2p2FgBwPpty/gTtf/vGFsJP0d9OWiHtB+ AD08qXxClcViSuo9/7lsTn3+XMe1VC5jHVpL+Bmd4imajCIHT/w3OHZJj8fd2a0CAQ r86uqmKbXJkR1d3DBL8Iwh8CzR3opxi+6vuldrm0=
Message-Id: <6.2.5.6.2.20130915160907.0cbc65a0@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sun, 15 Sep 2013 18:11:55 -0700
To: Douglas Otis <doug.mtview@gmail.com>
From: S Moonesamy <sm+ietf@elandsys.com>
Subject: Re: Messages to SPFBIS mailing list (was: [spfbis] Benoit Claise's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT))
In-Reply-To: <66B3A227-8616-419C-BADA-891E46A7A40B@gmail.com>
References: <20130912104701.7259.79919.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130912065558.0b960550@elandnews.com> <5231D5E5.5070407@cisco.com> <6.2.5.6.2.20130912080503.0c90f9d0@elandnews.com> <18A91BEE-6360-4E1F-9B08-5E45C5217694@gmail.com> <20130914003652.GF78680@mx1.yitter.info> <BD926F72-A6C3-4F0B-BBFB-A18668C9E4AF@gmail.com> <6.2.5.6.2.20130914134022.0c89dab8@elandnews.com> <66B3A227-8616-419C-BADA-891E46A7A40B@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2013 01:19:51 -0000

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