Re: [Webpush] Application server authentication new years edition

Costin Manolache <costin@gmail.com> Thu, 07 January 2016 21:33 UTC

Return-Path: <costin@gmail.com>
X-Original-To: webpush@ietfa.amsl.com
Delivered-To: webpush@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6801A0149 for <webpush@ietfa.amsl.com>; Thu, 7 Jan 2016 13:33:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoJKEZWbYmVy for <webpush@ietfa.amsl.com>; Thu, 7 Jan 2016 13:33:19 -0800 (PST)
Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C27721A0145 for <webpush@ietf.org>; Thu, 7 Jan 2016 13:33:18 -0800 (PST)
Received: by mail-ob0-x22e.google.com with SMTP id wp13so202852375obc.1 for <webpush@ietf.org>; Thu, 07 Jan 2016 13:33:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.182.19.164 with SMTP id g4mr80115145obe.15.1452202398082; Thu, 07 Jan 2016 13:33:18 -0800 (PST)
Received: by 10.76.8.74 with HTTP; Thu, 7 Jan 2016 13:33:17 -0800 (PST)
In-Reply-To: <CABp8EuJZpe-4T7LQStyeTi-L95rq5duXxxkxExN7ZOXoSsE-yA@mail.gmail.com>
References: <CABkgnnXBHXfY6Gz-FKGVUUoOwyJo9zaw1rWceSqVp94FypDbJA@mail.gmail.com> <CAP8-Fq=PhUcj5aaE6dvF2_+-HmVrGDyk41QBzkVxiNMxUakoag@mail.gmail.com> <CABkgnnUYkuu9pjuqLDhiWLNWzkr9ZfYRNny4ZvSKRTWie2bQyA@mail.gmail.com> <CAP8-FqnSqtMb5bT14tkycYXOOP+Xmoa9SMjuP5KkeN_ri+_NVQ@mail.gmail.com> <CABkgnnU0CP-fGpEfqLo01ZVdjT3dNVeb3MSufO1P8T2W63dNVw@mail.gmail.com> <CAP8-FqkF9X+_CjSyXB10621L0=b756REjXsbRfsL8rT6nuh9pw@mail.gmail.com> <CABkgnnW7oRTZRKDQcxf9=0f-mxKfctQQTrR5zY6q4qJtL_cPjw@mail.gmail.com> <CAP8-Fqnage13JQiz8Qkvrho-e8DWcw8p_NLd_xux+uQALwD7og@mail.gmail.com> <CABp8EuJZpe-4T7LQStyeTi-L95rq5duXxxkxExN7ZOXoSsE-yA@mail.gmail.com>
Date: Thu, 7 Jan 2016 13:33:17 -0800
Message-ID: <CAP8-Fqn=T1qpK8cb=6E+Jf5siuUkuqPo0pKC_qhkVh3n-T7U-w@mail.gmail.com>
From: Costin Manolache <costin@gmail.com>
To: Benjamin Bangert <bbangert@mozilla.com>
Content-Type: multipart/alternative; boundary=001a11c2a5f61471cd0528c5387c
Archived-At: <http://mailarchive.ietf.org/arch/msg/webpush/xrqo-LUb7mrPV6eF1xgyJoqMgCU>
Cc: Costin Manolache <costin@google.com>, Martin Thomson <martin.thomson@gmail.com>, "webpush@ietf.org" <webpush@ietf.org>
Subject: Re: [Webpush] Application server authentication new years edition
X-BeenThere: webpush@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of potential IETF work on a web push protocol <webpush.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webpush>, <mailto:webpush-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/webpush/>
List-Post: <mailto:webpush@ietf.org>
List-Help: <mailto:webpush-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webpush>, <mailto:webpush-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2016 21:33:21 -0000

On Thu, Jan 7, 2016 at 12:56 PM, Benjamin Bangert <bbangert@mozilla.com>;
wrote:

> On Thu, Jan 7, 2016 at 10:59 AM, Costin Manolache <costin@gmail.com>;
> wrote:
>
>>
>>
>> On Wed, Jan 6, 2016 at 11:53 PM, Martin Thomson <martin.thomson@gmail.com
>> > wrote:
>>
>>> On 7 January 2016 at 16:43, Costin Manolache <costin@gmail.com>; 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
>
>