Re: [Webpush] Eric Rescorla's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT)

Eric Rescorla <> Wed, 16 August 2017 12:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6CD1113219A for <>; Wed, 16 Aug 2017 05:56:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b8UNd4E7U2Ba for <>; Wed, 16 Aug 2017 05:56:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B20A11326B8 for <>; Wed, 16 Aug 2017 05:56:14 -0700 (PDT)
Received: by with SMTP id l82so21842120ywc.2 for <>; Wed, 16 Aug 2017 05:56:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XUkSofcTw53DIS6kRFZCLEq/DdfuDLW1L+V0Nqo/+ik=; b=BpdG8R1K/zecLHe8uOp5KTpVLdFSIZvgsfi7+r+CmzzCToqYPlBKagX0trN8gR3aui UIVB0OYYoinbwsFsLxEVXK2e0p9h6jmHSZyKjQmeKqe4RmW65wqcOQLHiK2lnWKVIJPb emfvN5ku+ehyDRXsbnqBlktUWEXOGAYXVwkxC49oqc1o/TNQ9ci3evHP7gC2DcWy6hga SN6QCWk7X8kiMpTUJeEWxmwnSbnqusDC8Tazwt5u95FWSLmnpsUtW3yYFzC0VGwGftZa PtWPQE8uOCa8Sdju95C5fd5AnLJ+TzrxDbgasbVreWF7tKoRj9c6R9ppl0hOggJcJO8K Cm2A==
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=XUkSofcTw53DIS6kRFZCLEq/DdfuDLW1L+V0Nqo/+ik=; b=TywM4RqCbAn+6G8GXMCPsryOKKdWUyDm96P9UNAShVZlzqaNF1KlJU3/mYbdy/NajH /lCxzihEeRBlxF6KXvwbXcXhce46AvvD9cQhQEAPwFCh14HZnXHhb+k568T+VjdnrDr7 52Q7xj4Ar+BHh6sndRTO1s1ImjMJNvSj4+4SAJ/8Y1A3aCyZfzmAEFlq1ynM8xMprK7T dCsBU6974RPJ4KPMqXVbeI7qy5K4TLizMIcFK3O0mhq3RAxshcyfwa6ML+FXgx3z2kUh AhzfMBtkC56PDncWBdt928cGrt/GsHUWvqgh576mk4N/QyFd3uH6OF0pCHQST/gKtGcr Rsgg==
X-Gm-Message-State: AHYfb5hA1QebdeGS3NZTFhA/GB/txY9xrcHn7g/LxHYmy0ppm8ZxWfPy 7YanwTaE3Eu3NlPMcirN/jYwtCmVrx1U
X-Received: by with SMTP id o186mr1299482ywc.222.1502888173879; Wed, 16 Aug 2017 05:56:13 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 16 Aug 2017 05:55:33 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Eric Rescorla <>
Date: Wed, 16 Aug 2017 05:55:33 -0700
Message-ID: <>
To: Martin Thomson <>
Cc: Adam Roach <>, Ben Campbell <>, draft-ietf-webpush-vapid <>, Phil Sorber <>, The IESG <>,, "" <>
Content-Type: multipart/alternative; boundary="001a11493408bde1380556de6b2d"
Archived-At: <>
Subject: Re: [Webpush] Eric Rescorla's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT)
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, 16 Aug 2017 12:56:19 -0000

On Tue, Aug 15, 2017 at 10:09 PM, Martin Thomson <>

