Subject: [Wpack] Mirja Kühlewind's Block on charter-ietf-wpack-00-14: (with BLOCK and COMMENT)

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Thu, 27 Feb 2020 07:07:52 -0800

Mirja Kühlewind has entered the following ballot position for
charter-ietf-wpack-00-14: 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:
----------------------------------------------------------------------

Thanks for all the discussion that happen on the charter so far, unfortunately
there are still a few points that are not fully clear to me from a transport
perspective:

1) It not clear to me how you plan to address low latency. I assume you don't
want to optimise anything in the lower layers but it does sound a bit like it.
Can you clarify this point?

2) I think "Being extensible and crypto agile" is a requirement we have for any
protocol we design. Is there anything special here, or why is this listed?

3) I also don't really understand this point
"Specifying constraints on how clients load the formats without describing
specific loading algorithm to help achieve the above goals"
Can you further explain? I assume there are no transport implications here but
as I'm not sure what is meant, I'd like to double-check!

4) Again here I'm not sure what is meant and I assume you don't plan for any
transport protocol changes or extension but double-checking! "Optimize
transport of large numbers of small same-origin resources." What does this
mean? What's the solution you have in mind?

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

One editorial comment: I find the chosen form of listing goals rather than
writing text that describes the scope of the work not very reader-friendly (at
least more the main/key goals). I think text instead of quite short bullet
points would be more meaningful and would probably have avoided some of the
discussion/confusion we had about this charter.

Further I agree with Ben that this part is not very clear and could be better
scoped: "Security and privacy properties of using authenticated bundles as
close as practical to TLS 1.3 transport of the same resources."

---

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 27 Feb 2020 15:20:48 +0000

Hi Mirja,

I am only replying below to your blocking comments:

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

WPACK is working on a bundle format, so there is no transport protocol here. Can you suggest how to clarify this?

> protocol we design. Is there anything special here, or why is this listed?

Nothing special in this case, but in order to avoid any doubts.

> as I'm not sure what is meant, I'd like to double-check!

No transport implications. By "load" this means from disk/web browser cache. Does this help?

> mean? What's the solution you have in mind?

I might need Jeffrey's help to reply to this one. I am pretty sure there are no transport protocol implications.

Best Regards,
Alexey

---

From: Jeffrey Yasskin <[email-masked]>
Date: Fri, 28 Feb 2020 13:20:47 -0800

On Thu, Feb 27, 2020 at 7:21 AM Alexey Melnikov <[email-masked]>
wrote:

> WPACK is working on a bundle format, so there is no transport protocol
> here. Can you suggest how to clarify this?
>

We could split this into two requirements:

* When a bundle is streamed, the client must be able to start using a
subresource before the entire bundle is downloaded, and for large
subresources, before the entire subresource is downloaded.

* When a bundle is loaded from random-access storage, the client must be
able to use a subresource without necessarily reading the entire prefix of
the bundle before that subresource.
<<<<<

Those were roughly what I had in mind when I wrote "low latency".

The current format achieves the first by putting the index of subresources
at the start of the bundle (unlike ZIP) and by using
https://tools.ietf.org/html/draft-thomson-http-mice-03 to protect
subresource integrity.

It achieves the second by having an index (unlike multipart/*).

> No transport implications. By "load" this means from disk/web browser

See also the discussion on the IESG list under "WG Review: Web Packaging
(wpack)" and at
https://mailarchive.ietf.org/arch/msg/wpack/gokRbg6vSxHz3jC3eqcVhYkIF1s/.

> are no transport protocol implications.

This was about improving compression by letting the compression algorithm
keep state across many resources. There have also been a few attempts to
get the same benefits in HTTP directly, whose difficulties have led to
https://tools.ietf.org/html/draft-handte-httpbis-dict-sec-00.

Thanks for the transport-oriented review!

Jeffrey

---

From: Jeffrey Yasskin <[email-masked]>
Date: Fri, 28 Feb 2020 13:32:11 -0800

> the bundle before that subresource.

I missed the "whether or not the package is authenticated" aspect. That
needs something like:

* When a bundle is authenticated, the client must be able to validate the
authentication without extra requests over the network.

This drives the ability to include certificate chains, SCTs (for
certificate transparency), and OCSP responses (for revocation) in the
bundle.

Jeffrey