Re: [Accord] ANN: drafts discussing Secure Content Delegation (aka "blind caches")

Natasha Rooney <> Thu, 31 March 2016 10:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 058A612D585 for <>; Thu, 31 Mar 2016 03:01:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sFcxXBeirKY0 for <>; Thu, 31 Mar 2016 03:01:43 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fe00::641]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6804812D725 for <>; Thu, 31 Mar 2016 02:53:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-gsma-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=e54DCzMuD5le0hmRbVwonx40u8WyehvRExUyagmDfC4=; b=nkijzC77h/CBl0oqCI07o37D0t7BApsQhu4wKeRApQgGIaizH9PGUl7+obqs4RmseklSsIhbK6AczPT7z9rXxPUBTp0+1Jck4hUlTH02lW5JaCtWHpWsmEwrTfPYetbY5B1TCKomtI1vgrTpdbH7eTIISgxqM/qeqJUJwukeaUY=
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.447.15; Thu, 31 Mar 2016 09:53:04 +0000
Received: from ([]) by ([]) with mapi id 15.01.0447.024; Thu, 31 Mar 2016 09:53:04 +0000
From: Natasha Rooney <>
To: Julian Reschke <>, "" <>
Thread-Topic: ANN: drafts discussing Secure Content Delegation (aka "blind caches")
Thread-Index: AQHRir1v0vciEBhjukq3e+FQaDbJh59zUMCA
Date: Thu, 31 Mar 2016 09:53:04 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-mailer: Apple Mail (2.3112)
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-ms-office365-filtering-correlation-id: 9549b298-5ece-4d78-4645-08d3594a4124
x-microsoft-exchange-diagnostics: 1; HE1PR04MB1033; 5:W6i0VYIR0JQ6z7/PFjyVgAC35gI7HlMd2mM4q6dCUNY05aZGvu2WyK2mDIE1Gy35u8AuXcx6xc1AGv4L6m8at82MC3UVArUWQ2nbCvr20cXCwThnJVuBq6h+Tb1lDw1aDj1ouRB0xrIRLu9EygRQyw==; 24:r6CdRmUFGg7rMRJa7SbsNvl+15EjMIIsxAw1/56UeoYDiXcqKXOxB5mub1Wxqr2vvcQI3canlNJ4qMLa+piSrPeBojhCeQ1ESsLadTRQTSs=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1033;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:HE1PR04MB1033; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1033;
x-forefront-prvs: 0898A6E028
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(24454002)(76176999)(50986999)(2906002)(189998001)(10400500002)(122556002)(19617315012)(5008740100001)(87936001)(5002640100001)(81166005)(3280700002)(1096002)(3660700001)(5004730100002)(86362001)(5001770100001)(57306001)(36756003)(107886002)(33656002)(83716003)(50226001)(92566002)(66066001)(82746002)(102836003)(5890100001)(2501003)(19580405001)(19580395003)(16236675004)(3846002)(6116002)(2950100001)(106116001)(15975445007)(586003)(2900100001)(77096005)(11100500001)(1220700001)(7059030)(7090700003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1033;; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_30A49092FF84426990B8F5F80C6C2712gsmacom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2016 09:53:04.4251 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1033
X-MS-Exchange-CrossPremises-AuthAs: Internal
X-MS-Exchange-CrossPremises-AuthMechanism: 04
X-MS-Exchange-CrossPremises-SCL: 1
X-MS-Exchange-CrossPremises-messagesource: StoreDriver
X-MS-Exchange-CrossPremises-avstamp-service: 1.0
X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00
X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0;
X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent
Archived-At: <>
Subject: Re: [Accord] ANN: drafts discussing Secure Content Delegation (aka "blind caches")
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Alternatives to Content Classification for Operator Resource Deployment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 Mar 2016 10:01:47 -0000

Hi ACCORD mailing list subscribers!

Please see the below mail from Julian re the Secure Content Delegation (aka "blind caches") draft. On investigation it seems many cellular operators use caching to both to improve user experience and to increase savings, although many of these techniques are transparent. New caching techniques may help improve user experience whilst keeping content encrypted. Julian et al are looking for feedback in IETF95.



Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA |<> | +44 (0) 7730 219 765 | @thisNatasha | Skype:<>

On Mar 30, 2016, at 8:43 PM, Julian Reschke <<>> wrote:

Hi there!

In the past months, Martin, Göran, Salvatore, Christer, Zahed and myself have been working on a set of drafts about "Secure Content Delegation" -- in Martin's words:

"An architecture is described for content distribution via third-party content distribution networks with reduced privileges. This architecture allows an origin server to delegate the responsibility for delivery of the payload of an HTTP response to a third party. That party is unable to modify this content. The content is encrypted, which in some cases will prevent the third party from learning about the content."

The ideas behind this have been discussed since spring 2015; most of the times using the term "blind caches".

We have two new drafts out: - "An Architecture for Secure Content Delegation using HTTP"

and - "Caching Secure HTTP Content using Blind Caches"

and we'll use the github repo at <> to work on them.

The drafts build on lower level machinery defined in

1) (<>)

2) (<>)

3) (<>)

4) (<>)

We'll be attending the IETF meeting in Buenos Aires and would love to get feedback on this; if there's sufficient interest we may be able to steal a few minutes to present in the HTTP WG meetings...

Note: to better understand the problem space and develop the mechanism, a prototype has been built using browser service workers to deliver DASH streaming video as well as other resource types. This is also used to gather performance insights.

Best regards, Julian & Göran

This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.