Re: [dnsext] Deprecating SPF

Phillip Hallam-Baker <hallam@gmail.com> Tue, 20 August 2013 20:23 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7A211E829B for <dnsext@ietfa.amsl.com>; Tue, 20 Aug 2013 13:23:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.446
X-Spam-Level:
X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 n0MLa+uFQxbs for <dnsext@ietfa.amsl.com>; Tue, 20 Aug 2013 13:23:58 -0700 (PDT)
Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id BCAA511E829A for <dnsext@ietf.org>; Tue, 20 Aug 2013 13:23:57 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id x12so98700wgg.11 for <dnsext@ietf.org>; Tue, 20 Aug 2013 13:23:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZoK/0c+ZG6E5rkqBvUU6bl1kP/zGNlOqnEv7rPjhOoI=; b=gpXlqBxcaUdI3L1PriLidjk0nERDugEGBgEELmA5lDWE7YfR4TV9LqF9BbH/Xyz73G qQNn5aU299ypio6WZkdHcSlCEjLhXTG29FXME5pFVZ/v7rYqsk0C/UynsfI8yYquP/nE sCsbMBJQX/Po/Z9lcHehU/6F2CIFmy6KsHT//psdlumtoS4wZ46xSyfwIxK+7QfUP8sx pmAcTuSweziSImJAfhbq4Trn1wqzRunZgiFDld6va+8P0IBXW0ZcflltMJJLfahLKo92 Vf6XHeM3NEdsSXIo+YqeAVFn0hIHNpvAlgFXqb3m3jFjTX6IMQP+5z7ZC+6gcAf0gBmH +RRw==
MIME-Version: 1.0
X-Received: by 10.194.48.74 with SMTP id j10mr2852259wjn.41.1377030235520; Tue, 20 Aug 2013 13:23:55 -0700 (PDT)
Received: by 10.194.6.67 with HTTP; Tue, 20 Aug 2013 13:23:55 -0700 (PDT)
In-Reply-To: <CAMm+Lwhrk3Z2Y6A5zQ_GiaX4CcepsVzm78WAT3KgUz99Ug9KPw@mail.gmail.com>
References: <E3DE33F3-B0A5-494B-9202-499E16ECCFB1@virtualized.org> <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820144211.GD20618@mx1.yitter.info> <ED29CE68-EB63-42C2-8C40-0A3450DCCA10@frobbit.se> <20130820153656.GB21439@mx1.yitter.info> <5213A481.8010602@rancid.berkeley.edu> <CAMm+Lwhrk3Z2Y6A5zQ_GiaX4CcepsVzm78WAT3KgUz99Ug9KPw@mail.gmail.com>
Date: Tue, 20 Aug 2013 16:23:55 -0400
Message-ID: <CAMm+LwiAQVisGVOgprdRps5bbVdghN8gYcELteKkV9z9dRYOdA@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Michael Sinatra <michael@rancid.berkeley.edu>
Content-Type: multipart/alternative; boundary="047d7ba975c808894504e466d66c"
Cc: "dnsext@ietf.org" <dnsext@ietf.org>
Subject: Re: [dnsext] Deprecating SPF
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Aug 2013 20:24:00 -0000

My apologies, seems like we had a miscommunication and Patrick was waiting
for input from me. Taking that discussion offline.


On Tue, Aug 20, 2013 at 3:23 PM, Phillip Hallam-Baker <hallam@gmail.com>wrote:

