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

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 20 September 2016 03:16 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 CCF7812B5F2 for <ietf@ietfa.amsl.com>; Mon, 19 Sep 2016 20:16:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 CLd8KBmgn8QQ for <ietf@ietfa.amsl.com>; Mon, 19 Sep 2016 20:16:39 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A598112B5DC for <ietf@ietf.org>; Mon, 19 Sep 2016 20:16:39 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id C0293284ADC for <ietf@ietf.org>; Tue, 20 Sep 2016 03:16:37 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: Last Call: <draft-levine-herkula-oneclick-04.txt> (Signalling one-click functionality for list email headers) to Proposed Standard
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <20160920023615.83210.qmail@ary.lan>
Date: Mon, 19 Sep 2016 23:16:36 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <4CEBA33A-6E57-4121-AC9D-9A2A9528E2B2@dukhovni.org>
References: <20160920023615.83210.qmail@ary.lan>
To: ietf@ietf.org
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/_qawlYQZ5tNYRMLcGWifJcxKlWE>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: ietf@ietf.org
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, 20 Sep 2016 03:16:42 -0000

> On Sep 19, 2016, at 10:36 PM, John Levine <johnl@taugh.com> wrote:
> 
>> If they DoS a few spammers, seems like a win... :-)  In any case,
>> there's no need for this as a motivation in the RFC.
> 
> I wouldn't disagree, except that the reason it's there is about six messages
> ago people were complaining that I didn't explain why you had to use https
> rather than mailto.

I think there is a better reason to use HTTP(S) rather then email.

   * Immediate success/fail feedback with lower resource cost and latency
     for both the client and the server.

>>> That's an implementation detail.  In the most likely implementations,
>>> it's web mail so the MDA and MUA are all the same system.
>> 
>> The requirement for DKIM signing is a mystery in the draft.  If is
>> there, its purpose should be explained.
> 
> Really, it's what I said. It's so receipient systems have a handle to
> evaluate the message.  As you are doubtless aware, MUST means "do this
> if you want to interoperate."  At least one very large mail system has
> told me that they will only do one-click on signed mail.  So senders
> MUST sign it so they can, you know, interoperate.

The draft fails to explain that this is *sender* obligation.

   The email needs at least one valid authentication identifier.  In
   this version of the specification the only supported identifier type
   is DKIM [RFC6376], that provides a domain-level identifier in the
   content of the "d=" tag of a validated DKIM-Signature header field.

I see no MUST above, nor is it clear that the MUA is not obligated to
check this, but the sender MUST sign, else some MUAs might not honour
the signal.  I honestly had no idea what that paragraph was saying,
until you explained it as a sender obligation in this thread.

>> I think not, "GET" is supposed to not have non-idempotent side-effects.
>> I would strongly suggest that there be a requirement to include an
>> "Origin: mailto:<envelope-sender>" header in the POST, which would
>> indicate to the target webserver that it is dealing with a cross-origin
>> request.
> 
> If you can find a non-trivial mailer who actually wants that, and you
> are offering to update RFC 6454 so that header would be valid, I'd
> consider it.  They've already got the List-Unsubscribe=One-Click if
> they want a clue about why the POST is happening.

I am not talking about mailers wanting or not wanting this.  The issue is
avoiding a cross-origin attack vector.  A malicious sender can
get the MUA to POST arbitrary form content to an arbitrary URL.

If the MUA uses some common HTTP library, the request might end-up
authenticated (cached cookies, client certs, ...).

An "Origin" request header can help the target server identify the
request as a cross-origin request.

   https://www.w3.org/TR/cors/#origin-request-header
   https://tools.ietf.org/html/rfc6454#section-7

If your concern is that the syntax in RFC6454 is "scheme://host"
or "null", which does not include "mailto:address", then "null"
would be an adequate choice, or frankly "mailto://domain" (perhaps
from DKIM rather than the envelope).  In any case the POST specified
in this draft is clearly a cross-origin request, and so I rather think
it needs an "Origin" header.

-- 
	Viktor.