Re: [Webpush] Application server authentication new years edition

Benjamin Bangert <> Thu, 07 January 2016 02:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CDE951A6F51 for <>; Wed, 6 Jan 2016 18:11:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 74ro_9Yx-qAi for <>; Wed, 6 Jan 2016 18:11:14 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 347731A03AB for <>; Wed, 6 Jan 2016 18:11:14 -0800 (PST)
Received: by with SMTP id v14so232288466ykd.3 for <>; Wed, 06 Jan 2016 18:11:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id r123mr83993162ywd.27.1452132673346; Wed, 06 Jan 2016 18:11:13 -0800 (PST)
Received: by with HTTP; Wed, 6 Jan 2016 18:11:13 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Wed, 6 Jan 2016 18:11:13 -0800
Message-ID: <>
From: Benjamin Bangert <>
To: Costin Manolache <>
Content-Type: multipart/alternative; boundary=001a114e68862997e90528b4fcf6
Archived-At: <>
Cc: jr conlin <>, "" <>
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 02:11:18 -0000

On Wed, Jan 6, 2016 at 5:43 PM, Costin Manolache <> wrote:

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