Re: Redirections to `Content-Encoding: encrypted` payloads

Mike Bishop <mbishop@evequefou.be> Fri, 02 October 2020 00:34 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 803BB3A0A47 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 1 Oct 2020 17:34:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.648
X-Spam-Level:
X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykbaIWabJiXq for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 1 Oct 2020 17:34:36 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (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 295253A0A43 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 1 Oct 2020 17:34:35 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1kO8zY-0003Lh-4t for ietf-http-wg-dist@listhub.w3.org; Fri, 02 Oct 2020 00:32:08 +0000
Resent-Date: Fri, 02 Oct 2020 00:32:08 +0000
Resent-Message-Id: <E1kO8zY-0003Lh-4t@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 <mbishop@evequefou.be>) id 1kO8zV-0003E4-QJ for ietf-http-wg@listhub.w3.org; Fri, 02 Oct 2020 00:32:05 +0000
Received: from mail-co1nam11on2097.outbound.protection.outlook.com ([40.107.220.97] helo=NAM11-CO1-obe.outbound.protection.outlook.com) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <mbishop@evequefou.be>) id 1kO8zT-0004oA-Ik for ietf-http-wg@w3.org; Fri, 02 Oct 2020 00:32:05 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C/OlTCCh/+jd8tKKPZkfYDgL0nyadcfC7MNq8rQTqZNTq+HfrRIsTED6nIyI70qdJJGVaygmU215pJN+mFAoB9dC88vKwV/1H4YuWw7i0FI2pvOU7gGsWof+wYnbjByxx8/5JHuWFadZCo8aR1WKnvb7DQ+7tJnvo1TCHrwTJcFGOfEK7mDEaZzFUUn5jXqdCjyTwEDzYGWW2sWID9GLgyDBT3dMrGQbERs8h4AXrie1/0Es1n0lQvS8NOnxGR4cAP2tMScq8If4/2YORGZ6pPjYxAT7pqKodJdEl5jUvpVY5N+i1NYDJs5dGC+2w5zM859HhHixua2z3QE7//7c4Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AJ79yN12xvo81oGDIIpNGIXH9hu9e3sZdIr2kKYk8u8=; b=nRrm4TymBJ8QFGU0iV+mu3Dlf8GI5Rr8aFna/W6T/soT8aDuY/ZdVpTp00q1bJSbRXloyIs2zrdLzr3ADAcBDsPnUrjUGrOWdcbbfmoHeCqEy+y1xK6RaMZ4qXTttG+pE5pOT1OAgZSu35kw1JIpEEbfGQmNRGbgDmlUV7MoNvmGXedZJQjVP5YU1aW6C4TK4gVJS+NfM4X52qSZHvxBAwZhx6ccctulGAC5dxz/Gpa1TeBK5byZIuEXU3Pxrkx+ggBlCbFrAc1aH0Dga7LhehFofFg+B+1jYW2zFytzue7EgRb4B58fIEOuEFTKRvkwtEU2xsSQG2nbtHBZqReaDA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=evequefou.be; dmarc=pass action=none header.from=evequefou.be; dkim=pass header.d=evequefou.be; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector2-evequefou-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AJ79yN12xvo81oGDIIpNGIXH9hu9e3sZdIr2kKYk8u8=; b=kqQ2VAc5S8PohEzbyfUW052SSRQb3ZbVs8WEZ/C1IZdC4tb9uuY3lhLG3wbdYLTWIEwEFz7PZs9dgd2JJlPTrilVTbTB2pN80Hx86zbgvR34astjwzS2G55jvo8XyDA2da0HyaWGS96CGTlC9gR9xiKyV+XV+MO2rQNMKOfG0sU=
Received: from CH2PR22MB2086.namprd22.prod.outlook.com (2603:10b6:610:8c::8) by CH2PR22MB1864.namprd22.prod.outlook.com (2603:10b6:610:83::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.35; Fri, 2 Oct 2020 00:31:50 +0000
Received: from CH2PR22MB2086.namprd22.prod.outlook.com ([fe80::b4f0:9c2f:ba9b:4ae3]) by CH2PR22MB2086.namprd22.prod.outlook.com ([fe80::b4f0:9c2f:ba9b:4ae3%7]) with mapi id 15.20.3433.032; Fri, 2 Oct 2020 00:31:50 +0000
From: Mike Bishop <mbishop@evequefou.be>
To: "alex@strugee.net" <alex@strugee.net>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Thread-Topic: Redirections to `Content-Encoding: encrypted` payloads
Thread-Index: AQHWmD5da1NfZfjJi0G9p3TsKDoWeKmDdllX
Date: Fri, 2 Oct 2020 00:31:49 +0000
Message-ID: <d638f42b-2918-4c1b-b620-8d510ef2db38@evequefou.be>
References: <622b20db1c96220b24718cfb80f4b5e8@strugee.net>
In-Reply-To: <622b20db1c96220b24718cfb80f4b5e8@strugee.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: strugee.net; dkim=none (message not signed) header.d=none;strugee.net; dmarc=none action=none header.from=evequefou.be;
x-originating-ip: [72.49.212.17]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3916be77-2ea4-4335-9512-08d8666a8d8b
x-ms-traffictypediagnostic: CH2PR22MB1864:
x-microsoft-antispam-prvs: <CH2PR22MB1864EB8A58F7DD4F6477C99FDA310@CH2PR22MB1864.namprd22.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: jZSAUdRqN+pfGTdhYTfUYEQCsjQ0Mov4UFaCJGpkIk5mipaDXaNFO04qAk+8ybifRh5VYLIfPtDM6bsdCkI0RxJUnx+mAbQdhKapafdnu2wTecxlyKa9hq86xB5BfTpr659ll/iiT+CzmXp9y4gTuiCQNDtOOX5gh3IpPEOmPYFVVjilU9S+xKAsany7DNzu0tXTHMV/t3NVpunK+6OqTZQidIe2hN3CLA5Ck6kizxvlE0Bj2gA/JppCyNCjsvUkWIXBFKtMQwkDD4RV1FrJN1xl/CaPWGM9Nx2s+4OrVw89F3qhbKSgNUpEWbMZfUCnodCElljybxswZ+04wsqCOnzrNQZzpzrkhsiBr4ZJsnsXuJACH/3Labs5WYX5MYI4peYnJbnXuNtJ0UmN9kePzImNEYUEdB287rfs+AfccbVDfGoNGtDtpsSNoPuCdU4s
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH2PR22MB2086.namprd22.prod.outlook.com;PTR:;CAT:NONE;SFS:(396003)(39830400003)(136003)(346002)(366004)(376002)(53546011)(86362001)(83080400001)(6486002)(36756003)(166002)(31686004)(7066003)(186003)(26005)(508600001)(5660300002)(6512007)(2616005)(2906002)(66556008)(66446008)(64756008)(66946007)(76116006)(66476007)(110136005)(91956017)(8936002)(316002)(71200400001)(8676002)(6506007)(31696002)(81973001);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata: 9iHRWXHxAfiAU/IfIUElOwtR9zcV8ozhg3xWlgVJhNxV7J2DcM1v9DzsMKTAIBhrGSKD7e1y+CnXv4FZMU5a+fohBXxKN8zlOG0lCWHAhHgr7WOAr8J7aoAxre8kaTc4yJWd9fF87i6fsPJkI17lgnb52EVYZnT6WT6eq6qK6gnvU4pSxHC9f/QL9dT0WoMHyxofMNCzllgF0QcRkPlHeNla2ekaizyh0yqUTZYcT1Wpx/KLwWzLSZ1QS5r1Ahd5oJkM8JO068oUVMY50h4reF0P+e3nAosBzPcSAM9dkzP388dAcsCtMJz9Egz8i0PoykZkSiTl3NIbtugX/MpXk0C8TbAehWD8eJWmFTpFXrFukh9vv5aM0mrwvXgKradFSKz4Y611fB6e2idba1FJyZhXv9hNOdtoSO4rHAzYHkIkqmNIq+QxwxkLq7jf8neOORIvVgIKP9yKGNzuyea6u4z1zTkOZjCF4KigkvfRBl/ppEaOfPh5EsFDLOc2gHhaJH+MqzJXJQlvgLxSaG0BcGrD3ZV1gE4R8QXnq47guN7WsrfsY7PJlgiVzSBgFSNOBaW8l8Jl8QiPEY18tWkCWM5u2Cd1OBkm+pwP0HhBP53lHHCJFRhA5FqybAdu8k1AzxlPADuz1y1RShFoJHStFg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_d638f42b29184c1bb6208d510ef2db38evequefoube_"
MIME-Version: 1.0
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH2PR22MB2086.namprd22.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3916be77-2ea4-4335-9512-08d8666a8d8b
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2020 00:31:49.8822 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: BF07bd5SgTc1b5tDCO3jj7JqhjP3qlSIfY0Igl4KNpoT8Zzm33NOgI7iAmENQREF429D9NiDSf7JNXve7fejZQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR22MB1864
Received-SPF: pass client-ip=40.107.220.97; envelope-from=mbishop@evequefou.be; helo=NAM11-CO1-obe.outbound.protection.outlook.com
X-W3C-Hub-Spam-Status: No, score=-3.9
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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1kO8zT-0004oA-Ik 2eb024ffd45fca5506eb1a356cd63f90
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Redirections to `Content-Encoding: encrypted` payloads
Archived-At: <https://www.w3.org/mid/d638f42b-2918-4c1b-b620-8d510ef2db38@evequefou.be>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/38074
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>

This is essentially the problem for which the Out-of-Band Content Encoding (https://tools.ietf.org/html/draft-reschke-http-oob-encoding) was designed. The headers (including the decryption key) are served by the origin, with the encrypted payload at a location indicated by the OOB encoding.

Sent from Nine<http://www.9folders.com/>
________________________________
From: alex@strugee.net
Sent: Thursday, October 1, 2020 6:01 PM
To: ietf-http-wg@w3.org
Subject: Redirections to `Content-Encoding: encrypted` payloads

Hi, all,

I've been thinking about an extension to HTTP for a little while and am
curious whether you all think it's worth pursuing. Here's the use case:
say I have some large file, maybe a video or something. Given my server
and network resources, it's difficult for me to efficiently distribute
that file. The obvious answer to this is to use e.g. a CDN, but now I've
leaked the content of the file to the CDN. So I'd like to upload an
encrypted version of the file to the CDN, and then redirect clients to
that URL and say "by the way, here's the decryption key". I can think of
a couple ways to do this:

1. Some kind of 3xx redirect, with an additional response header to
distribute the key material. The issue with this is how the server can
tell that the client will be able to follow such a redirect.
draft-ietf-httpbis-client-hints to the rescue, maybe? (I could be wrong;
I have literally only read the introduction for that I-D.) Another issue
is what to do about headers. You don't want to leak e.g. the
Content-Type, so you can't give the headers to the CDN to serve. But,
the only other place to put them is in the original response, which is a
3xx response. So now you're sending e.g. Content-Type headers that are
basically lies, unless you encode them some other way.

2. Do option #1, but to solve the header problem define a new 3xx status
code whose semantics say that the 3xx response's headers are
authoritative, not the new location's headers. This does not seem like
an important enough use case to allocate a new status code though.

3. Do option #1, but with a header that indicates option #2's semantics.
E.g. `Redirect-Headers: use-original` or something. This also seems like
a bad idea because now the same sequence of responses can be interpreted
in completely disparate ways depending on whether the client supports
`Redirect-Headers`, which seems like a recipe for disaster (especially
because the server doesn't know in advance if the client supports
`Redirect-Headers`).

4. Something like Alt-Svc, but that worked on the resource level instead
of the origin. As a strawman let's say it's called Alt-Location. One
awkward problem with this: because the server doesn't know whether the
client will interpret the Alt-Location header, it needs to send the
response body as usual, but if the client *does* interpret the header,
it won't want the response body. Therefore the client will need to e.g.
terminate the connection. Also, if the client receives e.g. several
Alt-Svc values with different protocols, it can make an intelligent
decision about which protocol it prefers, but with Alt-Location it's not
clear how the client might pick between values.

5. Do option #4, but use Link and then add a header that explicitly
signals the client to prefer rel=alternate Links. This has the same
problem with sending the response body, though.

So, given the above, I'm wondering if the WG members have any interest
in pursuing this usecase, and if so, have any thoughts on any of the
above proposals. Is there anything I missed? Is there a decent way to do
this with the correct semantics? All of the above ideas seem wrong in
various ways.

Cheers!

-AJ