Re: [Webpush] CALL FOR CONSENSUS: VAPID cut-and-paste protection

JR Conlin <> Fri, 18 August 2017 03:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF5D5132409 for <>; Thu, 17 Aug 2017 20:36:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.69
X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IRYIX8UTbtSD for <>; Thu, 17 Aug 2017 20:36:35 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AC92A132717 for <>; Thu, 17 Aug 2017 20:36:34 -0700 (PDT)
Received: by with SMTP id t128so37629382lff.2 for <>; Thu, 17 Aug 2017 20:36:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DN7qD25LY5kQ9gYxSrz3RqpqVP/4UWd09XZsfaQUhmY=; b=MtZ8bWsuZeb0t1fn/TFRxvzogFKwyC7RvRnYqN9HQlk7TgK7KP4+uIzxWhR6YvPVuG azgIKiPFincofqa0N38rxEZMaH1yWcVHKwjsF3mirD5roVc1O17n5drNmHEEQ531c9yg K53eYHa97Hj6nVOj+1F94R34PFcIx0W40aB7M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=DN7qD25LY5kQ9gYxSrz3RqpqVP/4UWd09XZsfaQUhmY=; b=liY927KQfEs+xyPA5GCZ4Bz+fJhfHZtNK8R5uW+dxaGxuSH2eQ4izMgHB5PSSekWT3 QLrQt33YzFSX5cauQidkCiWs3XNtTID5HzHOHusPIJXO/c251QHOWkAFBn1CxdUArF/S W4S6cnq+Ejvsv2G197O/GHkMzhrzvpx+LgjW1+VAuAHgQo4zilRRuN5Xk201M69hQH1W B/EH0COmWl4u847Z7oIwW9TLmz7HHFJYoOJLMhRbMZwgIzeBimt57Zb4teVXxqqhfuj0 MQ3A4z0KcjWijAemjKvjE/EXHB52BM9Hyh+iGjRpAWv5LwiTDQ1pigXsX15fbOZRlNWO cHWQ==
X-Gm-Message-State: AHYfb5h+q1F1I24N9LeBDDHHqY8077BlC8kgBrSEVvmds9xEyGZD7ru+ Pw4wu1rZynAfEg0auQ5hQw12LphPGMBT
X-Received: by with SMTP id f33mr2856824lfi.133.1503027392519; Thu, 17 Aug 2017 20:36:32 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 17 Aug 2017 20:36:31 -0700 (PDT)
In-Reply-To: <>
References: <>
From: JR Conlin <>
Date: Thu, 17 Aug 2017 20:36:31 -0700
Message-ID: <>
To: Phil Sorber <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="001a113f9146d1c5620556fed545"
Archived-At: <>
Subject: Re: [Webpush] CALL FOR CONSENSUS: VAPID cut-and-paste protection
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: Fri, 18 Aug 2017 03:36:39 -0000

Per Phil's request, I am reposting my statement about how VAPID is used by
our Push Service.

If I may lend a bit of prospective from the point of view of the Push
Service provider.

We enjoy VAPID because it provides us a way to associate contact
information with the data we receive. It's (in theory) voluntary, and we
can prefer feeds that provide the data. VAPID provides us a reasonably low
cost means to "validate" the information we get *if* the requested URI was
secured using the same key, as well as prove that there has been no casual
MITM alterations of data. As Martin notes, the bar is set fairly high for
an attacker sending malicious data to the remote customer.

>From our point of view, VAPID isn't really a security device, it's a
contact device. It's equivalent to someone stapling their business card to
their letter, and is most useful for our ops folk when things go awry.
That's why we accept feeds that use VAPID even if the requested URI was not
secured. In addition, our most pressing concern is with sites that perform
non-hostile abuse. (e.g. we currently get near 2:1 traffic from sites
sending to URIs that are no longer active, and do not provide good ways to
contact their operations.)

That said, we still encourage frankly horrible security practices around
VAPID just so that the barrier to use is as low as possible. We find the
data to still be that useful. For example, we encourage application servers
to cache the VAPID header for as long as possible to reduce the publication

Naturally, we look forward to the guidance provided by the working group
and will adopt their suggestions, but I did want to offer what the more
hands-on usage of the spec has been so far.


On Thu, Aug 17, 2017 at 7:58 PM, Phil Sorber <> wrote:

> This is a call for consensus for an issue relating to
> draft-ietf-webpush-vapid, which is currently in IESG evaluation. Interested
> participants should respond no later than Friday, September 1st 2017.
> During its initial review, one of the Security Area Directors expressed
> concerns regarding the cryptographic properties of the JWT:
> Specifically: as implemented, the JWT is merely a bearer token. While the
> DISCUSS provides a thumbnail sketch of how this could be mitigated, the
> crux of the issue isn’t the specifics of the implementation, but whether
> the WG had considered other, more cryptographically secure approaches.
> Although participants are free to respond in any way they choose, the most
> useful input would be of one of the following three forms:
>    1.
>    I believe the working group has already discussed adding such a
>    mechanism and rejected it (with citation to an email discussion or minutes
>    reflecting such discussion).
>    2.
>    I do not think the working group has discussed the issue before,
>    however I am opposed to changing the mechanism prior to publication
>    because...
>    3.
>    I do not think the working group has discussed the issue before, and
>    would support bringing the document back to the working group for the
>    purpose of mitigating copy-and-paste attacks.
> Thank you.
> _______________________________________________
> Webpush mailing list