Re: [Webpush] Major change to encryption

[Costin Manolache <[e-mail]>]

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.

Costin




On Tue, Nov 1, 2016 at 12:46 PM jr conlin <[e-mail]> wrote:

> I'll agree that putting as much crypto in the message would be great. One
> thing to note is that when messages are delivered over bridged connections
> (like GCM/FCM or APNs) all that added content eats into the preciously
> small available delivery content. Particularly when you have to encode to
> base64 for JSON envelopes.
>
> We should strive to have as little required "prefix" content as possible,
> else folks wind up only able to send a few hundred bytes across.
>
>
> On 11/1/2016 10:58 AM, Costin Manolache wrote:
>
> Using the Crypto-Key for vapid is fine with me - I have no problem with
> keeping it for this purpose, in vapid spec. Or to use Crypto-Key in
> other specs that deal with key distribution or other things.
>
> However I still think that for consistency, the dh-public key used for
> decrypting
> the message should be in the binary header, next to salt - maybe even
>  using the 'key id' field ( renamed to 'symmetric key id or public key' ).
> The binary blob should be sufficient to decode the message, if the
> content-encoding is known, using secrets known to the receiver ( symmetric
> key in http case, or EC private key for webpush ).
>
> I think it's important to recognize that client-to-pushservice
> communication
> may use different transports, in addition to http/2 push promises. In
> particular
> it may be layered over Webcoket, newly proposed WiSH, etc - and in many
> cases the implementation will be greatly simplified if the binary blob can
> be sent as-is (after any protocol-specific authentication ).
>
> Costin
>
>
>
>
> On Mon, Oct 31, 2016 at 4:57 PM Martin Thomson <[e-mail]>
> wrote:
>
> Hi Peter and JR,
>
> Thanks both for picking up on my stupid errors.  Hasty is not always
> careful enough, but I was working to a time limit.  With 5 minutes
> left, I think that I managed to get all your input integrated.
>
> And your reminder about vapid was timely.  I think that we can
> dispense with any attempt to remove Crypto-Key, since we have to have
> it for vapid anyway.
>
> Now I need to think about getting the python implementation updated.
>
> --Martin
>
> On 1 November 2016 at 10:31, Peter Beverloo <[e-mail]> wrote:
> > Hi Martin,
> >
> > Thanks for the update and the proposal!
> >
> > I've reviewed these today, and have minor some points of feedback. I'll
> > deliberately avoid the topics of interoperability and upgrade cost here.
> >
> > First of all, this indeed vastly improves layering between the drafts. I
> > very much like how webpush-encryption is now built on top of encryption-
> > encoding as opposed to being some sort of fork.
> >
> >>> A push message MUST include a zero length keyid parameter in the
> >>> content coding header. This allows implementations to ignore the first
> >>> 21 octets of a push message.
> >
> > I don't think this is right. The `salt` and the `rs` must still be known,
> > and those are included in the header.
> >
> >>> A push service is not required to support more than 4096 octets of
> >>> payload body (see Section 7.2 of [I-D.ietf-webpush-protocol]), which
> >>> equates to at most 4059 octets of cleartext.
> >
> > I think this forgot about the padding --
> >
> >   4096 - 16 (auth) - 2 (padding length) - 21 (header w/o keyid) = 4,057
> >
> > May also want to s/cleartext/plaintext/ for consistency with encryption-
> > encoding.
> >
> >>> An Application Server MUST include exactly one aes128gcm content
> >>> coding, and at most one entry in the Crypto-Key field. This allows the
> >>> keyid parameter to be omitted.
> >
> > This means the draft is incompatible with VAPID again. It must have at
> > most one Crypto-Key entry that has a `dh` value.
> >
> > I haven't yet been able to validate the examples in the draft, but it
> > sounds like you're changing these anyway per jr's feedback (+1 to that).
> >
> > Thanks,
> > Peter
> >
> >
> > On Mon, Oct 31, 2016 at 11:19 PM, Martin Thomson <
> [e-mail]>
> > wrote:
> >>
> >> On 1 November 2016 at 10:07, jr conlin <[e-mail]> wrote:
> >> > One small comment, then? Can we change the transmitted
> Content-Encoding
> >> > type to match the new Content-type of "aes128gcm" instead of the long
> >> > abandoned "aesgcm128"? (See point #4)
> >>
> >> Ouch, that's going to hurt.  I'll have to redo the examples :*(  40
> >> minutes until the deadline, go!
> >>
> >> _______________________________________________
> >> Webpush mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/webpush
> >
> >
>
> _______________________________________________
> Webpush mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webpush
>
>
>