Re: [Webpush] Application server authentication new years edition

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8A84D1A6FFC for <>; Wed, 6 Jan 2016 21:43:18 -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 I9YhgHjFbIMs for <>; Wed, 6 Jan 2016 21:43:15 -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 C023F1A6FF8 for <>; Wed, 6 Jan 2016 21:43:15 -0800 (PST)
Received: by with SMTP id wp13so183216283obc.1 for <>; Wed, 06 Jan 2016 21:43:15 -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=DLl16LRDbNwMacmaQAd3zvQcOW2KEdLkp0e6cqCKDqw=; b=Rx3VauhThvb4hOW00rzhEXRRHCcFa0cYI1X2FRas9CAj1UvlK5WWaR0agstIuzYj3c QcV4QmCGaUefWN0U88BGv1L3LO86CiDE+XQIIntJDSEw1Cf4MVKS5zZDSupb3KLces6j zdeXH7nALOfSZ5s53k0y/TD7vN8gYvMbHt0TQ8kV1+verWhDGdno5c/yZa2/XrxaQYEG IWpNvGZVVE7OlWhy5J+P3N63c4BUhBFPfi1wIIXlA6T3xAiIHU3kc15l4N6wzg/r5lyK 0zfwSJa4IXj8+Ja/P9kAZH9ehYk2IuYp2QP8no+Ys/xBqtHAbXVFehMPrTo4j5CIzN84 3DEg==
MIME-Version: 1.0
X-Received: by with SMTP id xb9mr46701384oeb.26.1452145395136; Wed, 06 Jan 2016 21:43:15 -0800 (PST)
Received: by with HTTP; Wed, 6 Jan 2016 21:43:15 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Wed, 6 Jan 2016 21:43:15 -0800
Message-ID: <>
From: Costin Manolache <>
To: Martin Thomson <>
Content-Type: multipart/alternative; boundary=047d7bd768e870858c0528b7f248
Archived-At: <>
Cc: Ben Bangert <>, Costin Manolache <>, "" <>
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:43:18 -0000

On Wed, Jan 6, 2016 at 7:29 PM, Martin Thomson <>

> Mega-multi-response.
> On 7 January 2016 at 05:01, Costin Manolache <> wrote:
> > At the same time you can't force push service providers to accept
> >  unauthenticated/unauthorized sending either. Or require them to
> > provide unlimited (and free) service to everyone regardless of how much
> > they're abusing/hurting users or networks.
> The authorization question is challenging, particularly when it comes
> to abuse of limited resources (user attention, battery power, push
> service capacity).  It would be good to understand what the invariants
> are on each service.
> If Google are unwilling to allow completely unauthenticated requests,
> then I think that we could insist on something voluntary.  I'm
> reluctant to do that because it makes it more difficult for
> application server developers to get a start, but that can be mitigate
> with good tooling, I guess.
> On the other hand, if there are cases where a small number of requests
> can be made without extra authentication, then the proposed option
> would be ideal.  That would allow people to experiment a little before
> having to tool up.

Completely unauthenticated requests would be an extremely hard sell, and
I suspect other push services will be in the same position (at least after

Also I don't think developers would benefit much - generating a signed
JWT token is much simpler than encryption, and it already has plenty of

And it won't benefit them too much to start an app without authentication,
get random rejections or errors - or worse, launch it and than realizing it
doesn't work.
We had a period of 'free quota/contact us if you need more' - it was not

> > How about 2.1 AND 2.3 ? Push servers should support both, clients
> > should use what they can.
> I'd like to avoid that situation because it hurts a lot more all
> around.  We like to save that option for the really tough problems
> (video codecs, for example).

I think the fact TLS client auth doesn't work on some providers is enough
to kill it
at least for this version, I didn't know it's not supported.

That leaves 2.3 only.

> > And it may be the way to allow the choice on app server side - either by
> > having an 'isAuthorizationRequired()' or an error code when attempting to
> > subscribe without a public key.
> Again, that makes it more difficult to use the API, and I'd be very
> reluctant to take that option unless the alternatives are untenable.

I agree - IMHO just passing the sender key for all providers is cleanest
and least
risky option.

> On 7 January 2016 at 06:29, Costin Manolache <> wrote:
> > That leaves 2.3 only ? I think it's ok - it relies on the same thing as
> > 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 ?
> We can certainly use P-256 for that as well; that's what is proposed.
> However, it would need to be a different key pair, since all the
> experts recommend against using the same key for signing and key
> exchange.  (There isn't an actual attack, but the dual use isn't
> provably safe.)

I know it's recommended, but it would be very convenient for device2device
 to be able to use the public key generated by subscribe.

In any case, the UA will need to provide some special API to send() or just
an API to
sign or generate JWT token - it could generate a second key for

> On 7 January 2016 at 12:43, Costin Manolache <> wrote:
> > 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.
> I very much agree with this sentiment.  That contact information can
> be verified, though I think that we should probably start out by
> relying on manual processes for that.  We can layer other mechanisms
> on top.
> I'm not particularly fond of the idea of using something as
> heavyweight as what Ben suggested.  Something much simpler might work,
> but I don't think that we need that.  An absolute requirement to use
> something that that would be a big problem.

Agreed, and while his suggestion would work for checking the contact info,
it will still
not be enough for possible charging providers, or for providers offering
dashboards or
other tools. Better to keep verification and association of the public key
with a
'real' account as out of scope of this draft.


> On 7 January 2016 at 13:11, Benjamin Bangert <> wrote:
> > 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.
> If this is your concern, why not ask the dashboard user to prove that
> they have access to the JWK private key when logging in?  That's
> relatively easy to do.  You don't actually need to know who they are
> in that case.  (Though you could use the dashboard UI to do things
> like email verification, as many sites do.)