Re: Draft v1 Update for Resumable Uploads

[Greg Wilkins <[e-mail]>]

On Tue, 21 Jun 2022 at 16:26, Guoye Zhang <[e-mail]> wrote:

> We think parallel upload places unnecessary burden on the server code to
> support it, and it is generally an abuse of the network.
>

+1

>
>    1. ... Could the server use this mechanism to skip ahead? ...
>
> This is a really interesting use case. We do not prevent this in the
> current draft, and it will probably just work with our current experimental
> implementations. Is there a concrete example where this capability is
> useful?
>

I have no specific use-case.  I was just thinking through any constraints
that might be on offset, such as rewinding to zero or a previous boundary.
 So I thought about the skip forward case when thinking about constraints
in general.
I certainly know that range requests were/are used to skip ahead to
specific sections of a PDF document to rapidly display them, so perhaps
there are similar examples of a server that wants to check a signature at
the back of a content before accepting the whole thing.   Thus I could
image a sequence like:

   - client posts a large document
   - server send 104
   - server reads initial section containing indexes into the content
   - server fails the transfer with a 5xx
   - client requests offset
   - an offset is given at a specific index deep inside the content
   - the client sends the content from the deep offset
   - server reads the deep offset content and is satisfied that the
   document is applicable
   - server terminates the transfer with a 5xx
   - client requests offset and server now responds with an offset just
   after the initial index section
   - client sends the full content.

This would be no stranger than what PDF viewers have done with range
requests.

In fact I can even think of a use-case now.   If a document system had
given out a huge PDF to be signed by a human on some specific pages, then
when that signed document is uploaded, the server might want to avoid
uploading all the unsigned pages and just get the signature pages.

We’ll definitely discuss it internally. If it isn’t too much trouble for
> client implementations, I don’t see any reason not to support it explicitly
> in the draft.
>

For our client in the jetty project, we would have no problem with a skip
forward semantic.  In fact we actually have more problems with a rewind
semantic as a client can be configured with a content that generates bytes
on the fly and cannot (or should not) be replayed.

Which now makes me think that the draft might need a bit more clarification
on why there are no security implications for sending the body of a POST
(or other non idempotent request).   Whilst a lot of security concerns are
mitigated by asking the server for the offset and then using a PATCH
method,  I can still see some implications for some types of client.

Consider a client that dynamically generates a one-time password/signature.
Then a man-in-the-middle attack could read the entire on-time password, use
it, but fail the transfer to the client and reply with a 0 offset.  The
client would then resume from 0, generating a new one-time-password on the
fly and the man in the middle could use that again and repeat.   I've no
idea if this is really exploitable in any way, but I'm just thinking about
when we might consider it safe to rewind our dynamic contents in our client.

It would be good if the security implications section could expand on the
impact for non-idempotent requests and give recommendations of when content
can be replayed in a resumed request.

cheers








-- 
Greg Wilkins <[e-mail]> CTO http://webtide.com