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

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

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 <sorber@apache.org> 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:
>
> https://mailarchive.ietf.org/arch/msg/webpush/HYW9NcUioQo5X2Np-d2hjCzB1Fo
>
> 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
> Webpush@ietf.org
> https://www.ietf.org/mailman/listinfo/webpush
>
>