Re: [Webpush] Application server authentication new years edition

Benjamin Bangert <bbangert@mozilla.com> Thu, 07 January 2016 02:11 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 CDE951A6F51 for <webpush@ietfa.amsl.com>; Wed, 6 Jan 2016 18:11:17 -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 74ro_9Yx-qAi for <webpush@ietfa.amsl.com>; Wed, 6 Jan 2016 18:11:14 -0800 (PST)
Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (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 347731A03AB for <webpush@ietf.org>; Wed, 6 Jan 2016 18:11:14 -0800 (PST)
Received: by mail-yk0-x230.google.com with SMTP id v14so232288466ykd.3 for <webpush@ietf.org>; Wed, 06 Jan 2016 18:11:14 -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=dIku4mCbTrKim3MNwK53XiDs60ETkznrgAsGuk3pEuQ=; b=PNq1KCdp4C3n/Ac4etGtcj2GjtPkeXrwawPbBCB854zTSedwgyHdUH17wN49DJS1H9 9bOLxkU1FxPKcuNfbtUTSiApOUqmOepLBbSWujemKSXauv9DI9N+zCZsCytcRDG0xuiP YjDFJcr8SyfdzxorCna5E6/6p6ZRi9xKyo0X/awRkm1ABgNhYqVShuWj+/ISDelkkV3q YmN/2ULoAOo0i6yse3y8K+bfZmRyvoVaKQOknZBLlcASBV3h5gwv86+N2aIt9xOPCFwp keh5RpbbJzUYyhulojWe+mObxzTqkvPPogn5R6CKQ8CgAaK+XoFI6J6Tg/w+IFQDYUqD ewLg==
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=dIku4mCbTrKim3MNwK53XiDs60ETkznrgAsGuk3pEuQ=; b=NBA7fuk0SSUKdTWu7NBoC3oDv/lfTr0Zgo3htd/V2lqaDd8Nr8Cm+2IKPt6ZGQVE4u GISMWdLs28sYKobwi0xLK97CJ+m5mu7PGuumA4xKTCxaivnToaku2rWTMLcPT7GBtiqf dbrX4JXzyd4ZbQRleXIL7vOV/Mv6eQEEkKpkne8FxyTgF/jlGKSEGzeKwgDshVu8n8Vv FWA8a/4uk6FOKKdSLk0/MwgNoWUk77aDIvSor/EJzp5vmmIwznviygPAvgJjl+XcHlfA T+NFtyES/Fd3v1IUusiM1os/o4umDXhETP0Hr0Yk63LmSnZYANvu11lE0/sAFhCN7Dji PC2Q==
X-Gm-Message-State: ALoCoQlBW7U0cLuIMsrxWbd+LHoe9Z9yt0LXbb2eNR9XT6KtuuJiD0uYIegocmdfCcJEXZiiC0HYldmZKny4Ja3yjlgxBf1Nkf2Q5FPKfKeAKa8DB7bZFjk=
MIME-Version: 1.0
X-Received: by 10.13.207.129 with SMTP id r123mr83993162ywd.27.1452132673346; Wed, 06 Jan 2016 18:11:13 -0800 (PST)
Received: by 10.37.224.9 with HTTP; Wed, 6 Jan 2016 18:11:13 -0800 (PST)
In-Reply-To: <CAP8-Fqmzc9pWdDLCBiEs1YvtcKrbGN5TYR86PoaeNBc0wmA2Ew@mail.gmail.com>
References: <CABkgnnXBHXfY6Gz-FKGVUUoOwyJo9zaw1rWceSqVp94FypDbJA@mail.gmail.com> <CAP8-Fq=PhUcj5aaE6dvF2_+-HmVrGDyk41QBzkVxiNMxUakoag@mail.gmail.com> <CABkgnnUYkuu9pjuqLDhiWLNWzkr9ZfYRNny4ZvSKRTWie2bQyA@mail.gmail.com> <568D41D6.40904@mozilla.com> <CAP8-FqnnYtQrBbngna5a6PqfXxawq-ORh-HFA85tJ56VsNd=LA@mail.gmail.com> <CABp8EuLspfCA6+YfoSH_JOKi1To4EH4G22vkf_ZS3v397HtCJA@mail.gmail.com> <CAP8-Fqmzc9pWdDLCBiEs1YvtcKrbGN5TYR86PoaeNBc0wmA2Ew@mail.gmail.com>
Date: Wed, 6 Jan 2016 18:11:13 -0800
Message-ID: <CABp8EuJT3yYLgSgx3f3jUEwtspHU14TT+GCv1o6th5LLfPjtHA@mail.gmail.com>
From: Benjamin Bangert <bbangert@mozilla.com>
To: Costin Manolache <costin@gmail.com>
Content-Type: multipart/alternative; boundary=001a114e68862997e90528b4fcf6
Archived-At: <http://mailarchive.ietf.org/arch/msg/webpush/ryviyTW96XtQINeffCO00bFmku8>
Cc: jr conlin <jconlin@mozilla.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 02:11:18 -0000

On Wed, Jan 6, 2016 at 5:43 PM, Costin Manolache <costin@gmail.com>; wrote:

> On Wed, Jan 6, 2016 at 2:24 PM, Benjamin Bangert <bbangert@mozilla.com>;
> 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.



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

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.

Cheers,
Ben