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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 26 Feb 2020 15:23:07 -0800

Benjamin Kaduk has entered the following ballot position for
charter-ietf-wpack-00-12: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-wpack/

----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

It looks like we've gotten some good discussion on the community feedback mentioned
in my previous Block, though we may still be waiting for a response on the intent of the
"Support books being published in the format" secondary goal.

I am not sure how appropriate it is to have milestones for "signing document"s given that
we say that WPACK will attempt to reuse work on HTTP signing from HTTPBIS.

I think there were some more s/signed/authenticated/ changes that were indicated but
not present in the 00-12.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

It's not entirely clear to me whether "low latency to load a subresource" fits better
as a primary or secondary goal.

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?

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.

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"?

Are there other IETF WGs (in addition to W3C and WHATWG) that might have some
knowledge about security and privacy models for the web?

---

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 27 Feb 2020 14:13:56 +0000

Hi Ben,

> "Support books being published in the format" secondary goal.

As I just replied, I will either take it out or replace this with more specific requirements.

> we say that WPACK will attempt to reuse work on HTTP signing from 

Whether it is a document that just references HTTPBIS work (and thus a very small one) or a separate document, I think we need a milestone for this. If you can suggest a better name for the milestone to make this clearer, please do.

> not present in the 00-12.

These should now be fixed.

Best Regards,
Alexey

---

From: Jeffrey Yasskin <[email-masked]>
Date: Fri, 28 Feb 2020 14:09:49 -0800

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

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

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?

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

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."?

Thanks,
Jeffrey