Re: [Webpush] Application server authentication new years edition

Costin Manolache <> Thu, 07 January 2016 21:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5D6801A0149 for <>; Thu, 7 Jan 2016 13:33:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FoJKEZWbYmVy for <>; Thu, 7 Jan 2016 13:33:19 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C27721A0145 for <>; Thu, 7 Jan 2016 13:33:18 -0800 (PST)
Received: by with SMTP id wp13so202852375obc.1 for <>; Thu, 07 Jan 2016 13:33:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xSVi+f9cuRlZ8WuTw5f1jkIZvxNalqCauAd/o8uTiso=; b=OMuyB86jKD4xNXsEUh28Ac2HWlo0Z2j8F8SYYOvMx8St2dD/avCvchc2/kSmquebH4 EKoJzTPwKiqdxLOr9EdMVi5qZFPjBxh+3iczy+b/kuRu25/2EUruwRMG9ZnugFDKnbGx Iq7vaDDFnFb7z/VuxiDwtwJHjQ4YoGDOk26ndqChFf6/GSoM9RZ7a1NBjWnWmn3GAmlZ 20X9nAYBcYk07DP/3OiT5tdNn/VnqV6Gg8urhvalHLR6EblHGnw5qOOw67qkz2i912oo vvNP4TP9zxJx8IovrMY6YO4UumLnG5tT/gQXmMj952Hndsj26SzJnsRRn/PWqMbLEuCy SRHQ==
MIME-Version: 1.0
X-Received: by with SMTP id g4mr80115145obe.15.1452202398082; Thu, 07 Jan 2016 13:33:18 -0800 (PST)
Received: by with HTTP; Thu, 7 Jan 2016 13:33:17 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Thu, 7 Jan 2016 13:33:17 -0800
Message-ID: <>
From: Costin Manolache <>
To: Benjamin Bangert <>
Content-Type: multipart/alternative; boundary=001a11c2a5f61471cd0528c5387c
Archived-At: <>
Cc: Costin Manolache <>, Martin Thomson <>, "" <>
Subject: Re: [Webpush] Application server authentication new years edition
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of potential IETF work on a web push protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Jan 2016 21:33:21 -0000

On Thu, Jan 7, 2016 at 12:56 PM, Benjamin Bangert <>

> On Thu, Jan 7, 2016 at 10:59 AM, Costin Manolache <>
> wrote:
>> On Wed, Jan 6, 2016 at 11:53 PM, Martin Thomson <
>> > wrote:
>>> On 7 January 2016 at 16:43, Costin Manolache <> 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