Re: [Extra] Ben Campbell's Discuss on draft-ietf-extra-sieve-fcc-08: (with DISCUSS and COMMENT)
Ben Campbell <ben@nostrum.com> Thu, 10 January 2019 22:16 UTC
Return-Path: <ben@nostrum.com>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C71131285 for <extra@ietfa.amsl.com>; Thu, 10 Jan 2019 14:16:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.679
X-Spam-Level:
X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
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 Tv2OhlrkKLcs for <extra@ietfa.amsl.com>; Thu, 10 Jan 2019 14:16:36 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5193313127E for <extra@ietf.org>; Thu, 10 Jan 2019 14:16:36 -0800 (PST)
Received: from [10.0.1.45] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0AMGX2A015777 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 10 Jan 2019 16:16:34 -0600 (CST) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1547158595; bh=1/FAi1I6j2qFPBcfG1Oni1pZzQJUTCB84yyD5ZpPXPk=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=kdLoJ3buK4EtuxM1/qwRuXE8lGOnP/3EdiyeV1EDqR+sj9PhukzTo9Nf+y9XwXP8F 1mBBAjMj7mjMjxfGSBFdBQ92Zj+Q9GR5B7zkWd0GiW+dv6dILYTbaIISXOUq0JNPRR KjjDAh0BL4MoNnn8ZqTvYr+tiuW2z8TeN6lUxinA=
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.45]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <47A55584-25D5-409A-B5D0-884A9F8FAA30@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_E61AA3E3-2C02-4FF3-A074-80DCA8C0578E"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 10 Jan 2019 16:16:32 -0600
In-Reply-To: <01R1UIX3NK2M00004L@mauve.mrochek.com>
Cc: draft-ietf-extra-sieve-fcc@ietf.org, Alexey Melnikov <aamelnikov@fastmail.fm>, extra@ietf.org, yaojk@cnnic.cn, The IESG <iesg@ietf.org>, extra-chairs@ietf.org
To: Ned Freed <ned.freed@mrochek.com>
References: <154707068927.5028.9965727374137648132.idtracker@ietfa.amsl.com> <553C69A0-9D9F-45F7-9586-B0BD71DF2661@fastmail.fm> <9DF727DF-068E-437D-B8E1-D3A71A087DE3@nostrum.com> <01R1UIX3NK2M00004L@mauve.mrochek.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/TvOU3X2ppVblCKc-3K5LZ-RvQKU>
Subject: Re: [Extra] Ben Campbell's Discuss on draft-ietf-extra-sieve-fcc-08: (with DISCUSS and COMMENT)
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Jan 2019 22:16:38 -0000
> On Jan 10, 2019, at 11:53 AM, Ned Freed <ned.freed@mrochek.com> wrote: > > > >>> On Jan 10, 2019, at 2:42 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote: >>> >>> Hi Ben, >>> >>>> On 9 Jan 2019, at 21:51, Ben Campbell <ben@nostrum.com> wrote: >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> Thanks for the work on this. I plan to ballot "yes", but have one item I think >>>> needs to be discussed first: >>>> >>>> The security considerations say that this extension adds no new considerations >>>> not already present in [RFC5228], [RFC5230], [RFC5435], and [RFC6131]. I'm not >>>> sure that that is true. >>>> >>>> It seems like the ability to insert a copy of message into a mailbox might have >>>> security and/or privacy considerations. >>> >>> Can you give me an idea of what you have in mind here, other than putting the user (Sieve script owner) over quota? > >> I can’t say that I know what the security considerations might be; I’m >> just skeptical that the answer is “no new considerations." > > I think this is demonstrably true. > > I'll first note that in terms of the sorts of messages it is capable of > generating, the enotify extension with mailto: is effectively a superset of > vacation. (Vacation is much more convenient to use and includes some additional > builtin checks, but these aren't relevant here.) > > So it suffices to consider the notify :fcc case. > > Now compare the following sieves, each belonging to bob@example.com: > > [1] > > require ["enotify", "fcc"]; > notify :fcc "INBOX.Sent" :message "Bob got mail!" "mailto:ken@example.com"; > > [2] > > require ["enotify", "fileinto"]; > if header :is "subject" "Bob got mail!" { > fileinto "INBOX.Sent"; > } > else { > notify :message "Bob got mail!" "mailto:ken@example.com?to=bob@example.com"; > } > > In case this isn't clear, the first script uses :fcc to make a copy of the > notification and file it while the second uses a second notification recipient, > test, and a fileinto to make the copy and file it. The results will likely > differ in minor ways, e.g., Received: fields will probably be different, but > since :fcc is constrained to have essentially the same semantics as fileinto, > the security considerations aren't going to differ much if at all. > > The use of :fcc with actions defined in the future may result in additional > security considerations, but we won't know what those are until it happens. > I absolutely agree the security considerations for fcc are similar, perhaps identical, to those for fileinto. > Of course this also sidesteps the issue of whether or not the security > considerations for fileinto are properly documented. That is my concern. > >> The authors of >> 5228 thought “fileinto” could be dangerous. Do we know why? > > Yes, but I doubt you'll care for the answer much. (I certainly don't.) First, > it's pretty obvious that there are risks with using fileinto. Off the top of my > head: > > (1) Lost messages. An incorrectly set up fileinto, or a correct one that's > set up and then forgotten can result in important messages being put in a > place where nobody bothers to look. > > (2) Excessive disk usage. Lots of sites have automatic rules for cleaning out > unread messages from commonly used mailboxes like INBOX or Junk. However, > the assumption tends to be that since other folders have to be set up > manually that they should have longer expiration times or not be subject > to expiration policies at all. > > (3) Breaking non-idempotent workflows. Fileinto can be used to create > additional copies of messages, and this can have bad effects on > processors (including people) that fail to check for duplicates. > > (4) Creating large numbers of mailboxes. Combine fileinto and Sieve > variables with a bit of carelessness, and you can achieve some > spectacular results. Example: > > require ["fileinto", "variables"]; > # File tagged list mail in an appropriate folder. > if header :matches "subject" "*[*]*" { fileinto "List-${2}"; } > > (I note that this issue is described in more general terms in RFC 5229.) > > And so on. Similar lists can also be constructed for discard, redirect, > ereject, etc. > > But here's the thing: Are these really the sorts of things that need to be > listed in a security considerations section? I don’t think they all are. I’m primarily concerned about things that could unintentionally expose information to third parties. I guess data loss could be a secondary concern, but I’m not as concerned about that. In email discussion so far, the only things that have come up that seem to fit that is filing into a shared mailbox, or into a mailbox that is otherwise not well protected. > Sure, they all have potential > security ramifications, but the common factor in all of these is that somebody > did something dumb. And the list of dumb things is effectively endless. Do we > need to caution against having > > discard; > > or > > require "fileinto"; fileinto "Junk"; > > as your entire Sieve script? And if not, where do we draw the line? > > And perhaps more to the point, there's little if anything a Sieve implementer > can do to prevent people from doing dumb things. In every case I've listed > above - including the last two examples - there's a legitimate use-case that > isn't dumb. > > Note: Speaking as someone who supports a Sieve implementation, users definitely > do dumb things with sieves on a regular basis. In fact if I could add one > recommendation to the base document, it would be that Sieve implementations > running at or just before final delivery SHOULD log all actions the user' Sieve > takes. Including explicit keep. Logging makes it possible to tell users what > happened, and in most cases why. Of course the log then has privacy issues ... > > Even worse, we've now opened the door to a bunch of meta-issues that are well > known to be ratholes: Exactly who is the target audience for security > considerations? Where do we draw the line between "Obvious problem but > sufficiently dangerous to be worth belaboring" and "Duh!!!"? Etc. > > And this brings us back to what's in RFC 5228. What's in there and what's not > is a result of the fact that the process that produced that text in both RFC > 3228 and 5228 was - and I'm being generous here - distinctly suboptimal. > > I don't think it's productive to get into the specifics of what went wrong, so > let me just say that ratholes were involved, and by the time we extricated > ourselves from those there was neither sufficient energy nor sufficient > patience to try and flesh out what dangerous aspects of various actions needed > to be discussed and which ones didn't. So we stuck in a dangerous bend sign and > left it at that. > My point was not to do a post-mortum on 5228, or to try to fix it. I’m only concerned about any issue there to the extent that _this_ draft relies on it. > In any case, while I acknowledge that the security considerations in RFC 5228 > could and should be improved, I think doing so in a document that provides - > let's face it - a power user feature and which is therefopre unlikely to be > consulted by base specification implementors doesn't meet a cost-benefit > analysis. I therefore support the text Alexey has suggested which I think goes > just far enough. I think it’s likely that I agree; which text that Alexey suggested do you refer to? If it’s down to mentioning shared mailboxes and moving on, I’m fine with it at this point. Thanks! Ben.
- [Extra] Ben Campbell's Discuss on draft-ietf-extr… Ben Campbell
- Re: [Extra] Ben Campbell's Discuss on draft-ietf-… Alexey Melnikov
- Re: [Extra] Ben Campbell's Discuss on draft-ietf-… Ben Campbell
- Re: [Extra] Ben Campbell's Discuss on draft-ietf-… Alexey Melnikov
- Re: [Extra] Ben Campbell's Discuss on draft-ietf-… Ben Campbell
- Re: [Extra] Ben Campbell's Discuss on draft-ietf-… Alexey Melnikov
- Re: [Extra] Ben Campbell's Discuss on draft-ietf-… Ben Campbell
- Re: [Extra] Ben Campbell's Discuss on draft-ietf-… Alexey Melnikov
- Re: [Extra] Ben Campbell's Discuss on draft-ietf-… Ben Campbell
- Re: [Extra] Ben Campbell's Discuss on draft-ietf-… Ned Freed
- Re: [Extra] Ben Campbell's Discuss on draft-ietf-… Ben Campbell
- Re: [Extra] Ben Campbell's Discuss on draft-ietf-… Ned Freed
- Re: [Extra] Ben Campbell's Discuss on draft-ietf-… Ben Campbell
- Re: [Extra] Ben Campbell's Discuss on draft-ietf-… Ken Murchison