Re: [dispatch] Work for IETF114
Tim Bray <tbray@textuality.com> Fri, 10 June 2022 16:06 UTC
Return-Path: <tbray@textuality.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 4BC67C1A7F1D for <dispatch@ietfa.amsl.com>; Fri, 10 Jun 2022 09:06:31 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=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=textuality-com.20210112.gappssmtp.com
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 bBqkO2LMYqFi for <dispatch@ietfa.amsl.com>; Fri, 10 Jun 2022 09:06:27 -0700 (PDT)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 78ABEC175066 for <dispatch@ietf.org>; Fri, 10 Jun 2022 09:06:27 -0700 (PDT)
Received: by mail-ej1-x631.google.com with SMTP id m20so54273975ejj.10 for <dispatch@ietf.org>; Fri, 10 Jun 2022 09:06:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KTd4cyhcLB/xEoohxSyMKNzsvcOsGb7kxipWGguI+l4=; b=vXSv8DLzU3oziS0qrwuO0MNPq56POOg1icXgnoTZz1Mxv3ujpjOtt1zyieOkxei1P2 QNcrGY2QUVheVz1CmyKnkz9042x2qiPl97G4hkkPHDjGEbLDVuhooQmgUSrtxgtOhCWO uomUpyrPvboSgjC4ziZSW7KXrZY0VcmzTcB0RAWkr2isFEvSKJu0Qd7Df6rELVHfO1YX O2gsIHhXETtGXQDlJu/Z1Qd5+4KgES9MIDS+sXFIpkjAn8enb6xxFubpxECbgo1G2w69 EWsMYM0nd+EVG/K8HgPPe9okAN9OvE402uwGr8pi9XWC+zWshKFJn9HO5GKmeuh4YK+4 z6Ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KTd4cyhcLB/xEoohxSyMKNzsvcOsGb7kxipWGguI+l4=; b=nMF1dmtkm+JyDNXQAMaJBP+ZSGz9V03JudF9W86E8WXwh/fVEKPb4fQ6Erwf9TdBNl sM34DbQtXSEB1M4BbzeAxIkc1AUbbf+rI6dKWUpmnsruCwmQnsdoQMhDLp7avHdy4zid 871xWICJPX9Rek6dJcU529IXgrWClggG+IexhzI3t5d0J6pgXlUn/wyCb2QO8dLIFDQU vzLeDXOJVlyGpYQyTXG6zmfN2lf9sZezyzM80NphUs446mZzJcCagPi3jJ5Fwn7CQxdo 62vLFlBmoyYzzw0tBoXBgHHf5qJFQLU7pIpArqmZWuQjnzsuEarBoVS4P/8ka1DZG8I2 Rfsg==
X-Gm-Message-State: AOAM5327L107MG2epthttb9rBo5we0rVwkYgncEgXptmE6iIgeGl74az j/pNHYkGRr7xmWA2/6MfYpPiYWU7/l945vbpXHk8LvTVIN4jQNEG
X-Google-Smtp-Source: ABdhPJwSHKudyV6a8T0daEa38BJzIxhWg17QelfkVxybcPKKnoURaql+tia6M8pxjI6F217b+OxpD9iOr4EKdN4IEmA=
X-Received: by 2002:a17:907:1b1a:b0:703:a290:98f1 with SMTP id mp26-20020a1709071b1a00b00703a29098f1mr41422859ejc.418.1654877185695; Fri, 10 Jun 2022 09:06:25 -0700 (PDT)
MIME-Version: 1.0
References: <ec38343d-6c89-4c8a-82c0-484375bd89b1@www.fastmail.com>
In-Reply-To: <ec38343d-6c89-4c8a-82c0-484375bd89b1@www.fastmail.com>
From: Tim Bray <tbray@textuality.com>
Date: Fri, 10 Jun 2022 09:06:14 -0700
Message-ID: <CAHBU6iuKpV-GTyOTHaytg9_MxDtrNNuSF88WWsTp3wfLmpfsQQ@mail.gmail.com>
To: Bron Gondwana <brong@fastmailteam.com>
Cc: DISPATCH list <dispatch@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ccfb5b05e11a1ee2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/s0TBmMcChzVJ1pObXdKxcq7JkgE>
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 16:06:31 -0000
You know, you wouldn't have to invent *that* much new. When you retrieve https://example.com/foo#bar, the "#bar" part isn't sent to the server, and the rules say it is interpreted with respect to the content-type of whatever you get. It's called the Fragment Identifier ( https://datatracker.ietf.org/doc/html/rfc3986#section-3.5) and normally used to identify a fragment within the resource representation, but let's ignore that. So suppose you invent a new media type, say app/encrypted-file. Then you invent a tiny little language to go in the fragment identifier. E.g. https://example.com/#KeyID=48954289574239 or possibly even https://example.com/#KeyHost=tbray.org&KeyID=48954289574239 When this thing is retrieved (without the #fragment) you get something with Content-type: app/encrypted-file Now, there'd need to be serious thinking about chain of trust. Obviously you'd require trust and encryption for the channel over which the URI-with-fragment is transmitted. Then there's the matter of where the key comes from. In the second form, one assumes the key is in example.org//.well-known/something and the receiver only really needs to decide to trust example.org. The first form, where there's a pre-existing out-of-band arrangement about where to get keys from, is attractive. I think you still need the KeyID thing. Wouldn't be that hard to implement. On Fri, Jun 10, 2022 at 6:22 AM 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 mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >
- [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