Re: [Webpush] Application server authentication new years edition

[Costin Manolache <[e-mail]>]

On Thu, Jan 7, 2016 at 12:56 PM, Benjamin Bangert <[e-mail]>
wrote:

> On Thu, Jan 7, 2016 at 10:59 AM, Costin Manolache <[e-mail]>
> wrote:
>
>>
>>
>> On Wed, Jan 6, 2016 at 11:53 PM, Martin Thomson <[e-mail]
>> > wrote:
>>
>>> On 7 January 2016 at 16:43, Costin Manolache <[e-mail]> wrote:
>>> > That leaves 2.3 only.
>>>
>>> It looks like we're mostly in agreement for something like 2.3.
>>> Should I take some time and flesh out the details?  Does anyone
>>> disagree?
>>>
>>
>> Sounds good, but I have few questions/comments on the details.
>>
>> 1. Key identifiers ('kid') - for normal JWT, the key is known from the
>> issuer or
>> 'sub'. Since in our case we'll have self-generated keys, and we want to
>> avoid
>> having each key registered with all providers - all that a push service
>> will know
>> when seeing a JWT token the first time will be the content of the token.
>> So we need a way to find the public key needed to verify the content -
>> and
>> the only one I know is to use something like the SHA of the public key.
>> On subscribe - the provider can store the public key, with the kid as
>> lookup key, than
>> on send it can verify. For example kid == (SHA1 or SHA256 truncated to
>> 64bits) would work.
>>
>
> If an app-server has a private key leak and needs all its users to rotate
> sender keys, that will also tie up a substantial amount of server resources
> having such a large unsubscribe/subscribe cycle.
>
> Key rotation for private keys is common in many cases already, it'd be
> nice if such a thing wasn't expensive for the server.
>
>

Key rotation can be spread over a long interval - normal subscriptions
expire anyways and need to be rotated,
 so for a periodic rotation it shouldn't add extra load. The push service
itself may rotate its keys (assuming that
the URLs are generated using keys) - which will also likely be staged with
the periodic expiration of subscriptions.

If only the private key is leaked - I assume it's a tradeoff, users are
still protected by
the secrecy of the URL/secret-public key.

For 'my private key AND the database of subscription have been stolen' - I
don't think there
are many options except taking the extra load hit (for the general case).
Some providers may
allow additional options - in particular if the public key is linked to
some developer account
(for tools or other purposes).

( we discussed in the past the case of 'private keys of the push service
leaking', and at least the js API
has support for handling it )


> 2. 'aud' field - not sure what would be the right value, maybe the domain
>> of the push provider ?
>>
>
> I know it doesn't seem popular to include stronger authentication at this
> layer.... but if 'aud' was the domain (or sub-domain for per-push-provider
> public keys), and there was a DNS TXT record that contained the JWT public
> key then the push service would have a way to lookup the key. It'd also
> allow the app-server to rotate keys used without all the push clients
> needing to resubscribe.
>
> This would bump the authentication to domain verified, while remedying the
> issue of how to get the public key to the push service and reducing server
> resources needed to handle sender key rotation.
>

Audience is one of the most confusing concepts :-). My understanding is
that it means 'identifies who will
process/consume the JWT token', in our case the push service provider. The
draft defines it as 'full push resource URL',
meaning developer needs to generate a new token for each message. I think
using just the domain name
is more efficient ( less overhead on client, possible caching on server ) -
and it's what Oauth2 is doing as well.


Using DNS TXT records or any other mechanism for verifying the 'contact
info' - i.e. the domain of the
sender is tricky, and on top there is strong opposition to even include
contact info in requests.
I suggest leaving this for a separate discussion/standard. But I agree, if
a 'contact info' is provided, it
would be good to use DNS TXT records or even a "well known" URL to fetch
the current public key.



>
>
>> 3. Going back to the 'voluntary'/optional part: I'm not sure if
>> encryption is going to be required or
>> optional in the final version ?
>>
>> 4. I think we can have the sender key optional in the subscribe
>> operation, in particular for cases
>> like low end IOT - not including it would give permission to anyone with
>> the URL and pubkey
>> of the device to send messages. There is another case where it helps -
>> pairing, in cases of D2D -
>> but with restrictions ( either time, or binding the subscription to the
>> sender at first use ).
>> In other words: I'm not opposed to having 'optional' on the subscribe
>> (and on contact info).
>>
>> 5. This may be a bit controversial :-), if we require the developers to
>> use a JOSE library to
>> generate JWT tokens, signed with a ES256 - wouldn't make sense to also
>> allow them to use
>> the same library to encrypt the payload for the e2e ? There is already a
>> content type defined, so easy to
>> differentiate.
>>
>
> +1 on simplifying this for developers.
>
> Cheers,
> Ben
>
>