Re: [dispatch] Work for IETF114

worley@ariadne.com Mon, 13 June 2022 01:27 UTC

Return-Path: <worley@alum.mit.edu>
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 BA3BEC157B35 for <dispatch@ietfa.amsl.com>; Sun, 12 Jun 2022 18:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.99
X-Spam-Level:
X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net
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 PCGvPGNJYLtC for <dispatch@ietfa.amsl.com>; Sun, 12 Jun 2022 18:27:51 -0700 (PDT)
Received: from resdmta-h1p-028597.sys.comcast.net (resdmta-h1p-028597.sys.comcast.net [96.102.200.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D84AAC157901 for <dispatch@ietf.org>; Sun, 12 Jun 2022 18:27:51 -0700 (PDT)
Received: from resomta-h1p-028434.sys.comcast.net ([96.102.179.205]) by resdmta-h1p-028597.sys.comcast.net with ESMTP id 0Yd6ojNRpL9Vp0Ypyov2wj; Mon, 13 Jun 2022 01:25:50 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20211018a; t=1655083550; bh=9dkZBPkiDNZ7PI5qyuU1bTm5AOCg4FUamF0yvC2IE/o=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=e4Ki7F7XZVWY6jyZZAGxF8TA23QL2lgATuSqMVYOMhAet1LFJjUGO/KlLvyaem8L6 zQvw8YdqeZ32b8s+N4i6XAuZ2FlU/0KBQVXrq1hkYR4/8yU2bLvjeCXp2hr5Ftjrce U+N/hb+/BgBSZfXny/owyoGsBXNmfdK4huvjM4fXLQtToJAvXEhuXRRLNESGUPn1mB njk6HKYCY86Wy4J9UZnLn6PQ89or4N3ZiBJ1LjOFkqDor6+N6hjba/lEc7d6AkbtE1 IVhXWpSlFawbp76cRXP5kgNIHqsrEdOTd75h1EM/Jy2L6pp3DpoN04dQ7MgMYMWUcH 4ANgWBk6yYE4Q==
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430::69ae]) by resomta-h1p-028434.sys.comcast.net with ESMTPA id 0Ypjo9cPLx90y0Ypwo0XJl; Mon, 13 Jun 2022 01:25:50 +0000
X-Xfinity-VMeta: sc=0.00;st=legit
Received: from hobgoblin.ariadne.com (localhost [127.0.0.1]) by hobgoblin.ariadne.com (8.16.1/8.16.1) with ESMTPS id 25D1PZ94146626 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sun, 12 Jun 2022 21:25:35 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.16.1/8.16.1/Submit) id 25D1PYJf146623; Sun, 12 Jun 2022 21:25:34 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: John C Klensin <john-ietf@jck.com>
Cc: brong@fastmailteam.com, dispatch@ietf.org
In-Reply-To: <F43BDC96CB68396AECE8E2B5@PSB> (john-ietf@jck.com)
Sender: worley@ariadne.com
Date: Sun, 12 Jun 2022 21:25:34 -0400
Message-ID: <87sfo9l5gx.fsf@hobgoblin.ariadne.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/UNVjaVhDqbtg6ZRQVK1fRjrW6j4>
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: Mon, 13 Jun 2022 01:27:56 -0000

Relative to this use case:

> --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.

>> 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.

It seems like this is the natural attack:

John C Klensin <john-ietf@jck.com> writes:
> 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/

That is, define a new scheme whose resolution process involves
- fetching of an object from URL-of-server-and-location,
- decrypting it with a particular algorithm-and-key,
- possibly verifying the hash of either the encrypted or the decrypted 
  object,
- attaching a specified media type (since the server of the encrypted
  version isn't necessarily going to preserve the media type).

After resolution, the generic "apply the fragment specifier based on the
media type" operation is applied.

I haven't chewed through the URI syntax carefully enough to propose how
to pack that information into a URI with the minimum amount of
%-encoding, but it would be nice if URL-of-server-and-location could
always be a suffix of the URI without modification.  You want a
URI form that doesn't have an authority component.  And the URL
embedding needs to allow a query part as part of the embedded URL,
preferably without having it be a query part of the URI.

I assume you'd use it for "large files over email" in this style:

    Content-type: message/external-body; access-type=URL;
                  URL="ENCRYPTEDFILE:/key/URL-of-server-and-location/"

Dale