Re: [lamps] S/MIME fix

Adam Roach <adam@nostrum.com> Wed, 16 May 2018 22:32 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D7D12D960 for <spasm@ietfa.amsl.com>; Wed, 16 May 2018 15:32:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 cvxE-xK05rQ5 for <spasm@ietfa.amsl.com>; Wed, 16 May 2018 15:32:57 -0700 (PDT)
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 F187B126D05 for <SPASM@ietf.org>; Wed, 16 May 2018 15:32:56 -0700 (PDT)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w4GMWkx5069640 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 16 May 2018 17:32:46 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Phillip Hallam-Baker <phill@hallambaker.com>, Tim Hollebeek <tim.hollebeek@digicert.com>
Cc: SPASM <SPASM@ietf.org>
References: <CAMm+Lwj=VTBHYxH-iOaqEUHxALpBfSXWG3p0+xxUnY+o4CmGvA@mail.gmail.com> <BN6PR14MB1106A2890EE8B9243B4EA08C83920@BN6PR14MB1106.namprd14.prod.outlook.com> <CAMm+LwhuBoQ1VHQy-=E2FODYq4Fnzs8e24Yqyfg4akwQTsqc=w@mail.gmail.com> <1e8468d7-da6c-62f1-e24b-1ee03df22606@cs.tcd.ie>
From: Adam Roach <adam@nostrum.com>
Message-ID: <e678276f-79c2-ec3c-7df5-f70794740f77@nostrum.com>
Date: Wed, 16 May 2018 17:32:41 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <1e8468d7-da6c-62f1-e24b-1ee03df22606@cs.tcd.ie>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/KYfBTyv4ozp6NYV0JzKe9LLQNAQ>
Subject: Re: [lamps] S/MIME fix
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 May 2018 22:32:58 -0000

On 5/16/18 4:16 PM, Stephen Farrell wrote:
> - Designs pre-date web user agent which changes trust model
> (where's the private key kept? Needs new infrastructure)


To understand the challenges surrounding what you suggest, you probably 
want to study the issues surrounding isolated media streams in WebRTC. 
Start by looking at section 4.3.2.4 of draft-ietf-rtcweb-security, and 
then read through <https://www.w3.org/TR/webrtc/#isolated-media-streams>.

To create an analogous situation for secure email, you'd need to use 
webcrypto in a way that stored your private key in the browser 
(inaccessible to the page), and develop web standards that add some 
affordance for web pages to hand encrypted data to the browser in a way 
that causes the corresponding unencrypted data to be displayed to the 
user, but isolated from the web page completely (e.g., rendered into an 
iframe that the parent cannot inspect).

Whether that kind of isolated context for email (which should be usable 
for real-time messaging as well, if done correctly) is reasonable or too 
clunky to work is yet to be seen. (I've had a few conversations that 
concluded "too clunky," but reasonable people may disagree.) In any 
case, the bulk of the work for that kind of system would need to take 
place in the W3C.

There are, of course, possible trade-offs to be made in which the user 
trusts the web-hosted mail service with access to message plain text, or 
even to their private key; but once you take that leap, you're doing 
scantly better than the hop-by-hop security provided by DANE and/or MTA-STS.

/a