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
>