Subject: Re: [Wpack] Benjamin Kaduk's Block on charter-ietf-wpack-00-12: (with BLOCK and COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 5 Mar 2020 13:49:13 -0800

On Fri, Feb 28, 2020 at 02:09:49PM -0800, Jeffrey Yasskin wrote:
> On Wed, Feb 26, 2020 at 3:23 PM Benjamin Kaduk via Datatracker <
> [email-masked]> wrote:
> 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > It's not entirely clear to me whether "low latency to load a subresource"
> > fits better
> > as a primary or secondary goal.
> >
> 
> There's tension between "Efficient (binary) storage" and low latency
> loading, since compressing the whole package as a unit will improve storage
> but harm random access loading. The WG should be able to discuss that
> tradeoff instead of having it already answered by the charter's choice to
> describe low latency as a secondary goal.
> 
> If we demote both to secondary goals, the charter might be read to imply
> that we have to achieve TLS 1.3's liveness guarantees by, for example,
> forcing authentication to happen via an extra online request to the origin
> server. I'd again like the WG to discuss the tradeoff between the latency
> harm of that request and its security benefit.
> 
> We say we'll try to have security and privacy properties "as close as
> > practical to
> > TLS 1.3".  Do we have a sense for how much distance we are willing to
> > accept
> > (vs. conceding that we cannot uphold our security and privacy requirements
> > and produce something that satisfies the  key goals) and still publish?
> >
> 
> I think that I'm only pushing to compromise on TLS's liveness guarantee,
> but I haven't thought about this in detail in a couple months, so I might
> be forgetting something.
> 
> When we say that we will try to "address the threat model of a website
> > compromised
> > after a user first uses the site", I'm not entirely clear on which
> > properties we're trying
> > to preserve in the face of such threats.
> >
> 
> I described this in more detail at
> https://wicg.github.io/webpackage/draft-yasskin-wpack-use-cases.html#name-protecting-users-from-a-com.
> In particular, a user with an existing relationship with a website
> shouldn't be compromised by an attacker just because they visited the site
> once at any point the attacker controlled its frontend. If the attacker
> gained control of the site's build system instead, or if the attacker keeps
> control for more than a site-determined amount of time, the user may still
> be compromised.
> 
> Does that make sense?

It does, though I'm not sure I could distill it to a specific "list of
properties" as I was asking for :)

> I wanted to let the WG help work out exactly what's needed here, but the
> trend of comments seems to be that we should write my current design for a
> solution into the charter. If that's the case, I think the "Support signed
> statements about subresources" goal is actually sufficient for this
> purpose, and we could remove this item.
> 
> Regarding the "automatic discovery" non-goal, does this preclude a way for
> > a website
> > to indicate how to retrieve an offline-usable version of a resource when
> > that resource
> > is being fetched "on-line"?
> >
> 
> I don't think it's important to prohibit this WG from discussing that
> particular kind of link, mostly because I think that discussion will be
> short: add to
> https://www.iana.org/assignments/link-relations/link-relations.xhtml or
> https://html.spec.whatwg.org/multipage/links.html#linkTypes. I wanted to
> head the WG off from discussing how to find a peer's copy of a resource
> that the client can't access directly. Maybe we should change the non-goal
> to "A way to automatically discover the URL for an accessible (retrievable)
> package that includes specific content that the client can't otherwise
> access."?

That might be overly specific for the non-goal; it's hard to say.

Thanks for the extra explanations; unfortunately, I don't expect to have
the cycles to try to craft them into text suitable for inclusion in the
charter.

-Ben