Re: [Webpush] Application server authentication new years edition

Costin Manolache <> Thu, 07 January 2016 01:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 004A61A3BA6 for <>; Wed, 6 Jan 2016 17:43:11 -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 SpvCJ-QvNHEz for <>; Wed, 6 Jan 2016 17:43:08 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3FA661A6EE9 for <>; Wed, 6 Jan 2016 17:43:08 -0800 (PST)
Received: by with SMTP id ba1so314744579obb.3 for <>; Wed, 06 Jan 2016 17:43:08 -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=sExRTrcTv3Sy+zxDsZWR05+VNF2fjHVM/ZNnal1xM6g=; b=AN/0FkD1mQufh4TjQFihx7ZMLbCGl2Sv5FxhaMzqBihnkCQp7ztSzVnletUNGL6e2+ +Yc0Z+hHzT0vrqfnxETnh/S39WZebNn4zlEMz2FexE0XuTbpEIdfy10Wl4s2S0SX7iE2 PCZDHdqCF9DcsJ36sLpZQYHdhXha/abhFjyNa1z67ARpthffHWdDBMpAGbJ9HEiPU59V RvCuDRrjZSaAOqxnTfUE38jG1RuPKeEqed4i/6mZuN3hjTXn9a4kXrVTygLY0OLdW1WU G3WRXzixELBCxaFP/89RnWjKeUnpVe1rICkShjvkMVcQXOsJAds6+R2ey4FlkFLffWNy luzw==
MIME-Version: 1.0
X-Received: by with SMTP id aq8mr30897632obc.51.1452130987558; Wed, 06 Jan 2016 17:43:07 -0800 (PST)
Received: by with HTTP; Wed, 6 Jan 2016 17:43:07 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Wed, 6 Jan 2016 17:43:07 -0800
Message-ID: <>
From: Costin Manolache <>
To: Benjamin Bangert <>
Content-Type: multipart/alternative; boundary=e89a8ff1ccaaae50fd0528b497de
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 01:43:11 -0000

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

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

> 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 :-)


> Cheers,
> Ben
> On Wed, Jan 6, 2016 at 11:29 AM, Costin Manolache <>
> wrote:
>> Understood - I assume other push services may have similar restrictions,
>> and in general TLS client
>> auth is tricky on both client and server side.
>> That leaves 2.3 only ? I think it's ok - it relies on the same thing as
>> TLS client auth, the sender
>> signing with the private key, and push service checking it against the
>> public key provided at subscribe time.
>> Can we at least make it consistent with the the encryption - i.e. use the
>> same type of key ?
>> In particular it would be nice if an app instance (A) could even use the
>> public key of another instance (B),
>> to allow B to send messages directly to A, without using the app server (
>> for a future version of the
>> standard, of course - but we should keep it in mind ).
>> Costin
>> On Wed, Jan 6, 2016 at 8:33 AM, jr conlin <> wrote:
>>> On 01/06/2016 01:16 AM, Martin Thomson wrote:
>>>> On 6 January 2016 at 15:55, Costin Manolache <> wrote:
>>>>> For authentication:  2.1(certificate) would be my preference, and is a
>>>>> well
>>>>> known and established
>>>>> mechanism, followed by 2.6, 2.3.
>>>> Both 2.1 (certs) and 2.6 (token binding) require access to the TLS
>>>> connection.  Token binding has the added concern that it is a new
>>>> mechanism that might not be well deployed.
>>>> When I inquired, certs did seem possible, but Mozilla folks (JR can
>>>> speak to this better than I), had some operational concerns.  JWT
>>>> hoists the authentication information up into HTTP, which was a lot
>>>> easier to manage.
>>> We are currently deployed on Amazon Web Services (AWS) using Elastic
>>> Load Balancers (ELBs) to terminate TLS connections for both cost and
>>> performance reasons. The ELBs act as a simple proxy, consume the
>>> certificate and provide no certificate information. AWS has no plans to
>>> modify ELB software to relay the cert information as part of the proxied
>>> connection. It is not possible for any AWS based service to use any cert
>>> information to show authentication, since it is impossible to get that
>>> information.
>>> _______________________________________________
>>> Webpush mailing list
>> _______________________________________________
>> Webpush mailing list