Re: [Webpush] Application server authentication new years edition

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9DD0F1A21A3 for <>; Wed, 6 Jan 2016 21:21:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mGkmdErZO8T9 for <>; Wed, 6 Jan 2016 21:21:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B80E1A1BFE for <>; Wed, 6 Jan 2016 21:21:21 -0800 (PST)
Received: by with SMTP id ba1so318027317obb.3 for <>; Wed, 06 Jan 2016 21:21:21 -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=e09Boqp8ATSeSuFNdHoUeOGJxEfFFrNUaUIpXAqnoY0=; b=DM/koGpX2K3bCzjSSTX+hR5O2TVxHNmciDJXA0/fIk2Eo+y0/JVGsDWy5iUFgHWTZ5 cAywzmA9Y6D+jYSUQ5XXCfT81Ve1b64LPup9/Hiv0PSlC9DD36uysxtq7x1u66cSiSMD EmvhtdJSxnfJzoNVkbLQc3ALuk8HFobrSclO50hJk3I0HS8UHdZ9w/SBMfdW0vSyFMhC t8tvdaLaFEmYTAQjRpd3pkaZ+SlihQ36uu43STYTCJJL0gZ+yWPaBN/gjgOZdEcKWE2E JntvNBAjesczCX5UD03FTJqKRvoIhdo6jv7B/kRMxo+6erak9ePEvPlmru29R+mPk/Oc aMpA==
MIME-Version: 1.0
X-Received: by with SMTP id pr2mr65021348oeb.65.1452144080462; Wed, 06 Jan 2016 21:21:20 -0800 (PST)
Received: by with HTTP; Wed, 6 Jan 2016 21:21:20 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Wed, 6 Jan 2016 21:21:20 -0800
Message-ID: <>
From: Costin Manolache <>
To: Benjamin Bangert <>
Content-Type: multipart/alternative; boundary=047d7b417921142b2b0528b7a4a5
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 05:21:23 -0000

On Wed, Jan 6, 2016 at 6:11 PM, Benjamin Bangert <>

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

That shouldn't be a problem - there are many ways you can associate a real
developer account with the public key,
using the private key to sign a statement.

Or you could exchange a JWT with a cookie or token that allows access to
the dev tools, without requiring a separate

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

GCM doesn't require payment for diagnostic or anything else, but there are
providers that charge, and for them
the 'contact info' would be more important and need to be more specific.

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

It is not impossible - once we have the auth defined, it can be used to
access other endpoints - debugging, etc.
But probably their definition will need to be in a separate future draft.