Re: [Webpush] Major change to encryption

[JR Conlin <[e-mail]>]

​On Tue, Nov 1, 2016 at 8:50 PM, Martin Thomson <[e-mail]>
wrote:

> Moving the public key into the body will cut into message budgets.
> We'll be at 3994 octets of plaintext maximum if we do that.
>
​​

​I'm a bit confused about that. For "native" networks, push servers have
pretty wide tolerances for how much data that they can send over their
pipes. Going between services, I can definitely understand, since you're
held to the limits of the provider system. (APNs limits to about 2K, so
users are kinda screwed worse.) Of course, with "bridged" systems like
those, you still have to deal with the host system, so "headers" aren't
free. You still have to encode the data into the body of the message in
some fashion, which eats into the available amount.

Worst of all, is that those bridged systems are also unreliable for hosts
of reasons and then you're re-implementing TCP with one hand tied behind
your back.​

Granted, I've got a pretty limited viewpoint, so I'm sure I'm missing
something obvious.

On Tue, Nov 1, 2016 at 8:50 PM, Martin Thomson <[e-mail]>
wrote:

> On 2 November 2016 at 12:00, Costin Manolache <[e-mail]> wrote:
> > Yes, when sending over GCM it's better to have the 65bytes of the key in
> the
> > binary prefix of the
> > "raw_data" byte[] instead of having to add another key/value pair, with
> the
> > b64 encoding and proto
> > overhead. But it's an optimization - not the main reason :-). A nice
> extra
> > benefit is that browsers on android
> > could dispatch the message based on the raw_data only, since the EC
> public
> > key can identify the app/SW.
>
> As I said, I'm not opposed to this, it just seems wrong.
>
> Moving the public key into the body will cut into message budgets.
> We'll be at 3994 octets of plaintext maximum if we do that.  One of
> the nice things with the header field is that users don't pay for it.
> The bad thing is that the server needs to find a way to move it.
>
> If we are going to make this change, we need to be very crisp about it.
>