Subject: Re: [Webpush] Stephen Farrell's No Objection on charter-ietf-webpush-00-00: (with COMMENT)

From: Costin Manolache <[email-masked]>
Date: Thu, 2 Oct 2014 08:04:27 -0700

On Tue, Sep 30, 2014 at 3:10 PM, Martin Thomson <[email-masked]>
wrote:

> On 30 September 2014 14:07, Stephen Farrell <[email-masked]>
> wrote:
> > Do we have any worked examples of using security (and caring
> > about privacy) here though? I remain concerned that its too easy
> > to just say "turn on push" for <foo>, where the security and
> > privacy consequences of doing so are unknowable for <foo>. But
> > maybe I'm worrying over not so much and a worked example will
> > help.
>
> OK, so the intent of the proposed security mechanism is that the
> easiest thing to do is to provide end-to-end security.
>
> How we'd do that is the API returns two things to the application
> running in the browser: a location to send messages and a key with
> which to encrypt them.  If you don't encrypt them, then the browser
> will fail to deliver pushed messages.
>

(from android/gcm perspective): there are quite a few developers using
push with multiple 'senders', i.e. the app can receive messages from
different organizations that don't share keys.  There is also the case
 of 'groups' - where the entire group may need a shared key.

I think the API will need to be able to return multiple keys, based on the
sender. There is also the issue of authorizing the send - so you need
to return at least 2 keys, one that is shared with the push provider
and is used to authorize the send ( 'registration id' in gcm ), and the
encryption key that will not be shared with the provider.

>
> The keying material isn't used in the message delivery at all.  An
> application running on the server can send anything to the browser
> over the push channel, but if the message doesn't decrypt and
> authenticate with the selected key, it doesn't get delivered.  It's a
> little odd to effectively hold functionality hostage like that, but I
> think that it will work.
>

Yes, it works - even without any intervention from the push provider, i.e.
there are apps that generate the key and do end-to-end encryption on top
of gcm. Allowing a binary payload is probably the best way to help them.

Costin

>
> I won't lie, we can't prevent someone outside of the browser context
> from only using the hop-by-hop security mechanisms.  I can't help but
> be optimistic that a demonstration of feasibility will help shift
> those use cases too.  It's possible that this sort of mechanism could
> be enforced at the operating system level in the same way.
>

>
> Ever the eternal optimist, I suppose.
>
> _______________________________________________
> Webpush mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webpush
>