Re: [Endymail] FW: Group/Enterprise encrypted email

Trevor Freeman <trevor.freeman99@icloud.com> Thu, 04 June 2015 18:54 UTC

Return-Path: <trevor.freeman99@icloud.com>
X-Original-To: endymail@ietfa.amsl.com
Delivered-To: endymail@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D738E1A88A1 for <endymail@ietfa.amsl.com>; Thu, 4 Jun 2015 11:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.501
X-Spam-Level:
X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 h1JnPEuKPhbz for <endymail@ietfa.amsl.com>; Thu, 4 Jun 2015 11:54:06 -0700 (PDT)
Received: from mr11p24im-asmtp002.me.com (mr11p24im-asmtp002.me.com [17.110.78.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 356B91A8869 for <endymail@ietf.org>; Thu, 4 Jun 2015 11:54:06 -0700 (PDT)
Received: from denhp (c-24-17-210-106.hsd1.wa.comcast.net [24.17.210.106]) by mr11p24im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NPF00I8SOI35000@mr11p24im-asmtp002.me.com> for endymail@ietf.org; Thu, 04 Jun 2015 18:54:05 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-06-04_14:2015-06-03,2015-06-04,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1506040242
From: Trevor Freeman <trevor.freeman99@icloud.com>
To: "'Nordgren, Bryce L -FS'" <bnordgren@fs.fed.us>, 'Phillip Hallam-Baker' <phill@hallambaker.com>
References: <82E7C9A01FD0764CACDD35D10F5DFB6E7DFBBD@001FSN2MPN1-046.001f.mgd2.msft.net> <000d01d09cef$76039f10$620add30$@icloud.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7E1094@001FSN2MPN1-046.001f.mgd2.msft.net> <007001d09e27$3c3083f0$b4918bd0$@icloud.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7E154A@001FSN2MPN1-046.001f.mgd2.msft.net> <CAMm+Lwgk9pMdURgNg=vvSbwNkQw_Q9Qmn=bgExU7Mqdvsun_DA@mail.gmail.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7E159E@001FSN2MPN1-046.001f.mgd2.msft.net> <CAMm+Lwikmt--GVVT_UPYjY5WcxcBJ_2geg5EkA47F7=gp-sYww@mail.gmail.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7E1614@001FSN2MPN1-046.001f.mgd2.msft.net>
In-reply-to: <82E7C9A01FD0764CACDD35D10F5DFB6E7E1614@001FSN2MPN1-046.001f.mgd2.msft.net>
Date: Thu, 04 Jun 2015 11:54:05 -0700
Message-id: <004901d09ef7$d5a893d0$80f9bb70$@icloud.com>
MIME-version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-index: AQI4r1yN6a8adADhwF3Fb1Vfc9FNLwJxMimUAfuiTKACF+YyqAEv4b4IAXOSVw0C5yq6lgIS6/KbAeXXBV6cTEZwoA==
Content-language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/endymail/TlIoNiJFTndSdjWSkDs0cg2YVlc>
Cc: endymail@ietf.org
Subject: Re: [Endymail] FW: Group/Enterprise encrypted email
X-BeenThere: endymail@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <endymail.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/endymail>, <mailto:endymail-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/endymail/>
List-Post: <mailto:endymail@ietf.org>
List-Help: <mailto:endymail-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/endymail>, <mailto:endymail-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jun 2015 18:54:08 -0000

Hi Bryce,
I am not quite sure why you keep asserting Plasma is attempting DRM when it's not. All its doing is providing the same access controls for email content as the same content is published via the web - and why should an organization expect anything less. It help the sender make sure that recipients are entitled to receive the information and that the sender has complied with the information protection policy for the information in the email. Unlike DRM, Plasma does not raise expectations that the recipient does the right thing with the information. Plasma did show it is possible to provide additional controls to ensure it is appropriate only disseminate the decryption keys when policy has been satisfied. We do not set expectations beyond that because the only strong control is the act of releasing the decryption key. In the Plasma PoC we showed it was possible to drive Plasma via a simple combo box selection as a one stop shop which hid the specifics of each policy. One of the vendors who participated in the project also did a user trial to test Plasma against the check box options of today and we got back positive results that user preferred Plasma to the encrypt message check box.

Trevor

-----Original Message-----
From: Endymail [mailto:endymail-bounces@ietf.org] On Behalf Of Nordgren, Bryce L -FS
Sent: Wednesday, June 03, 2015 3:20 PM
To: Phillip Hallam-Baker
Cc: Trevor Freeman; endymail@ietf.org
Subject: Re: [Endymail] FW: Group/Enterprise encrypted email


>Trying to absolutely control the flow of information has a lousy track record. 
>And not just in the US but FOIA means that the US examples are rather 
>more obvious. Trying to lock everything down resulted in security 
>systems so complicated, even an MIT professor was unable to figure them out when he was made CIA director.

>The lesson we have learned is that imperfect security systems that are 
>acceptable to end users are much more effective than theoretically 
>perfect schemes that users bypass. It is possible that the US federal govt. will learn the same lesson someday.
> If they ever do, they know where to look.

I think we are in agreement that top down micromanagement of information flow is bad. My comments are intended to align the language in the doc with the actual security provided, not cause anyone to fix perceived security holes. :) It does very much read like the intent is to set up a DRM such that conforming systems provide certain guarantees. It shouldn't.

I'm not certain I've been persuaded that the DRM-esque aspects are worthwhile. Sticking with normal, un-augmented email semantics simplifies this proposal to the point that implementers may be able to make the encryption process completely transparent to users, or at least boil it down to a checkbox. Much of the value associated with generalizing the available policies beyond "encrypt this message and disseminate keys to the email recipients" seems to be predicated on prose making guarantees of policy enforcement across organizational boundaries. A very much clearer and more precise value statement is warranted.

Perhaps this is answered in that other spec, but I don't yet see how the mail client knows what parameters are expected by the policy. Does it need to understand and implement a UI for some sort of policy schema language?

Best,
Bryce
_______________________________________________
Endymail mailing list
Endymail@ietf.org
https://www.ietf.org/mailman/listinfo/endymail