Re: [Webpush] Application server authentication new years edition

[Costin Manolache <[e-mail]>]

On Wed, Jan 6, 2016 at 6:11 PM, Benjamin Bangert <[e-mail]>
wrote:

> 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.
>

That shouldn't be a problem - there are many ways you can associate a real
developer account with the public key,
using the private key to sign a statement.

Or you could exchange a JWT with a cookie or token that allows access to
the dev tools, without requiring a separate
account.



>
>
>
>>
>>
>>
>>>
>>> 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.
>

GCM doesn't require payment for diagnostic or anything else, but there are
providers that charge, and for them
the 'contact info' would be more important and need to be more specific.




>
> 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.
>

It is not impossible - once we have the auth defined, it can be used to
access other endpoints - debugging, etc.
But probably their definition will need to be in a separate future draft.

Costin