Re: [Shutup] [ietf-smtp] Proposed Charter for something

Chris Lewis <ietf@mustelids.ca> Mon, 07 December 2015 19:41 UTC

Return-Path: <ietf@mustelids.ca>
X-Original-To: shutup@ietfa.amsl.com
Delivered-To: shutup@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E9A1A6FE9; Mon, 7 Dec 2015 11:41:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.043
X-Spam-Level: ***
X-Spam-Status: No, score=3.043 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=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 9z0MJPjINfd0; Mon, 7 Dec 2015 11:41:16 -0800 (PST)
Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 176201A6FE5; Mon, 7 Dec 2015 11:41:15 -0800 (PST)
Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB7JfDh1022221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 7 Dec 2015 14:41:14 -0500
To: ietf-smtp@ietf.org, shutup@ietf.org
References: <20151207023426.54934.qmail@ary.lan> <56656482.7090900@cs.tcd.ie>
From: Chris Lewis <ietf@mustelids.ca>
X-Enigmail-Draft-Status: N1110
Message-ID: <5665E0D9.1050102@mustelids.ca>
Date: Mon, 07 Dec 2015 14:41:13 -0500
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
In-Reply-To: <56656482.7090900@cs.tcd.ie>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/shutup/giAY8sT6nlsuGnhbvg4fJLfjeVw>
Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for something
X-BeenThere: shutup@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SMTP Headers Unhealthy To User Privacy <shutup.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/shutup>, <mailto:shutup-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/shutup/>
List-Post: <mailto:shutup@ietf.org>
List-Help: <mailto:shutup-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shutup>, <mailto:shutup-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2015 19:41:17 -0000

On 12/07/2015 05:50 AM, Stephen Farrell wrote:
>
>
> On 07/12/15 02:34, John Levine wrote:
>> This is increasingly looking like a RG, not a WG.
>
> Hmm, not sure. A good RG is one that'd attract an active
> research community and be relatively long lived whereas
> this seems like a bit of work where we need to do a relatively
> small and discrete amount of research on one topic. (Which
> is roughly "What'd happen if you mucked with received headers
> the MSA passes on to the rest of the mail infrastructure?")
>
> The way I think of it is a good RG would produce a stream
> of academic publications and then some stuff that'd be of
> use to the IETF. This sounds more like one paper's worth
> of research then stuff would be done in the IETF or not,
> depending on the findings.

One could envision a RG constituted to long-term specifically work on 
privacy implications of IETF RFCs in general, with a view towards 
improving privacy via future RFCs.  There is at least some precedent 
given the requirements about security area oversight of new RFCs, and 
the required SECURITY sections of RFCs now.  Which would be a "good 
thing", but huge, unwieldy, and perhaps unsustainable long-term (given 
that most people may only have narrow topic-area interests).

You could, instead, have it focus on specific areas for periods of time. 
  Like, "today SMTP, 6 months from now web" etc.  May still be 
unwieldy/ineffective for the same reasons.

Or finally, make it narrow - "RG on email privacy leakage" - a WG with a 
stronger research/analysis mandate.

OTOH, if we stayed with the WG approach, the mandate still has to be 
adjusted to do the research for guiding output documents w.r.t. privacy 
vs other tradeoffs.

I'm tending more towards RG on email privacy leakage.  Even just a 
document outlining where the potential leaks are, and outlining the 
threat landscape tradeoffs (both privacy and other) of 
eliding/not-eliding the info.

So put me up as a strongish vote for a narrow RG.