Re: [Webpush] Protocol proposal updated

[Costin Manolache <[e-mail]>]

I have a few small suggestions - I'll start with what is more blocking:

1. The push server needs some way to authenticate the sender. I understand
the Channel URL is used as a bearer token ( which is probably not
a good idea, but separate issue ), and UA can reject the message if the
encryption fails, but the push server still needs to deliver
the message if the bearer token ( channel URL ) becomes compromised.
The push server may also need quotas or TOS agreements (or in some cases
billing ? not all push servers are free) with the sender.

2. Expiration: this creates some load problems if too many devices attempt
to re-register at the same time. It would be preferable for the push server
to request renewal of registration or channel - it can do this with special
control messages send from the push server.
This will also allow the server to address some special use cases - device
registration that become invalid (it happens after some backup/restore for
example,
or on storage corruption on low memory, and few other obscure cases) or for
security reasons, if keys need to be rotated or invalidated.

3. Authentication - I think some form of authentication is needed in all
layers, use of the URL as auth, server address and identity is not very
common.
The registration, channel and sender all need to authenticate with either
shared secrets, oauthx or certificates - and the auth needs to
be managed separately, i.e. tokens may need to be rotated, invalidated, etc.

4. Encryption of messages - it needs to be specified what format it is -
can be simple openpgp (rfc4880), or anything else. Otherwise no
interoperability.
It seems the rfc requires encryption, which is great, but it still need
more authentication than 'can't decrypt the message'. I'm also not sure if
using the
 public key of the channel as a secret is the best option - but it may work
(usually public keys are treated as public).


Costin

On Wed, Oct 8, 2014 at 5:15 PM, Martin Thomson <[e-mail]>
wrote:

> I've just submitted an updated version of my push protocol proposal:
>
> https://tools.ietf.org/html/draft-thomson-webpush-http2
>
> And a new proposal that builds on the first for dealing with the
> delivery of the same message to multiple recipients:
>
> https://tools.ietf.org/html/draft-thomson-webpush-aggregate
>
> One feature of these proposals is that they assume the presence of
> something in the W3C API that is not currently there related to push
> message security.  If the API can force end-to-end security, I think
> it would be strictly a good thing.  I'm happy to articulate the
> proposed solution, or you can read my proposal here:
>
> https://github.com/w3c/push-api/issues/55
>
> _______________________________________________
> Webpush mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webpush
>