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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Thu, 06 Feb 2020 07:01:42 -0800

Benjamin Kaduk has entered the following ballot position for
charter-ietf-wpack-00-07: 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:
----------------------------------------------------------------------

  The WPACK working group will develop a specification for a web packaging
  format that efficiently bundles multiple HTTP representations. It will also
  specify a way to optionally sign these resources such that a user agent can
  trust that they came from their claimed web origins. Key goals for WPACK are:

A key feature of the modern web is that HTTPS is becoming almost
universal: HTTPS provides not just encryption for the content but also
integrity protection and source authentication, but we've had to put a
fair bit of effort in to get to where we are.  I'm not sure that we want
to leave ourselves with a new baseline of "unsigned" and another fair
bit of effort to get back to "most things have cryptographic
protection".  While I recognize that there are some use cases for WPACK
where the origin may not be cooperative and the entity creating or
distributing the packages needs to remain anonymous or pseudonymous, I
don't think that precludes signing the resources in some way.  What the
exact semantics of such signing would be are, of course, not clear yet,
but I'm reluctant to endorse a charter that describes the signing as
just "optional".

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

  * The ability to create an unsigned snapshot of a web page without the
  cooperation of its publisher.

Similarly, perhaps this would be "without a signature from its
publisher".

  * Being extensible and crypto agile.

Generally good things, though I'm curious if there's a particular
direction(s) of extensibility in mind.

  * Support more-efficient signing of a single, possibly same-origin HTTP
  resource.

More efficient than what?

I am also confused about the "self-extracting executables" point that
others mentioned.

---

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 06 Feb 2020 18:23:51 +0000

Hi Ben,

> https://datatracker.ietf.org/doc/charter-ietf-wpack/

I think "optional" is because a particular bundle might be generated by somebody other than the publisher. I don't think the intent is to encourage publishers not to sign.

So how about changing "specify a way to optionally sign these resources" to "specify a way for publishers to sign these resources".
So basically to drop "optionally" and clarify who this sentence applies to.

I don't think such details belong to the charter.

> More efficient than what?

Jeffrey, could you expand on what was intended here?

> I am also confused about the "self-extracting executables" point that

I suggest we drop it, because it is not clear how useful this goal is. I assume pretty much any data structure can be used by a self-extracting executable :-).

Best Regards,
Alexey

---

From: Jeffrey Yasskin <[email-masked]>
Date: Thu, 6 Feb 2020 10:48:32 -0800

Sorry I'm behind on some of the other comments.

> https://datatracker.ietf.org/doc/charter-ietf-wpack/

I think it would be fine (wouldn't break any use cases) to require
that the package be signed by *some* key, but that signature is only
useful to a recipient if they can map it to some identity that they
recognize. Most users don't have a public key with such an identity,
so it didn't seem useful to require them to generate a key just to
save a web page into a package.

That sounds fine to me.

> direction(s) of extensibility in mind.

I was thinking primarily of dealing with algorithms that get broken,
and that's one motivation for allowing multiple signatures on a
resource. For example, we know that post-quantum crypto is coming, and
during the migration to it a signer might want to provide signatures
with both an elliptic curve algorithm and a post-quantum algorithm, to
be compatible with more clients.

> More efficient than what?

A multi-resource bundle has some overhead to support the ability to
include multiple resources. The current "signed exchange" format is a
little smaller because it doesn't need to support more than one
resource, and I wanted the group to be able to keep that optimization.
I'm not certain we'll wind up wanting to keep it.

> I am also confused about the "self-extracting executables" point that

This drove the inclusion of the package length at the end of the
package format, and didn't otherwise change the format. Including the
trailing length allows one to concatenate an extraction executable
with a package without needing the executable to know its own length.
It was a request from, I think, someone who worked on Electron.

Jeffrey

---

From: Sean Turner <[email-masked]>
Date: Thu, 6 Feb 2020 20:43:48 +0100

Sent from my iPhone

> On Feb 6, 2020, at 19:48, Jeffrey Yasskin <[email-masked]> wrote:
> 
> t sounds fine to me.
> 

I think it is fine to keep this, but since we have BCP 201 do we strictly need to include this?

spt

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 6 Feb 2020 17:33:03 -0800

> save a web page into a package.

This seems like a question that should be decided by a WG and not at
charter time!
Alexeys suggestion of "a way for publishers to sign these resources" (or
perhaps even just "a way to sign these resources"?) is probably a good way
forward.

> be compatible with more clients.

Sean's point is a good one, though it may still be worth mentioning
extensibility in its own right.

> I'm not certain we'll wind up wanting to keep it.

So this could be summarized as "optimizations in encoding and processing
when only a single resource (as opposed to a collection thereof) is being
packaged"?

> It was a request from, I think, someone who worked on Electron.

Ah, that helps with understanding, though it's perhaps a bit more detailed
of a point than might be expected in a charter.

Thanks,

Ben

---

From: "Alexey Melnikov" <[email-masked]>
Date: Fri, 07 Feb 2020 11:11:45 +0000

Hi Ben,

> perhaps even just "a way to sign these resources"?) is probably a good way

I use the former.

> extensibility in its own right.

I kept this item as is.

> when only a single resource (as opposed to a collection thereof) is being

I used your text.

Best Regards,
Alexey