Re: [Webpush] Major change to encryption

[Costin Manolache <[e-mail]>]

I now understand your concern - no need to steal any octet, just define
that
real message size should be 4k. I believe aesgcm also adds few byes for
authentication - we can define that the cleartext can be 4k, with header
and crypto overhead excluded..

Costin

On Tue, Nov 1, 2016 at 9:43 PM Costin Manolache <[e-mail]> wrote:

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