Re: [Webpush] Application server authentication new years edition

[Benjamin Bangert <[e-mail]>]

On Wed, Jan 6, 2016 at 5:43 PM, Costin Manolache <[e-mail]> wrote:

> On Wed, Jan 6, 2016 at 2:24 PM, Benjamin Bangert <[e-mail]>
> wrote:
>
>> 2.3 would allow us to get the data, but it doesn't address strongly
>> authenticate senders.
>>
>
> 2.3 is not authenticating the contact info provided by senders, just that
> sender is the same that
> the UA requested.
>
> The subscribe in the UA includes the public key of the sender, and 2.3
> AFAIK strongly authenticate
> the fact that the sender has access to the private key.
>
> The contact information they chose to include in the JWT is not
> authenticated at all  the push
> service can only verify the sender is what the UA authorized, and can
> block/throttle that sender without
> affecting other senders.
>

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.



>
>
>
>>
>> Discussing this earlier with my manager, there are two additional schemes
>> that we could consider instead of or in addition to 2.3 on a voluntary
>> basis for app-servers.
>>
>> - DKIM: Re-use DKIM in some manner so that an app-server can claim a
>> domain its sending notifications on behalf of. Since DKIM also includes a
>> body hash, it could be used instead of JWT if an app-server wishes to
>> strongly authenticate.
>> - Lets Encrypt Domain Validation: The Lets Encrypt folks have a scheme
>> and tools that automate Domain Validation to prove ownership of a domain
>> (though it unfortunately needs to be tied into a webserver, DKIM is nicer
>> in that aspect of only requiring a DNS addition).
>>
>> Both of these would allow an app-server to change the JWT secret being
>> used if needed with no interaction needed with the push service.
>>
>
> 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.
>
> Rotating the identity and keys used by sender normally happens when the
> app is updated, the sender can subscribe with the new key, and can use 2
> subscriptions while migrating. The fact that subscriptions can be
> rotated or can expire helps. Would be good to mention in the draft that a
> push service that requires or accepts subscription
> association (== authorization) should also allow multiple subscriptions
> for an app.
>
> I would expect verification of the sender to be useful for non-free
> services - in which case the public key
>  of the sender will need more than verification (i.e. will need to be
> associated with a credit card :-)
>
>
Ah, in our case we were thinking of providing some basic diagnostic
information in a dashboard free-of-charge. I didn't think the GCM
Diagnostic panel required payment, but it uses the strong authentication by
requiring a sign-up process and such.

I was hoping that there would be some way push service providers could
provide a higher degree of authentication in a standard way that wouldn't
require app developers to go through extensive sign-up processes at each
push service, but perhaps that's just wishful thinking.

Cheers,
Ben