Re: [Webpush] AD Review of draft-ietf-webpush-vapid

Martin Thomson <> Wed, 14 June 2017 07:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74C7B1270B4; Wed, 14 Jun 2017 00:34:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lKyzUlxGO6ta; Wed, 14 Jun 2017 00:34:46 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D8BEF129B45; Wed, 14 Jun 2017 00:34:44 -0700 (PDT)
Received: by with SMTP id v20so85614597lfa.1; Wed, 14 Jun 2017 00:34:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mdp7oqwKCvH4NdQks34qvAWYZMr0m949nRFVOZxZGLI=; b=jHy2AyXa74mpS0mzsOx8OemUWesvGwid9SEC7IMi7mn48H75G5N8od8L5zyB9AC3nF SWKK2rVU2JX3KPiZDSlN5IrjUl6T/J2MxODGzYJ2g/Indw61Fyfm6bZX+G8ZUr7OxP4O PFU4omk7C97JWwXV6gBhMA6yqTaYf0dqYygliwg6b2uKeRJjtTMQNxEAGQoANITRAKF2 r/LPDlERLw/c2IIBBUxbSmnmtb7fBm1BvWDpC8iVmFyAS0HDzdi+6lnRmWXNiWy83QEH tI8bwfwrbyCx3JmC1c5dJ2YgcO9BVmzETnL6y+/UFny4y3tRedIptpV01qAQ3KG6zAAb J9JQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mdp7oqwKCvH4NdQks34qvAWYZMr0m949nRFVOZxZGLI=; b=rA9IezwbMGvcA2v9e1MxoFO/p8EWh3QXUibl1fPLGcaZ11bRHuBXpntrKMG5VweErW VsbCuUJo8N3IuJtJCXdOgexOtvK/8T1oPYr6btY107Q0bQ+goG61Hs8PEKlE570+YOy3 PiHbFFlA1B4u4SFE+uHDIVMfAMQtKSgIkScyCaK/Nij4vOwWsYfcZ8P7Oyn3c+4Z1HMz aTkYgQEE2FG3CSuuUK31SzpNfaN8Dpaa1VMACtV2yahR/5J5zGB0qxm5VWZkAD2wz+gm rFFEVaDzTK5VhZQzNosYE+lRFjLI9zbVxtdoYLsoeD7z21SUYzas3VbpexsGi94jzxsn LBQQ==
X-Gm-Message-State: AKS2vOy88iJPsmQNDX2KI+ChvF5OdgxVjEkecvjHfmJdUPIMWzMrmr95 VT/YM4rX5Ra8tz1uWbicDFXb3Hrjn2LZ
X-Received: by with SMTP id q74mr1236155lfg.50.1497425683009; Wed, 14 Jun 2017 00:34:43 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 14 Jun 2017 00:34:42 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Martin Thomson <>
Date: Wed, 14 Jun 2017 08:34:42 +0100
Message-ID: <>
To: Adam Roach <>
Cc:, "" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Webpush] AD Review of draft-ietf-webpush-vapid
X-Mailman-Version: 2.1.22
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: Wed, 14 Jun 2017 07:34:48 -0000

Hi Adam,

Thanks for looking at this.

On 14 June 2017 at 01:21, Adam Roach <> wrote:
> The first issue I'd like to have clarified regards agility of the crypto
> suite. This document hard-codes the signing algorithm as ES256. I'm familiar
> with the fact that documents will frequently do this kind of hardcoding, and
> then normatively update allowed algorithms in future documents; however, for
> all such cases I'm familiar with, there is a negotiation involved that
> allows for bilateral transition from one algorithm to another. For example,
> RFC7616 was able to include new algorithms because of the challenge/response
> nature of its authentication scheme. Since VAPID specifically does not
> include a challenge, application servers have no way of reasonably knowing
> what the push server might be capable of handling. I think the security
> section really needs a treatment of how this can be handled, since the
> obvious solutions with the current design are less than elegant.

