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
- Re: Last Call: <draft-levine-herkula-oneclick-04.… John C Klensin
- Re: Last Call: <draft-levine-herkula-oneclick-04.… John R. Levine
- Re: Last Call: <draft-levine-herkula-oneclick-04.… John C Klensin
- Re: Last Call: <draft-levine-herkula-oneclick-04.… tobias.herkula
- Re: Last Call: <draft-levine-herkula-oneclick-04.… John Levine
- Re: Last Call: <draft-levine-herkula-oneclick-04.… John C Klensin
- Re: Last Call: <draft-levine-herkula-oneclick-04.… John R Levine
- Re: Last Call: <draft-levine-herkula-oneclick-04.… Viktor Dukhovni
- Re: Last Call: <draft-levine-herkula-oneclick-04.… John Levine
- Re: Last Call: <draft-levine-herkula-oneclick-04.… Alexey Melnikov
- Re: Last Call: <draft-levine-herkula-oneclick-04.… Dave Crocker
- Re: Last Call: <draft-levine-herkula-oneclick-04.… Dave Crocker
- Re: Last Call: <draft-levine-herkula-oneclick-04.… Dave Crocker
- Re: Last Call: <draft-levine-herkula-oneclick-04.… Dave Crocker
- Re: Last Call: <draft-levine-herkula-oneclick-04.… John R Levine
- Re: Last Call: <draft-levine-herkula-oneclick-04.… Viktor Dukhovni
- Re: Last Call: <draft-levine-herkula-oneclick-04.… John Levine
- Re: Last Call: <draft-levine-herkula-oneclick-04.… Viktor Dukhovni
- Re: Last Call: <draft-levine-herkula-oneclick-04.… John Levine
- Re: Last Call: <draft-levine-herkula-oneclick-04.… Viktor Dukhovni
- Re: Last Call: <draft-levine-herkula-oneclick-04.… John Levine
- Re: Last Call: <draft-levine-herkula-oneclick-04.… Dave Crocker
- Re: Last Call: <draft-levine-herkula-oneclick-04.… John R Levine
- Re: Last Call: <draft-levine-herkula-oneclick-04.… Viktor Dukhovni
- Re: Last Call: <draft-levine-herkula-oneclick-04.… Dave Crocker
- Re: Last Call: <draft-levine-herkula-oneclick-04.… John R. Levine
- Re: Last Call: <draft-levine-herkula-oneclick-04.… Viktor Dukhovni