Re: [Webpush] Application server authentication new years edition

[Martin Thomson <[e-mail]>]

Mega-multi-response.

On 7 January 2016 at 05:01, Costin Manolache <[e-mail]> wrote:
> At the same time you can't force push service providers to accept
>  unauthenticated/unauthorized sending either. Or require them to
> provide unlimited (and free) service to everyone regardless of how much
> they're abusing/hurting users or networks.

The authorization question is challenging, particularly when it comes
to abuse of limited resources (user attention, battery power, push
service capacity).  It would be good to understand what the invariants
are on each service.

If Google are unwilling to allow completely unauthenticated requests,
then I think that we could insist on something voluntary.  I'm
reluctant to do that because it makes it more difficult for
application server developers to get a start, but that can be mitigate
with good tooling, I guess.

On the other hand, if there are cases where a small number of requests
can be made without extra authentication, then the proposed option
would be ideal.  That would allow people to experiment a little before
having to tool up.

> How about 2.1 AND 2.3 ? Push servers should support both, clients
> should use what they can.

I'd like to avoid that situation because it hurts a lot more all
around.  We like to save that option for the really tough problems
(video codecs, for example).

> And it may be the way to allow the choice on app server side - either by
> having an 'isAuthorizationRequired()' or an error code when attempting to
> subscribe without a public key.

Again, that makes it more difficult to use the API, and I'd be very
reluctant to take that option unless the alternatives are untenable.

On 7 January 2016 at 06:29, Costin Manolache <[e-mail]> wrote:
> That leaves 2.3 only ? I think it's ok - it relies on the same thing as TLS
> client auth, the sender
> signing with the private key, and push service checking it against the
> public key provided at subscribe time.
> Can we at least make it consistent with the the encryption - i.e. use the
> same type of key ?

We can certainly use P-256 for that as well; that's what is proposed.
However, it would need to be a different key pair, since all the
experts recommend against using the same key for signing and key
exchange.  (There isn't an actual attack, but the dual use isn't
provably safe.)

On 7 January 2016 at 12:43, Costin Manolache <[e-mail]> wrote:
> Yes, they would also verify contact info - I have a feeling we're trying to
> avoid relying too much on
> the contact info ( i.e. domain name of the app server ). If the contact info
> is voluntary - I don't think we need
> to make it too complex by adding verification.

I very much agree with this sentiment.  That contact information can
be verified, though I think that we should probably start out by
relying on manual processes for that.  We can layer other mechanisms
on top.

I'm not particularly fond of the idea of using something as
heavyweight as what Ben suggested.  Something much simpler might work,
but I don't think that we need that.  An absolute requirement to use
something that that would be a big problem.

On 7 January 2016 at 13:11, Benjamin Bangert <[e-mail]> wrote:
> Right, that this is not strongly authenticated means we can't do something
> like build a developer dashboard that might expose notification traffic
> information associated with the JWT. ie, if a Push Service wanted to provide
> developers with a diagnostic dashboard similar to what GCM Diagnostics
> provides GCM users.

If this is your concern, why not ask the dashboard user to prove that
they have access to the JWK private key when logging in?  That's
relatively easy to do.  You don't actually need to know who they are
in that case.  (Though you could use the dashboard UI to do things
like email verification, as many sites do.)