Re: "why I quit writing internet standards"

Douglas Otis <doug.mtview@gmail.com> Sun, 20 April 2014 18:26 UTC

Return-Path: <doug.mtview@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C171A005A for <ietf@ietfa.amsl.com>; Sun, 20 Apr 2014 11:26:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_42=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8SBHsfS7RWt for <ietf@ietfa.amsl.com>; Sun, 20 Apr 2014 11:26:01 -0700 (PDT)
Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 818AA1A0029 for <ietf@ietf.org>; Sun, 20 Apr 2014 11:26:01 -0700 (PDT)
Received: by mail-pa0-f54.google.com with SMTP id lf10so3029198pab.13 for <ietf@ietf.org>; Sun, 20 Apr 2014 11:25:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CY9x4oJ85Ac/wFoOhwsVJUHQ9X5XXxNQzDG6c9AYY+E=; b=jDVKYsF97waK8X8+gw91W3HqobQzebyy5/Y653cb1Yq9+sBQU+xB1w2LxJQ91U0IBV w7y7Wwem6S1LEu3ANQIR497bLGTiq4Q6DcF2E1K8VhylMf1/IALrScnQ1/jW+gCCS1V/ UcOGTy+k8bgZrvtYxMMhQxHo5z1MOPNq4pvsT/n3AcySUIQ4pOBgwqsnCnXdykbL+cWb 5bIMRBzRWNc2DFYTKm5lktz6AmJ5e51EOUx1WFsA1olY1NLlH0ycGlSLS32ewMqOaybv WSct7KRtvPIFBawbVqp+A+QnXGp0t7XrasFZmuxTNEFQETlTKYREOMqCy9PLVZSrWe41 dB4w==
X-Received: by 10.68.221.42 with SMTP id qb10mr33858639pbc.65.1398018356855; Sun, 20 Apr 2014 11:25:56 -0700 (PDT)
Received: from ?IPv6:2601:9:7680:203:959f:4446:19b2:81ad? ([2601:9:7680:203:959f:4446:19b2:81ad]) by mx.google.com with ESMTPSA id ei4sm73038825pbb.42.2014.04.20.11.25.55 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Apr 2014 11:25:55 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
Subject: Re: "why I quit writing internet standards"
From: Douglas Otis <doug.mtview@gmail.com>
In-Reply-To: <5353FEF7.2060708@bbiw.net>
Date: Sun, 20 Apr 2014 11:25:56 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <AB5D3900-BB09-4C4A-B52C-46349C086927@gmail.com>
References: <CF71721A.180A9%wesley.george@twcable.com> <534C067D.8080506@meetinghouse.net> <CAL0qLwa5CRwxn0V=7D84KFv9K_u5W5L+PPUXc3KPkD0YHkNo1w@mail.gmail.com> <4756885.Eo3b3po9Vj@scott-latitude-e6320> <5353FEF7.2060708@bbiw.net>
To: Dave Crocker <dcrocker@bbiw.net>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/gT8_pEEv4zGVjpSogb4vL6L7R-M
Cc: Scott Kitterman <scott@kitterman.com>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 20 Apr 2014 18:26:03 -0000

On Apr 20, 2014, at 10:08 AM, Dave Crocker <dcrocker@bbiw.net> wrote:

> On 4/14/2014 8:28 PM, Scott Kitterman wrote:
>> If that's true, it's my impression it's true because the DMARC proponents
>> insisted any possible working group charter preclude meaningful changes to the
>> base specification because the work was already done.
> 
> 
> That statement is incorrect.
> 
> What we pressed for was to get community rough consensus on the kinds of technical work that needed to be done to the -base (core) specification, /before/ chartering the effort.
> 
> This was explicitly to avoid the trap of declaring the existing spec unstable -- and that's what starting an open-ended development effort automatically does -- when there was no demonstrated need to do that.
> 
> In spite of repeated efforts -- in at least two venues -- to get folks to state what work they thought was needed and to get community support for that work, no tasks were produced.
> 
> That meant that any wg charter permitting changes to the protocol would have been entirely without any foundation based on need.
> 
> In fact, it would have a foundation of NON-need.

Dear Dave,

Each group sees need differently.  The need driving DMARC was to prevent recipients being flooded by an onslaught of transactional phishing attempts that also involved establishing improved feedback to facilitate take-downs.  Without this protection, there would be a high rate of customer loss, at least according to numbers provided by PayPal.  They felt handling their domain's email policy by setting up arrangements with each ESP did not scale.

That said, DMARC was never intended to address needs beyond the narrow scope of high value transactional email. There were early warning signs as well. Even Paypal employees initially posted to mailing-lists in clear conflict with their DMARC policy.  That behavior was then replaced by linkedin.com, e-ngine.nl, junc.eu, and yahoo.com.  There should have been clear warnings rather than expecting ESPs to deal with a flood of complaints.  

There is not enough header or transactional bandwidth to expect each email to authorize individual third-parties.  The original TPA specification would have been able to address this with very low overhead.  Is it reasonable to expect user desired third-party services to carry a high cryptographic burden for each unique message destination.  It seems better to expect these services to simply verify their domain by currently available means.  It is also common to find List-ID header fields declaring the path taken that can also be specified using TPA. TPA use could the be declared in conjunction with DMARC to allow each domain seeking protection from DMARC to make specific exceptions and effectively react to abuse.

Had SMTP been properly federated, none of this would have become a problem, and it would have also avoided pervasive monitoring. 

Regards,
Douglas Otis