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
- Re: [lamps] S/MIME fix Alexey Melnikov
- [lamps] S/MIME fix Phillip Hallam-Baker
- Re: [lamps] S/MIME fix Alexey Melnikov
- Re: [lamps] S/MIME fix Jim Schaad
- Re: [lamps] S/MIME fix Phillip Hallam-Baker
- Re: [lamps] S/MIME fix Alexey Melnikov
- Re: [lamps] S/MIME fix Tim Hollebeek
- Re: [lamps] S/MIME fix Phillip Hallam-Baker
- Re: [lamps] S/MIME fix Stephen Farrell
- Re: [lamps] S/MIME fix Adam Roach
- Re: [lamps] S/MIME fix Tim Hollebeek
- Re: [lamps] S/MIME fix Stephen Farrell
- Re: [lamps] S/MIME fix Russ Housley
- Re: [lamps] S/MIME fix Russ Housley
- Re: [lamps] S/MIME fix Adam Roach
- Re: [lamps] S/MIME fix Phillip Hallam-Baker
- Re: [lamps] S/MIME fix Adam Roach
- Re: [lamps] S/MIME fix Ryan Sleevi
- Re: [lamps] S/MIME fix Russ Housley
- Re: [lamps] S/MIME fix Ryan Sleevi
- Re: [lamps] S/MIME fix Phillip Hallam-Baker
- Re: [lamps] S/MIME fix Phillip Hallam-Baker
- Re: [lamps] S/MIME fix Russ Housley