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

Costin Manolache <> Thu, 15 June 2017 07:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A7C541294EE; Thu, 15 Jun 2017 00:07:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 csLWMJOmLA_U; Thu, 15 Jun 2017 00:07:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 252FC126CF6; Thu, 15 Jun 2017 00:07:03 -0700 (PDT)
Received: by with SMTP id c10so8402760qtd.1; Thu, 15 Jun 2017 00:07:03 -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=rmjqgj9D6voWYcMsmaL4VhkicMvDlsRMiofl0RUd70U=; b=XeLJhx+lsUnowrgZ9dQGTCvQXfsh8GV7DzWCcIHn7lckW8LwLUpoqOiIk8n7VtY68C ECtA9cpfGSN/bmC7el0ghgqDMATRpjIUQTpG4mugahTxyiq341kL7Zto7Xf4dA4yojsz SnThbnX0gzZVKnm0rI8KzA08RPuYSkQl7fhhn0RtwqGjV0GoWzx4oB4AZaQGF6deqJBO LdoZ9U7imZKzyjCvLjNuspNZ23xE2pkBhzxjNHmM3ZMaEf46+0/+FGw6intttsxUYfsV jxWgGgqno8S80opyEhMu3CXACW8X2dw1DrPx+eCo7RMIQpaxc9qdg7eZZfx5cR7w37+5 HHXQ==
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=rmjqgj9D6voWYcMsmaL4VhkicMvDlsRMiofl0RUd70U=; b=cf+RZZsEc7QxzGBkH+J7SEHjcYBGUWSlZ86LHvmXh7U8gE8XLXx1scROiHRJKNTEvC BZn0BgNXsPQ+nR0slkcgOEfQhhyqJ0UZCzCE/ojZIbmcxvIkBrE2ybSWUi8PtL+BiIGr uSPFaoAR0QEUuXph2tMT4H4+zXyBWV6Lzvs4/wab6R7+1b+FJD93ndXKHJ891bB3tuc3 wC0ODyoeW+d//2LgRryB2tbfW+YCBp2JusLyPk0blusu+DtAu/KnHdj7i9EN0dcxAeb8 iWOOcIIvylroFTg4zW61z518qowiUDgQTiTfi0Oj1rdy6uy68LDh5Xcd0cYg05wtDNys hoXg==
X-Gm-Message-State: AKS2vOwQLXC4V55qKZLebmuloobZBa1d/sSiksqHxiKol2TY0qAbeGoI 42Y9hM+z+or4/Q8cqJ5RhhFklyKWRQBK
X-Received: by with SMTP id p31mr4546732qtb.64.1497510422242; Thu, 15 Jun 2017 00:07:02 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 15 Jun 2017 00:07:01 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Costin Manolache <>
Date: Thu, 15 Jun 2017 00:07:01 -0700
Message-ID: <>
To: Adam Roach <>
Cc:, "" <>
Content-Type: multipart/alternative; boundary="001a11434010c3e97f0551fa5049"
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: Thu, 15 Jun 2017 07:07:06 -0000

On Tue, Jun 13, 2017 at 5:21 PM, Adam Roach <> wrote:

> VAPID authors --
> This is my AD review for draft-ietf-webpush-vapid-02.
> I think the document may be ready for IETF last call, but I'd like some
> clarifications before sending it out.
> 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.

I think the 'negotiation' must happen much earlier - at subscribe time (and
in general case - out of band). At the time of auth, when VAPID
is used, the caller must have an endpoint that is bound to the server
public key.

If a EC256 public key is used at the time of endpoint creation - it
determines the signing algorithm as well.

So the 'challenge' happens long in advance.

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

The endpoints are supposed to expire after some time, and need to be
periodically rotated. That would be the best point to do graceful rotation,
the endpoints are refreshed.

If a server loses the key - at least in the case of webpush it is possible
to update the web application with the new key and recover.
If the key is stolen: the endpoint secrecy may provide some protection
while the web app is updated. If both private key and
endpoint database are stolen - I think right now the only option is to
contact the provider and have it blacklisted, or to
update the application to stop accepting messages from that key.

It may be good to add more mechanisms to simplify this - but probably
better in separate documents.

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

I think the intent was to allow other attributes in the json, besides the
vapid key, including vendor-specific attributes. The vapid just
defines the 'vapid' key in the subscription json.


> 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.
> Thanks!
> /a
> _______________________________________________
> Webpush mailing list