Re: [dispatch] Work for IETF114
John C Klensin <john-ietf@jck.com> Fri, 10 June 2022 15:07 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE684C157B52 for <dispatch@ietfa.amsl.com>; Fri, 10 Jun 2022 08:07:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GC887ctSl5eU for <dispatch@ietfa.amsl.com>; Fri, 10 Jun 2022 08:07:06 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43BF6C15AAF8 for <dispatch@ietf.org>; Fri, 10 Jun 2022 08:07:05 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1nzgE4-0002kN-73; Fri, 10 Jun 2022 11:07:04 -0400
Date: Fri, 10 Jun 2022 11:06:58 -0400
From: John C Klensin <john-ietf@jck.com>
To: Bron Gondwana <brong@fastmailteam.com>
cc: dispatch@ietf.org
Message-ID: <F43BDC96CB68396AECE8E2B5@PSB>
In-Reply-To: <ec38343d-6c89-4c8a-82c0-484375bd89b1@www.fastmail.com>
References: <ec38343d-6c89-4c8a-82c0-484375bd89b1@www.fastmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/rDkvD03SmPhqLwQWR4s7Ag8LmGA>
Subject: Re: [dispatch] Work for IETF114
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jun 2022 15:07:11 -0000
Bron, I've looked at the abstracts of, but have not studied, the material Julian pointed to, but I believe I'd think about this is a different way. For starters, if the content/information is important enough to encrypt, your probably want it to land on the recipient's machine (or at least the recipient's mail server) encrypted, without the server decrypting what it should not see before sending, without depending on TLS. If one starts there, whether the data are transferred to the recipient over HTTPS or over email is a matter of taste, size considerations, etc. If that is the case, then think about this as mostly an MUA problem, possibly with a near-trivial browser extension. Certainly worth a discussion at DISPATCH or a bit of brainstorming in ARTArea. Without having thought carefully about this, I'd think about something like a trick URI type, one that might look something vaguely like: ENCRYPTEDFILE://SomeDomain/key/URL-of-server-and-location/ where "SomeDomain" would normally be local, or somewhere trusted with the key and to safely transfer it, or maybe a new Well-Known type. The local UA (MUA or Browser) would interpret that URI as telling it to get and temporarily store the key, then use https://URL-of-server-and-location/ to pick up the content, decrypt locally, etc. Obviously there are lots of variations on syntax and details, but that would seem like a reasonable general approach and one that would be easier to deploy than anything requiring complex interactions with servers. If anyone cared about or supported message/external-body, it could be handled as a reasonable variation on that theme too. Sadly, your note comes a month or two late because the person who would be best at thinking about the issue would have been the late Ned Freed. best, john --On Friday, June 10, 2022 23:22 +1000 Bron Gondwana <brong@fastmailteam.com> wrote: > Yep, me again with something new that's bubbling up out of the > "large files over email" problem. > > I'm not quite sure the shape of this, but I'd like some time > to talk about something which might be a media type, might be > a URI scheme, might be... I dunno. I'm sure the group will > have zillions of opinions about both what the work should be, > and what it should look like. I can give you the user > experience and use-case that I want anyway. > > ... > > Use case: user wants to store a file encrypted on a server, > and provide a link such that their recipient can get the > decrypted file, without the server ever seeing the plaintext > content. > > Which basically means - the URL/URI that the sender provides > to the recipient contains the key data to decrypt the content, > encoded into the URI in such a way that it's not provided to > the server. There are pros and cons of different approaches, > but ideally the operating system / browser / library > transparently does the decryption as part of the fetching such > that a piece of client software doesn't care if the data is > stored in plaintext and transferred over HTTPS (or whatever), > or stored encrypted on the server with zero knowledge - either > way the client program / library gets the raw data plaintext > and doesn't have to care what the sender intended. > > Obviously, this only works if the recipient supports it, so > bootstrapping is going to be a pain. But I haven't seen > something like this existing, and it would be SOOOOOO much > nicer to have this transparently able to be embedded in the > URI and handled by lower levels rather than having to design > and specify an optional encryption layer in the email large > file handling stuff. > > ... > > I'll put together a better proposal in the next couple of > weeks, but just requesting the agenda time now :) > > And I would LOVE it if someone already knows that such a thing > exists and can point me to it instead of having to reinvent > the wheel. > > Cheers, > > Bron. > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com >
- [dispatch] Work for IETF114 Bron Gondwana
- Re: [dispatch] Work for IETF114 Julian Reschke
- Re: [dispatch] Work for IETF114 John C Klensin
- Re: [dispatch] Work for IETF114 Tim Bray
- Re: [dispatch] Work for IETF114 message external … John Levine
- Re: [dispatch] Work for IETF114 message external … John C Klensin
- Re: [dispatch] Work for IETF114 worley
- Re: [dispatch] Work for IETF114 Mark Nottingham
- Re: [dispatch] Work for IETF114 Tim Bray
- Re: [dispatch] Work for IETF114 Martin Thomson
- Re: [dispatch] Work for IETF114 Tim Bray
- Re: [dispatch] Work for IETF114 Martin Thomson
- Re: [dispatch] Work for IETF114 Bron Gondwana
- Re: [dispatch] Work for IETF114 Richard Barnes
- Re: [dispatch] Work for IETF114 Richard Barnes