> On 16 August 2017 at 12:35, Adam Roach <> wrote:
> > On 8/15/17 9:31 PM, Ben Campbell wrote:
> >>
> >> My knee jerk response is to agree with Ekr. But it’s worth discussing
> how
> >> big of an incompatibility with existing code people are talking about.
> Are
> >> there a lot of deployed services that support vapid? Do people think
> that
> >> existing implementors will choose not to implement/deploy the additional
> >> protection?
> >
> >
> >
> > My inclination is to ask the WG to weigh in on this issue in particular.
> > I've received some pretty confident responses indicating that VAPID has
> no
> > issues with crypto-agility. Given that such is the case, it seems like
> the
> > question of how many deployed implementations we have is pretty
> irrelevant:
> > if we can't change crypto schemes at scale, then we shouldn't publish
> this
> > document anyway.
> No change is free.  We'd first have to establish whether the change is
> a net gain.
> The presumption here seems to be that the presented design is
> unconditionally superior.  That's not true.  This is a trade-off, and
> - in my opinion - not one that favours any change.
> For me the important point here is that the proposed change (in any
> form) is of fairly marginal value.  Yes, the IETF is investing in
> anti-bearer-token-theft technology, but in this case what you get is
> the ability to send a message to user agent and wake it up.
> You get that after stealing two pieces of information: the push
> subscription URI and this token.  (That's assuming that the first was
> not already sufficient, which it is in some cases.)  You can't send
> arbitrary data, for that you need two more pieces of information: a
> public key and authorization code, and neither of these appear on the
> HTTPS connection from which the other items were stolen.

This is a rather odd argument, as it also applies to the mechanism in this
document as a whole.

So that's benefits.  Let's talk about costs.
> If we take the suggested design the biggest challenge is key
> management for K_p (the key that the push service would have to
> maintain).  Maintaining a set of keys across a globally-distributed
> service isn't free.  Given that key compromise would undermine the
> effort we'd be putting in here, you also need a strategy for updating
> those keys and revocation of old or compromised keys.  For that you
> want multiple keys, which means key identifiers in messages.  You also
> need some way of having application servers update their view of what
> keys are current, maybe using expiration times.

You raise several issues here:

1. The cost of coordinating the key. I agree that this is a real cost to
the mechanism I proposed here, though it's possible to mitigate it in a
number of ways (e.g., by having a centralized oracle for doing the
verification, given that you don't need to do a lot of EC computation

2. The need for revocation. You don't actually need that here, just a key
update mechanism and a way to tell the app server "use this new key". But
this latter mechanism is the same one you use for key updates and for
updates to the mechanism, which this document implies the WG thinks is easy.

3. Key identifiers in messages are just specification work, so I don't
think that that's a strong argument (see below).

4. Yes, it's a concern if these keys are compromised, but note that even if
that's so, the security of the system reduces back to a bearer token
(because you need the DH public key and the signed JWT), so that doesn't
seem like much of a cost.

Technically, we also have to work out what to cover with the MAC.  My
> experience with HTTP and signing suggests that this isn't as trivial
> as it might seem.  I think that we could canonicalize the push
> subscription URI, Content-Encoding header field and payload and be
> reasonably sure that the MAC couldn't be transplanted.  Probably also
> the RFC 8030 TTL, Urgency and Topic header fields, which suggests that
> there needs to be a way to sign any new and relevant header fields
> that might be added later.  This would need some more analysis than
> I've given it here.

I agree that there are complexities here, but they're complexities that are
motivated by actually trying to design something with stronger security
properties. More generally, they are costs to the WG, but not really costs
to the world at large.

Finally, I think this discussion has ratholed a bit on this particular
counter-proposal. My point isn't that you should do this particular thing
but rather that it seems like the WG decided on a bearer-token model
without giving sufficient consideration to alternatives that have better
security (of which this is merely one). The fact that I was able to produce
two such alternatives in a few hours (which I'll concede are not in every
way superior) and your response was not "yes, we considered those and here
is a pointer to the WG archives" seems to lend that point some plausibility.

As I said initially, this is ultimately a WG decision and I'm fine with
being told by the ADs and the Chairs that they believe sufficient
consideration has been given, in which case I'll withdraw my discuss. So
far I haven't heard that.


p.s., It's been a while since I've been on the receiving end of the
> old "your code doesn't matter, you took a risk implementing an I-D"
> argument.  As an argument it kinda stinks.  I'm embarrassed to confess
> that I've used it in the past, despite reminding myself not to.

I think I explicitly labelled this argument as flippant, but I also don't
think it's valueless, especially when put up against "Three large companies
implemented and are too lazy to change".