Subject: [Webpush] Protocol proposal updated

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Oct 2014 17:15:27 -0700

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

---

From: Arthur Barstow <[email-masked]>
Date: Wed, 08 Oct 2014 20:49:15 -0400

> https://tools.ietf.org/html/draft-thomson-webpush-http2

Speaking of new publications, FYI, on October 7 a new snapshot of Push 
API was published [WD], although the Editor's Draft [ED] reflects the 
latest developments (f.ex. bug fixes).

[WD] <http://www.w3.org/TR/2014/WD-push-api-20141007/>
[ED] <https://w3c.github.io/push-api/>

---

From: Costin Manolache <[email-masked]>
Date: Fri, 10 Oct 2014 11:52:54 -0700

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 <[email-masked]>
wrote:

> _______________________________________________
> Webpush mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webpush
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Oct 2014 12:53:14 -0700

Thanks for the feedback Costin,

These are things that I have considered, and they do need to be better
addressed in the draft.  I want to open a new thread about the two
questions you asked on authentication, because I think authentication
is a big deal and it ties into a lot of things.  If we don't have some
sort of common understanding about how this works, we're not going to
get far.

The other two points are, I think, less of a concern.

> control messages send from the push server.

This is something that proprietary protocols already have to deal
with, certainly.  You can either let clients deal with it and suffer
the stampeding herd problems that come when clients re-register
en-masse, or you can trigger something.

While it's not explicit, an HTTP-based protocol, as proposed, permits
a server to expire a registration at any time.  This could trigger
re-registration.  The server can do that by providing a response to
the hanging GET that we use to monitor for pushed messages.  This has
the intended effect, though the process remains under the control of
clients.

> 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

I can see how this might be confusing.  Yes.  There definitely needs
to be a format specification for the encrypted message.  But at the
level of the protocol itself, there is only one place that matters
(you will see this in the -aggregate draft).  The thing here is that
there should be no need to enforce format restrictions at the protocol
level.  It's the browser API that ultimately will care that the
message is encrypted (and decryptable).

I'm going to propose that we use the JSON encoding of JWE (again see
the -aggregate draft), but that is something that will land in the W3C
specification ultimately.

---

From: Costin Manolache <[email-masked]>
Date: Fri, 10 Oct 2014 13:42:26 -0700

> the intended effect, though the process remains under the control of

I think we're in agreement - but the draft is saying a different thing ( or
I'm reading it wrong ).

According to draft: when the client register or creates a channel (
independent of them listening for notifications )
they do get a max-age and/or Expires. That means the client app or UA must
renew before it expires.

What I'm suggesting - and you seem to - is that part of the hanging GET
that monitors for pushed
messages you will get the server to expire a registration or channel ID.
The format needs to be
specified - it needs to include the channelId that is getting expired or if
the registration id itself is expired.

Expiring the registration (i.e. the device identity and credentials) is
pretty simple in this case, the monitor
request can return a status code.

The issue is how can the server send to the app the message that its
channel needs to be renewed
during the hanging GET, with server controlling the rate and timing - i.e.
which synthetic GET or
other control message is sent and with which parameters.

> can
> more

The JWE is a bit too verbose for mobile - having a base64 / web safe
encoding
 in the binary payload of the message seems too chatty.
This matters the most when sending the message from the 3p server to the
push server -
which is also probably sent as binary payload, I couldn't find the proposed
details.

I also suspect there would be more libraries/implementations and experience
on using a (relatively)
common encoding like pgp.

In any case - the push server would need to do some validations and in
particular if JWE is used
to re-package in more compact form for transmission to mobile devices.

Costin