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 01:05 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 448D912B16C; Mon, 12 Sep 2016 18:05:49 -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 SOxGRoJa0Kwv; Mon, 12 Sep 2016 18:05:47 -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 2C79512B15F; Mon, 12 Sep 2016 18:05:43 -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 1bjcAQ-000KFB-0t; Mon, 12 Sep 2016 21:05:42 -0400
Date: Mon, 12 Sep 2016 21:05:37 -0400
From: John C Klensin <klensin@jck.com>
To: ietf@ietf.org
Subject: Re: Last Call: <draft-levine-herkula-oneclick-04.txt> (Signalling one-click functionality for list email headers) to Proposed Standard
Message-ID: <B717E322B172FC10398721BE@JcK-HP8200>
In-Reply-To: <147369951847.3676.9919080158898452438.idtracker@ietfa.amsl.com>
References: <147369951847.3676.9919080158898452438.idtracker@ietfa.amsl.com>
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/5gWPywHcVqFCD2xuNvn7tD2xu30>
Cc: alexey.melnikov@isode.com, paulkincaidsmith@gmail.com, draft-levine-herkula-oneclick@ietf.org
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 01:05:49 -0000
--On Monday, September 12, 2016 09:58 -0700 The IESG <iesg-secretary@ietf.org> wrote: > > The IESG has received a request from an individual submitter > to consider the following document: > - 'Signalling one-click functionality for list email headers' > <draft-levine-herkula-oneclick-04.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and > solicits final comments on this action. Please send > substantive comments to the ietf@ietf.org mailing lists by > 2016-10-10. Hi. I've looked through this and find it a little troubling, partially because I don't like the problem rather than not liking the details of the solution. I've seen deliberate attempts to disrupt mailing lists by unsubscribing participants. While crude, a message to a user asking for verification of intent to unsubscribe is an important protection against that behavior. Similarly, having anti-spam system follow/execute links in headers (as distinct from links in message bodies) seems like a bad idea generally, but verification messages or other two-step processes are an important protection against accidental (but, IMO, badly designed) or malicious bad behavior. So this specification proposed a way to bypass those safeguards and protection? I'm not convinced that is a good idea and what the document has to say about it is "This document does not address problems associated with deliberate malicious behavior." That seems to me to be equivalent to "we don't need to worry about bad guys because they will never attempt to use this feature". Really? The one protection that it offers is DKIM verification of the sending domain and headers. That is fine, modulo all of the concerns about how easy DKIM is to spoof and the observation that it really just validates a sending domain. However, consider the following case, remembering that a message for which this is relevant should be coming from a mailing list: ... MAIL FROM:<evildoer@example.com> RCPT TO:<sucker@example.net> ... From: evildoer@example.com To: ietf@ietf.org ... DKIM-Signature: ...; d=ietf.org; ... h=From:...:List-Unsubscribe:List-Unsubscribe-Post:... ... List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe> List-Unsubscribe-Post: List-Unsubscribe=One-Click&recip=sucker@example.net Now the signature verifies just fine because the message was sent from example.com, and the MUA promptly issues a POST that removes poor Sucker from the IETF list. Even more interesting, consider what happens if the last line of that example is List-Unsubscribe=One-Click&recip=victim@example.org Unless I've misunderstood this feature, unless the list manager does some checking --several versions of which checking this mechanism is designed to eliminate or forbid-- the MUA (or delivery server or anti-spam mechanism) associated with sucker@example.net promptly unsubscribes victim@example.org from the IETF list. Without studying the spec further, I'm not sure how much this would help, but I'd expect to see at least a check that the DKIM-signed sender domain for the list manager matches the domains in the List-Unsubscribe field. Without that check, this seems far too hazardous, even with a disclaimer that malicious behavior is out of scope. I do wonder about other topic areas in which one could create an I-D and propose it for Standards Track by putting a short section in the middle that says "This document does not address...deliberate malicious behavior" and thereby avoid the tedious and time-consuming requirement of BCP 72 to describe what can go wrong with various types of easily-predicted attacks. 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