>
>
>
> On Tue, Aug 20, 2013 at 1:16 PM, Michael Sinatra <
> michael@rancid.berkeley.edu> wrote:
>
>> On 8/20/13 8:36 AM, Andrew Sullivan wrote:
>> > On Tue, Aug 20, 2013 at 05:17:59PM +0200, Patrik Fältström wrote:
>> >>
>> >> And the fact people use both TXT and SPF is to me an indication the
>> >> migration plan works, and that the fix should be to clarify how to
>> >> continue that migration given that we have what I would call an
>> >> unclear paragraph exists in the original RFC.
>> >
>> > RFC 6686 tells us the extent to which people are "using both".  see
>> > section 3.1.  No survey was able to find people "using both" at even
>> > 2% of all the domains surveyed.  SPF records using TXT ranged between
>> > just under 40% to more than 50%.  I find it hard to interpret that
>> > data as an indication that the migration plan is having any real
>> > effect at all.
>> >
>> > I don't think anyone can accuse me of being sanguine about the
>> > overloading of TXT.  But the IETF is made ridiculous if it stands
>> > around trying to tell the sea to stay back.
>>
>> There seems to be an unstated philosophical argument about what the role
>> of the IETF should be.  It's like the perennial prescriptive/descriptive
>> argument that dictionary-writers have.
>>
>> Should the role of the IETF be to describe implemented standards or
>> should it be to prescribe new or evolved standards?  Should it be trying
>> to push SPF in a slightly-different direction or should it be trying to
>> maximize the *current* (short-term?) utility and interoperability of SPF?
>>
>
> The question that needs to be asked but isn't is 'what role do the
> governance structures permit'?
>
> he IAB is tasked with architecture but does not solicit or build consensus
> for its architectural proposals. Which is why Patrik's DNS options proposal
> was stillborn.
>
> That IAB is not elected by the IETF membership or accountable to it. So
> the IETF feels no obligation to follow the guidance it attempts to give.
> Worse, the old boys club method of selection ensures that members are
> picked for the conformity rather than the novelty of their views. So it
> tends to be a reactionary body.
>
> In the case of Patrik's RFC, there were many problems:
>
> 1) The SPF Working Group was justifiably peeved by the attempt by the
> DNSEXT group to trump their work by presenting their opinion in the form of
> an IAB ultimatum.
>
> 2) The RFC is broken. It makes assertions that are demonstrably untrue and
> makes erroneous conclusions.
>
> 3) The method of extension proposed is obviously unscalable as there are
> only 65535 possible RRs and far more Web Services requiring discovery.
>
> 4) The draft does not acknowledge the fact that at the time it was written
> one of the principle DNS servers in use could not in fact support unknown
> RR types.
>
> 5) The document does not admit that the real agenda was to push through
> the infrastructure needed to support DNSSEC.
>
> The last was subject to a long dispute between the SPF group and the DNS
> WG. At one point Microsoft presented the actual code for their DNS server
> and showed that it absolutely does not have the ability to save a zone
> file. Despite this DNSEXT members continued to insist that black was white
> and Microsoft's DNS server could be used to serve unknown DNS RRs based on
> the fact that one of them had written some sort of script that could
> somehow wedge them into the cache. A hack that any network manager using it
> should be sacked for touching since it was clearly not maintainable.
>
> Having watched the interaction between the SPF and DNSEXT WGs, this
> outcome is no surprise to me. Indeed it was inevitable.
>
>
> We should have a proper IAB that comes out with architectural guidance so
> we don't have six different WGs make six different decisions on how to do
> the same thing. But that can only work if the process delivers a result
> that has widespread consensus. Which is not going to happen if the process
> is that an elite club meets in secret and issues edicts.
>
> The IETF mission statement is botched. The mission of the IETF is not to
> produce documents, they are only a byproduct. The mission of the IETF is to
> produce consensus.
>
> The reason I am peeved by the CBOR fiasco is that we have a situation
> where we need a common approach but the mechanism chosen ensures that the
> chosen winner has no consensus and will thus be ignored.
>
>
> We do need a proper discovery architecture. One that makes it possible to
> discover policy information as part of the discovery process. The DNS
> options draft was a missed opportunity in that respect.
>
> I have suggested to Patrik on several occasions that we extend his URI
> discovery proposal to allow policy attributes to be included in the URI
> specification. But never received an answer.
>
> --
> Website: http://hallambaker.com/
>



-- 
Website: http://hallambaker.com/