Subject: [Webpush] Encryption container format (was: Protocol proposal updated)

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Oct 2014 14:14:29 -0700

On 10 October 2014 13:42, Costin Manolache <[email-masked]> wrote:
> The JWE is a bit too verbose for mobile - having a base64 / web safe
> encoding
>  in the binary payload of the message seems too chatty.
> This matters the most when sending the message from the 3p server to the
> push server -
> which is also probably sent as binary payload, I couldn't find the proposed
> details.

Yeah, I get the opposite about JWE from others: the attempts to keep
it small are considered too aggressive by some.  I guess there really
is no such thing as "one size fits all".

I'm going to suggest that gzip content-encoding might be your best
friend.  We can make support for that mandatory if you like.  HTTP/2
didn't manage to make support for it mandatory, but it's not
particularly hard to do.

> I also suspect there would be more libraries/implementations and experience
> on using a (relatively)
> common encoding like pgp.

Actually, the reason I chose JWE was the ease of implementation.
There is lots of code out there already.  Web Crypto uses JWK, so it's
going to be partially supported in browsers anyway.

I'm sure that we'll find that there are S/MIME enthusiasts out there
as well.  I don't really mind what we pick in the end as long as it is
easy to consume.  Well, as long as it supports the same sort of key
encryption mechanism that JWE does, because that's needed in
-aggregate.

> In any case - the push server would need to do some validations and in
> particular if JWE is used
> to re-package in more compact form for transmission to mobile devices.

Why do you think that the server would want to validate messages?  Or
even be able to?

I totally understand repackaging (see above re: gzip).

---

From: Costin Manolache <[email-masked]>
Date: Fri, 10 Oct 2014 14:50:25 -0700

> didn't manage to make support for it mandatory, but it's not

Average message size is quite low, it's quite common to send only few bytes.
The HTTP/2 stream frame and the data frame headers are going to be larger
than
the content of the message.

That's the issue: for notifications that result in sync or client
contacting the server
directly ( quite common ) you have 5 bytes of content - wrapped in many
layers.
Short packets keep the radio on for less time and may use significantly
less battery.

I would suggest using just regular data frames (streaming) instead of the
synthetic
GET for the same reason.

> encryption mechanism that JWE does, because that's needed in

On receiving side it's not a huge problem - browser (or UA) will decrypt
and handle
the clear message to the app.

There is the issue of how easy it is for the 3p sender to generate the
message -
JWE in browser won't help much there, and the issue of wasted bandwidth and
battery due to base64 encoding and extra verbose encoding.

> I totally understand repackaging (see above re: gzip).

You can't gzip encrypted content, at most push server may take the base64
encoded JWE and send it
as binary ( if it is possible ). If you mean gzip the json keywords - I
don't think that works
either, keeping the compression context would be too hard.

Costin