Re: Draft v1 Update for Resumable Uploads

Greg Wilkins <gregw@webtide.com> Tue, 21 June 2022 07:28 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C015EC13A246 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 21 Jun 2022 00:28:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.66
X-Spam-Level:
X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-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=webtide-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 Aj4jvioeUV_C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 21 Jun 2022 00:28:22 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3D8AC13A242 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 21 Jun 2022 00:28:22 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1o3YG2-0002Np-Tf for ietf-http-wg-dist@listhub.w3.org; Tue, 21 Jun 2022 07:25:06 +0000
Resent-Date: Tue, 21 Jun 2022 07:25:06 +0000
Resent-Message-Id: <E1o3YG2-0002Np-Tf@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <gregw@webtide.com>) id 1o3YG1-0002La-AQ for ietf-http-wg@listhub.w3.org; Tue, 21 Jun 2022 07:25:05 +0000
Received: from mail-lf1-x12f.google.com ([2a00:1450:4864:20::12f]) by mimas.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <gregw@webtide.com>) id 1o3YG0-001q7N-1U for ietf-http-wg@w3.org; Tue, 21 Jun 2022 07:25:05 +0000
Received: by mail-lf1-x12f.google.com with SMTP id i18so7230609lfu.8 for <ietf-http-wg@w3.org>; Tue, 21 Jun 2022 00:25:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=webtide-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UZnpkmuJ3KgX+k84IBZGPHfUY00sRlIe8Bvmzu58dIc=; b=rWO2mBT8tWALN5bKSWBxG7YWxizbG8E0NBunc9PFJKx/Ovxmn4xhSklwBenDWWa3e9 0plYBMYO+/przEZ1EZhKvE/ajjz5istCuqjoM9EqkSqCazZEzmolRF8bVr6ywDiBiPR4 kUu5eEFHAfSvNBTSa4Un4I+oyrLchIg48gAiB/wQYb+i8g3YsED2Zn06Mcdwu2kuxvIf voJUxqHengPGrV/F55Q8wtgMY6OiPBVAiLTebGbK/GBlQgFntN9cAnuZeZHEg9nAgDVd VIuO8Qm9T+Ydn81DxSoKtctErCZUi5iUpCgKpyAsT1bK1LeTemts2v1m7SMKVhPVpWMv HMew==
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=UZnpkmuJ3KgX+k84IBZGPHfUY00sRlIe8Bvmzu58dIc=; b=u59+kIyu5EOTPZXjm8hHDqTiYfS4FQUHVI7SMXgf0/WnKEqgJ+05/nPgomwjPEQ2Gg 3IFh2IIFu9BjbjKICm3wVGyYC7zcMk23kKQG/Jw6/J8MEKXPHx+FkpVIJEFGJZxqtbTa sAQqk7sUZteOY+H1d+kxPgbu1pj635ZUlVxY5A8HBgt9Ijk6imQY+vc4pZ6/pzCWSZ9p 3JUK3kkJtDuBFjyAKhkws5+xSZJAD2ovq6ihpq6ujl97uox/Ynp9uRXmbJOXuMDiQjrd kXOITlUvCXggTfn2DcfeA9K6aWEDyf1y7B08nNtlzC/AMM71jscjvSuVBNP6tm0/aHaE FiKQ==
X-Gm-Message-State: AJIora9xHF8tgxQxYn7lvHjCeSFd4Ml2Cs4jMchXPFropyrCiPtE558W cRjTFOFzPbIbG3OdhjnS9t37QiKxs1EQQsCf/3lCFseZa9g=
X-Google-Smtp-Source: AGRyM1u3QaxWt1TULjKkRTSKYlq2s+YNZALROenID68NyqYfQpUXnvAxPKMqTblUsIdJAB51KB03J9TblQArH/8RQ38=
X-Received: by 2002:a05:6512:3e09:b0:478:f180:2264 with SMTP id i9-20020a0565123e0900b00478f1802264mr15652958lfv.448.1655796291252; Tue, 21 Jun 2022 00:24:51 -0700 (PDT)
MIME-Version: 1.0
References: <BED5A5BC-3F7F-47E2-815E-DC0483328DFD@apple.com> <CAAPGdfEgMF6PQjejUP-r2+vT19fS8my4Mu=V_XvwCUy=8r9Abw@mail.gmail.com> <3B21D19E-A95C-4A68-B40F-23A59C9BA5DB@apple.com>
In-Reply-To: <3B21D19E-A95C-4A68-B40F-23A59C9BA5DB@apple.com>
From: Greg Wilkins <gregw@webtide.com>
Date: Tue, 21 Jun 2022 17:24:39 +1000
Message-ID: <CAAPGdfGv76e8DW3DdkXMx2y0or6dZ4c=BG1Vesx_Yu5JO2Rm+A@mail.gmail.com>
To: Guoye Zhang <guoye_zhang@apple.com>
Cc: ietf-http-wg@w3.org
Content-Type: multipart/alternative; boundary="000000000000c2cafd05e1f01d07"
Received-SPF: softfail client-ip=2a00:1450:4864:20::12f; envelope-from=gregw@webtide.com; helo=mail-lf1-x12f.google.com
X-W3C-Hub-DKIM-Status: validation passed: (address=gregw@webtide.com domain=webtide-com.20210112.gappssmtp.com), signature is good
X-W3C-Hub-Spam-Status: No, score=-3.2
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1o3YG0-001q7N-1U fad9e3d93ef0ca73fd353d45e8edf142
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Draft v1 Update for Resumable Uploads
Archived-At: <https://www.w3.org/mid/CAAPGdfGv76e8DW3DdkXMx2y0or6dZ4c=BG1Vesx_Yu5JO2Rm+A@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40197
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Tue, 21 Jun 2022 at 16:26, Guoye Zhang <guoye_zhang@apple.com> 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 <gregw@webtide.com> CTO http://webtide.com