Re: Last Call: <draft-levine-herkula-oneclick-04.txt> (Signalling one-click functionality for list email headers) to Proposed Standard

John C Klensin <klensin@jck.com> Tue, 13 September 2016 03:16 UTC

Return-Path: <klensin@jck.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 4DF1512B1BC for <ietf@ietfa.amsl.com>; Mon, 12 Sep 2016 20:16:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.408
X-Spam-Level:
X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=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 ratHqhfPZ9bX for <ietf@ietfa.amsl.com>; Mon, 12 Sep 2016 20:16:00 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A386712B1A8 for <ietf@ietf.org>; Mon, 12 Sep 2016 20:16:00 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <klensin@jck.com>) id 1bjeCT-000Kdh-53; Mon, 12 Sep 2016 23:15:57 -0400
Date: Mon, 12 Sep 2016 23:15:52 -0400
From: John C Klensin <klensin@jck.com>
To: "John R. Levine" <johnl@iecc.com>
Subject: Re: Last Call: <draft-levine-herkula-oneclick-04.txt> (Signalling one-click functionality for list email headers) to Proposed Standard
Message-ID: <9B3EC0D54665BEDE8495E629@JcK-HP8200>
In-Reply-To: <alpine.OSX.2.11.1609122139220.63493@ary.local>
References: <147369951847.3676.9919080158898452438.idtracker@ietfa.amsl.com> <B717E322B172FC10398721BE@JcK-HP8200> <alpine.OSX.2.11.1609122139220.63493@ary.local>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: klensin@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/lpmlO25k3fMgBUfVOOjWBjAvUgk>
Cc: alexey.melnikov@isode.com, IETF general list <ietf@ietf.org>, tobias.herkula@optivo.de, Paul Kincaid-Smith <paulkincaidsmith@gmail.com>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 13 Sep 2016 03:16:02 -0000


--On Monday, September 12, 2016 21:45 -0400 "John R. Levine"
<johnl@iecc.com> wrote:

>> important protection against accidental (but, IMO, badly
>> designed) or malicious bad behavior.   So this specification
>> proposed a way to bypass those safeguards and protection?
> 
> No, of course not.  The unsubscribe links in the mail this
> will affect are invariably unique to the message's recipient
> with a hard to forge hash of some sort.  So if you have the
> message, you are the subscriber or the subscriber gave the
> message to you.

But that doesn't show up in your the examples and, as far as I
can tell from quick reading, there is nothing in the text that
says "the unsubscribe links need to contain a hard to forge hash
or this would be a really bad idea" or something equivalent.
My guess is that this would be harmless at worst if the security
and operational issues were spelled out, but they aren't.

AFAICT, such a hash would be a better solution than the weaker
one I was contemplating with DKIM, so there may be just a
documentation problem rather than a technical one.

> I've talked at some length to the people at Gmail who plan to
> implement this, and they've clearly dealt with more mail
> forgery than any of us.

Ah.   That may suggest the disconnect we are having lies
somewhere other than in what I assumed.   This document appears
to have been written for Standards Track and the Last Call is
for publishing it as a Proposed Standard.  That implies at least
a plausible assumption or realistic hope that it will be
implemented and deployed by multiple independent parties.  For
that purpose, it just isn't complete and doesn't contain enough
information, with that issue about hashes as one example,
perhaps among many.   

If you want to see this as a Proposed Standard, then I think
there needs to be enough information, clearly spelled out, to
let people implement it in a way that is both interoperable and
safe.

The other possibility is that this is a Gmail idea or plan and
the real purpose of publication is to register a new header
field and tell MUA authors what they should do if they get some
fields Gmail is about to start producing.  That would make a
perfectly sensible Informational document that could be
descriptive rather than normative about what they sender/
mailing list software does and only use more or less the current
text to specify what the recipient/ would-be unsubscriber does.
You could probably even submit it through the Independent Stream
and try to convince the ISE to accept Section 4 or a variation
on it -- I believe that section and the narrowly-focused
Security Considerations one that results violates the intent and
requirements of BCP 72 that apply, AFAICT, to all IETF Stream
technical specifications.

    john