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

From: Phil Sorber <[email-masked]>
Date: Fri, 18 Aug 2017 02:58:55 +0000

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.

---

From: JR Conlin <[email-masked]>
Date: Thu, 17 Aug 2017 20:36:31 -0700

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 <[email-masked]> wrote:

>    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.
>
> _______________________________________________
> Webpush mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webpush
>
>

---

From: Costin Manolache <[email-masked]>
Date: Thu, 17 Aug 2017 21:15:21 -0700

(1)  we did discuss using mutual TLS for webpush, as one of the early
proposals, which would mitigate this
issue.  However it was felt that support for mutual TLS would be tricky in
various environments, limiting the adoption
both client and server side.  With the work going on SPIFFE and other
projects (gRPC, k8s) -  this may change and
 IMHO a future revision of webpush could add it.

On VAPID - since it is based on JWT, we have the same limitations as most
other uses of JWT.
I believe Oauth1 was mentioned in some discussions, but more as a thing to
avoid.
Also discussed the fact that bearer JWTs tokens with audience and similar
expiration are widely used
 for protecting more valuable user accounts, and in the case of webpush we
also have the authenticator
 and the (secret) public key.

If VAPID is used for other purposes besides webpush - I believe the format
is extensible enough to
support additional elements to avoid reply.

Costin

---

From: Martin Thomson <[email-masked]>
Date: Fri, 18 Aug 2017 14:16:57 +1000

On 18 August 2017 at 12:58, Phil Sorber <[email-masked]> wrote:
> 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).

We did consider options that don't have this unfortunate property.
Client certificates were a strong contender.  They would have been
ideal if not for operational challenges.

Here's the email that I think was pivotal on this subject:
https://mailarchive.ietf.org/arch/msg/webpush/_qwcGCuDekERw5o31t0MjFJGTh8

Later there is also:
https://mailarchive.ietf.org/arch/msg/webpush/poGnqtBFlFe3hpzvkiS3Rp5L94g

There are yet more emails that follow on from this where we discuss
scope of the token and relative costs.  The first of those is here:
https://mailarchive.ietf.org/arch/msg/webpush/xrqo-LUb7mrPV6eF1xgyJoqMgCU

I found the rest of thread instructive as a reminder of what happened,
I had forgotten the details of this discussion.

I didn't read meeting minutes, the above seems sufficient.