Re: [Webpush] Application server authentication new years edition

Martin Thomson <> Thu, 07 January 2016 03:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9434E1A6FBE for <>; Wed, 6 Jan 2016 19:29:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Rvp-qhdA6WDh for <>; Wed, 6 Jan 2016 19:29:44 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C958B1A6FB9 for <>; Wed, 6 Jan 2016 19:29:43 -0800 (PST)
Received: by with SMTP id ik10so46490829igb.1 for <>; Wed, 06 Jan 2016 19:29:43 -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=ow89xlItmQubNAcLyqTlfGEkiwfABANn3VzfDGnlqOc=; b=eUN3HC3CDt1L4k4h9A/mbQVudOiAUVLpu9V2gNtOQL/VHgabL0Dox6LgY1MB3CShG6 ejd6tUM+nAmwN1tLZz1+arMN73W+hpP6adQnnopsSfuaUmgxVzUWanc41Fj2A3RLTQ3O 86EOvke7qh91p3anN64tFKcv54sK1yiih7ZNdGLlUcZj5pyGO87RzsPalW3qzjR5R3ag hqZRPS+Nqic7J87lwW+b3b2UQSjFnnR2evuvu7O8pMMuvaJNunoUIPLOUdI4PuI8ZOm8 ZusnoNytUicAvkWcQhyVfhdZMxYRU8MwQ47sFhTk847aJfV5IxiGGsSPxKrxeE9RN8Er bW0w==
MIME-Version: 1.0
X-Received: by with SMTP id d6mr13537926igr.94.1452137383204; Wed, 06 Jan 2016 19:29:43 -0800 (PST)
Received: by with HTTP; Wed, 6 Jan 2016 19:29:43 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Thu, 7 Jan 2016 14:29:43 +1100
Message-ID: <>
From: Martin Thomson <>
To: Costin Manolache <>
Content-Type: text/plain; charset=UTF-8
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 03:29:45 -0000


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.

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

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

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

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

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.

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