Re: [Webpush] Major change to encryption

[Costin Manolache <[e-mail]>]

AFAIK the "DH" public key must be sent to the device no matter what.

Right now for GCM, if you use the webpush endpoint the headers end up in
the key/value pairs, as base64, while the binary data goes in the raw_data.
I have no problem if the spec defines that the binary header should be
excluded - and
 push services support 4k of real data ( i.e. continue to exclude the
header overhead).

If transmitting over other transports - somehow we need to send the dh
public key and
the body - if it doesn't fit a tickle+poll or segmentation need to be used.
The fact the
 public key was received in a header or was part of the body doesn't change
this.

Costin

On Tue, Nov 1, 2016 at 9:02 PM JR Conlin <[e-mail]> wrote:

> ​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.
>
>
>