Re: [Webpush] Application server authentication new years edition

Benjamin Bangert <bbangert@mozilla.com> Thu, 07 January 2016 20:56 UTC

Return-Path: <bbangert@mozilla.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 39C661A0016 for <webpush@ietfa.amsl.com>; Thu, 7 Jan 2016 12:56:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 E-doyeGyrhij for <webpush@ietfa.amsl.com>; Thu, 7 Jan 2016 12:56:12 -0800 (PST)
Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (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 AB6431A00BE for <webpush@ietf.org>; Thu, 7 Jan 2016 12:56:12 -0800 (PST)
Received: by mail-yk0-x232.google.com with SMTP id k129so320269632yke.0 for <webpush@ietf.org>; Thu, 07 Jan 2016 12:56:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c+unUPKATTA0bDXEk+DSk/trJGOgUJOEr82EXP07Ju4=; b=NUfKl7DWsgHOgzq5a8unWM7y8NPdQPYdrovxj5l/wvDN+61WKP+mTxMq/ajZwdZT4k vxJkkYBGjPTu1Q31SVtxl1cTHiG8kKFNjRPD9uonvnfen75O/9v8a3QWXHk5QkvALWgR YtYAmDXEWdUP76kdVt4GAU223pVb4cEQ5kg1ZDN7UehZ+xEsxfDHHQo5HOCgmsST2Cjz f5C0WV+XibpvtgGPNCC1VqQMadjYeA/QSexcXJBkqmaGv3PJwWGo6YHJJgieLbbzk0Ne MDD813pOwToUtWRM1PZq8i4A6bcwGDkbozcZqyJUmVw+ly9PhbS1FYf+vT7l+yo/DhMI uWKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=c+unUPKATTA0bDXEk+DSk/trJGOgUJOEr82EXP07Ju4=; b=UlsLlOMDmma3XnrQkPqzkEqHau2tJAEwNlD20HUwIUozlrrKMI8ZRRXPG/ztEhNueJ 6ATyCtmXlwo7N6qIPpeHivNWzKUknntq5V907gYI2TwNTE1Qt2eTEenHavPB9yyEWi5v nikxPC43G+KA/NuGugQa23yjWbqXzqA/SC/xxGeBcyg3IZOh1oax7Ew0BaW6G6RNmRYo /AewA7W9cC69Dkfybe1/LAr6k0eoWEnfu2UzhZajis5eZFMJo9mGbCpBGm7zuG3sKpZJ bJysYFjpDAE0ezy11r8BmLNnN8hkGDkpilTLtGyd1dnmlbGxslbSYhBxr6ZEVchyARqJ 3CZg==
X-Gm-Message-State: ALoCoQnlMtB/rCka8thq/DIsxgqCcKKSP63r0lXA4ijbvI9nBKIuf5LeIncrMttQOAy+EX3dWjHApcqU8bp24lJE6iyANLnsDBWq/plnAKVgf3x4a7v0t3g=
MIME-Version: 1.0
X-Received: by 10.13.218.129 with SMTP id c123mr86946863ywe.4.1452200171831; Thu, 07 Jan 2016 12:56:11 -0800 (PST)
Received: by 10.37.224.9 with HTTP; Thu, 7 Jan 2016 12:56:11 -0800 (PST)
In-Reply-To: <CAP8-Fqnage13JQiz8Qkvrho-e8DWcw8p_NLd_xux+uQALwD7og@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>
Date: Thu, 07 Jan 2016 12:56:11 -0800
Message-ID: <CABp8EuJZpe-4T7LQStyeTi-L95rq5duXxxkxExN7ZOXoSsE-yA@mail.gmail.com>
From: Benjamin Bangert <bbangert@mozilla.com>
To: Costin Manolache <costin@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c08090c62c03c0528c4b354"
Archived-At: <http://mailarchive.ietf.org/arch/msg/webpush/ZRps3NE_f5JneaKWD9woNSDQ-CQ>
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 20:56:16 -0000

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.


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


> 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