The decision we made here, as with other documents in this series, is
to define a single profile rather than allow flexibility in the
scheme.  The rationale for this being that it is better to have fewer
points of articulation in a protocol and where we already rely on one,
which is the authentication scheme.  We do have the option to change
to (for example) Ed25519 by changing the JWT header and tweaking the
definition of the k= parameter, but I think that the general idea is
that we would define a new authentication scheme in preference to
doing that.

As you say, an application server doesn't really have any way of
determining that the push service supports a given algorithm.  That
means we need to be very careful about how we signal these things.
Using the authentication scheme (in this document, "vapid") as the
extension point means that we can use the existing mechanisms in HTTP
to signal which scheme is supported if it ever comes to the point
where we want to or are forced to deploy a new algorithm.

In this case, that's probably going to depend on the rather ugly 401
(Unauthorized) status code and a WWW-Authenticate header field.  We
also have the option of replicating the supportedContentEncodings
parameter of PushManager in the API
( so that
applications might avoid that round trip.

> The second issue entails application server key rotation, especially when
> used without the Subscription Restriction mechanism described in section 4.
> My reading of the document (and I'll note, as a nit, that this is implied
> but not particularly explicit) is that the public key used to identify a
> server is a TOFU token; and that the only means a server has to detect
> impersonation is verifying that the public key is identical to previous
> uses. What is the system behavior intended to be when an application server
> needs to change its VAPID key gracefully; and what is the behavior intended
> to be when an application server loses its key unexpectedly? For
> subscription restriction purposes, I can see how servers could just change
> the key used for the subscription request; but when this mechanism is being
> used solely for the purposes of continuity of an application server's
> identity, it seems problematic.

This isn't TOFU as much as it is a delegated credential.  The server
designates a sender that can speak for it.  The API ultimately relies
on server authentication.

The model that the current draft assumes is that an application server
that wants to roll keys would need to create new subscriptions.  This
is always possible, though it requires contacting every user agent to
do so.  See

We could change the single key to a list of keys, but it would require
making similar changes to the API.  That would potentially allow
application servers the option of using updated keys more quickly
without creating new subscriptions provided that they do sufficient
preparation (which I suspect is unlikely).  It does change the storage
models on push services, and I'd be a little cautious about doing so
given how widely deployed this is already.

> Finally, I'm curious about whether there was any discussion regarding the
> use of "application/json" rather than using the syntax defined by RFC6839
> (e.g., "application/vapid+json"). My concern is that the use of a
> semantic-free syntactic designation here makes it more complicated to use
> push subscription requests for anything *other* than conveying a VAPID key
> in the future. If the intention is that push subscription bodies generically
> contain a JSON object with potentially myriad keys for a variety of
> unrelated purposes, please spell that out clearly (and I would still
> encourage the use of something less generic than "application/json" even in
> such a case).

There was no discussion on this point.  I'm happy to add a new media
type registration, but I would probably make it a generic push
subscription options type than restrict it to this narrow use.  My
initial thought is "application/webpush-options+json", but there's a
bike shed hidden in there.

I need to catch a plane right now.  I'll write up a proposal for this
(and the nits) as soon as I am able.

> Nits:
> Although "vapid" appears in the protocol elements and section headers, it is
> never put next to its expansion in the document. Please consider changing
> the title to "Voluntary Application Server Identification (VAPID) for Web
> Push".
> The abstract's phrasing of "This can used to reduce the secrecy for push
> subscription URLs..." seems quite awkward. While this is necessarily one
> result of employing the described technique, it could hardly be construed as
> a goal. I suggest rephrasing.
> The JWT shown in the Authorization header field has an expiration date of
> 1453523768, while the JSON that claims to be its expansion shows an
> expiration date of 1453341205. Please make these match: implementors are
> likely to use the examples as part of testing their implementations, and
> this may cause unnecessary confusion. Please also double-check that the
> signature in the example is valid after performing this adjustment.