Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-httpbis-early-hints-04: (with COMMENT)

From: Martin J. Dürst <[email-masked]>
Date: Tue, 1 Aug 2017 19:15:32 +0900

On 2017/08/01 08:39, Mark Nottingham wrote:
> 
>> On 31 Jul 2017, at 11:06 pm, Mirja Kühlewind <[email-masked]> wrote:
>>
>> Not sure if this should be part of the security consideration but isn't there
>> also a higher risk of loading resources unnecessarily if the finale response
>> turns out to not need these resources? Could that be even used somehow as an
>> attack?
> 
> The general thinking here is that in terms of risk, preload and server push are no different than "normal" Web operations -- the server already has the ability to push arbitrary bits at the client, get it to make other requests, etc. Because pushes and preloads are modelled as client requests, they're already within the web security model.

I think the web security model is mostly about what bits are able to 
trust what other bits, and to what extent.

Mirja seems to be worried more about DOS-like attacks on resources 
(client storage, processing power, and network bandwidth). In usual 
operation, a web client can always decide just to not download some 
stuff. But with pushes,..., the client at least has to be more actively 
watchful, and a note to that effect may help.
(In colloquial terms, it's the difference between "we'll only ever send 
you what you asked for explicitly" and "we'll send you whatever we think 
you may need or want; you can always say no if you don't".)

Regards,   Martin.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 2 Aug 2017 05:55:37 +1000

> On 1 Aug 2017, at 8:15 pm, Martin J. Dürst <[email-masked]> wrote:
> 
> Mirja seems to be worried more about DOS-like attacks on resources (client storage, processing power, and network bandwidth). In usual operation, a web client can always decide just to not download some stuff. But with pushes,..., the client at least has to be more actively watchful, and a note to that effect may help.
> (In colloquial terms, it's the difference between "we'll only ever send you what you asked for explicitly" and "we'll send you whatever we think you may need or want; you can always say no if you don't".)

The counterargument is that push is a direct replacement for inlining the content directly, and offers the client *better* control compared to it.

Regardless, this particular issue isn't about push, it's about giving link hints to the client, which the client does have control over. The actual specs for those hints already have specific security considerations, e.g., <https://w3c.github.io/preload/#privacy>.

Cheers,

--
Mark Nottingham   https://www.mnot.net/