[dispatch] Work for IETF114

Bron Gondwana <brong@fastmailteam.com> Fri, 10 June 2022 13:22 UTC

Return-Path: <brong@fastmailteam.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 09F04C15AACD for <dispatch@ietfa.amsl.com>; Fri, 10 Jun 2022 06:22:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=E/mL08eZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cjUBTHEw
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 5UYXJjnCnDLb for <dispatch@ietfa.amsl.com>; Fri, 10 Jun 2022 06:22:32 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54576C15AADA for <dispatch@ietf.org>; Fri, 10 Jun 2022 06:22:32 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id E3FBA5C01B0 for <dispatch@ietf.org>; Fri, 10 Jun 2022 09:22:28 -0400 (EDT)
Received: from imap43 ([10.202.2.93]) by compute4.internal (MEProxy); Fri, 10 Jun 2022 09:22:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm3; t=1654867348; x=1654953748; bh=u/HD7LI5oI Y10LWt1LCkpa4cfWQxW2dO4n0fXRV6Wt4=; b=E/mL08eZdLtKVUYI1ZH+tppiYa GTmET0Myljol8H+4lSI/+fqEAVrBM//g4ALXBt2FDikAFix9Aj9mycNgbFPQ+s5g X/6u5ZBRqNIOfs9w1HC4G/gzS/c0K+Ju79d17gKCOFeQBt4zf4jSiHAhtUU71LZd LYyE/p4QIfRz8L5aCIn/d64TLmGnODMqOPGBew8wjrRuRd3KUbCNxf2SvclEEA5U kVKe5sy8oS1ZBXG+hli2Nr1qgNCJ1ihsAPXAppOvfTzZZeZzP6PZBBu1oVgGNU03 0jwd8J2T9Ayxib7SllhZZoTopxzstEaTVv3lftXDDfyZCmEcCefi54Ic1nqA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1654867348; x= 1654953748; bh=u/HD7LI5oIY10LWt1LCkpa4cfWQxW2dO4n0fXRV6Wt4=; b=c jUBTHEwfI/BUvVFTPUuYbgxa+tYN+7ZdFNLTMgYnPv+hzKogJEXYOHlZWK0QdCVm IqskKvJ/Ymlk+Ng/1QTjQG12vDphCpTNdyaVL7ira9RgDaGYFy4K7b8QYQlAv4Ne Cb/Fs8POyp0jcMFPWa8zz+euEZ1V+iMw4jBUnfz6Ody+zxA7R4+cmogU/EhtTGRK eojTwaH9teHffg0mHWJv044L9iYvDvp5kmEhEH3WT74zKU4lMsywKiL9kXcirASt DvDUUKWjyJwq97GgAGYjvUr+gJvrlH0IPAXXCnDL7Sj91JDSph1D0TNMEH1gcTa6 HNXROuSUTNnrsoucbf0Zg==
X-ME-Sender: <xms:lEWjYtLavwQ81qPo-5WC1UxlneVtVwmH1ByCKGVtrIbWBaHi9RG5-Q> <xme:lEWjYpLz1oH5SOrVVqFh8RLwMHDfivIRGsAi-A6RhEOHoGIVbN2bPmhEWQ_weroeb Vx6DghS9v8>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudduuddgieduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpedvteetieeviefhge eitdegiefgudevleehgfffleegleeuhefhiedtleegtdffgeenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilh htvggrmhdrtghomh
X-ME-Proxy: <xmx:lEWjYls5U4VxuhplWFnXAYeGH4tJRwGqSsLSOEfHcJnqmG34au1JcQ> <xmx:lEWjYuaZvpgQzgxC4niv6gB3KGSzhG9Nn-PP8nQ-0t-GmCUncF0QZQ> <xmx:lEWjYkbvt9fzKMLXxHAXtaLhxfnIhtn_Phw8JtvIsOd92oTMKqZaXQ> <xmx:lEWjYtkNTmCJPSXRvyflAKhu-jRkOqU8GXUsG72L1BzZN57pAJtxfA>
Feedback-ID: i2d7042ce:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id AEB132D40071; Fri, 10 Jun 2022 09:22:28 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-692-gb287c361f5-fm-20220603.003-gb287c361
Mime-Version: 1.0
Message-Id: <ec38343d-6c89-4c8a-82c0-484375bd89b1@www.fastmail.com>
Date: Fri, 10 Jun 2022 23:22:07 +1000
From: Bron Gondwana <brong@fastmailteam.com>
To: dispatch@ietf.org
Content-Type: multipart/alternative; boundary="8e99f5d9897d4662b1be2680b5805446"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/OEQl6S4UVUhUy0vq_ejx_tFq7Xs>
Subject: [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 13:22:37 -0000

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