Re: [dispatch] Work for IETF114

I would also add that there is some overlap here with the TIGRESS working
group.  They're trying to solve a more complicated problem, but it has this
one as a subset.

On Mon, Jul 25, 2022 at 9:14 AM Richard Barnes <rlb@ipv.sx> wrote:

> This "upload an encrypted thing and send the URI+key" design pattern is
> ubiquitous in messaging, so it's not implausible to me that a common scheme
> would get some use.  But it would be good to benefit from prior art here.
> For example, this is the scheme that Webex messaging uses:
>
> https://www.npmjs.com/package/node-scr
>
> ```
> scr {
>   "enc" : string,   ; Content Encryption Algorithm from [RFC7518]
>   "key" : string,   ; base64url-encoded raw key value
>   "iv"  : string,   ; base64url-encoded initialization vector
>   "aad" : string,   ; Additional authenticated data (AAD)
>   "loc" : ? uri,    ; Location of encrypted content
>   "tag" : ? string  ; base64url-encoded authentication tag
> }
> ```
>
> Note that there are more fields there than the algorithm and key your URI
> thing envisions.  AAD could be left blank, and the tag might be part of the
> ciphertext (as called for in RFC 5116 but not universally implemented).  So
> the main problematic thing is the IV.
>
> There's probably some requirements work to be done here, for questions
> like whether anything can be assumed about the structure of the content
> aside from being a ciphertext for a given algorithm.  (If not, you could
> attach the IV.)  If there's interest, a focused working group would
> probably be my preferred path.
>
> --Richard
>
>
> On Fri, Jun 10, 2022 at 9: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
>>
>