Re: [lamps] S/MIME fix

Russ Housley <housley@vigilsec.com> Thu, 17 May 2018 14:02 UTC

Return-Path: <housley@vigilsec.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 394E2126D0C for <spasm@ietfa.amsl.com>; Thu, 17 May 2018 07:02:00 -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 1zzssmaZOt0d for <spasm@ietfa.amsl.com>; Thu, 17 May 2018 07:01:58 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC88A12783A for <SPASM@ietf.org>; Thu, 17 May 2018 07:01:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9CB3E3009FF for <SPASM@ietf.org>; Thu, 17 May 2018 10:01:56 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uQh_TYCKv93r for <SPASM@ietf.org>; Thu, 17 May 2018 10:01:51 -0400 (EDT)
Received: from new-host.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id BCFE130044B; Thu, 17 May 2018 10:01:51 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <e678276f-79c2-ec3c-7df5-f70794740f77@nostrum.com>
Date: Thu, 17 May 2018 10:01:52 -0400
Cc: SPASM <SPASM@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <AB332E06-E1F5-4E82-9EF8-B49846865DAC@vigilsec.com>
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> <e678276f-79c2-ec3c-7df5-f70794740f77@nostrum.com>
To: Adam Roach <adam@nostrum.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/KQgi4G8JrEZ4j-4S0otoGyPAMyk>
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: Thu, 17 May 2018 14:02:00 -0000

Adam:
> 
> 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>.

I see the parallel, and in fact, the biggest problem is the use of HTML that includes a reference to something that is outside the message itself.

> 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).

I am not following you.  I do not see the requirement to do anything with webcrypto.  However, I completely agree with the need to isolate each portion of the multi-part.

Russ