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

Eric Rescorla <> Wed, 16 August 2017 02:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B9106132459 for <>; Tue, 15 Aug 2017 19:05:03 -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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iEWkbbB5t2p5 for <>; Tue, 15 Aug 2017 19:05:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 263CF132430 for <>; Tue, 15 Aug 2017 19:05:01 -0700 (PDT)
Received: by with SMTP id l82so14825991ywc.2 for <>; Tue, 15 Aug 2017 19:05:01 -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=6tHxuva10CGAnjeesxz7Fewi9edwaem8WKACJUi/HCE=; b=l9Yr2riK9H8prq6gjgkO1p2zp1opoZajrEf+mbSXJcHOtoe9Z37aZ7dM/PAk/KWMSv 2OpejXdLbXEGJI+Wpkw/OGDnMaoOr7zwKxfCIVP0SlSgV5OjsZCutfwDu91I3DL223ri SnpY81MCgh8XZeLHxOuXE71hJS0vzMpFRSmgRc+f1QtzciLBHzSNLVwf3Twna/Lpelrp Y/WkkIfjdgys486Th87TpCMa/qGrPnGEb4lK0CNl9LC7koyHZh5d7bGRiFhoHFXGPki+ 92Olf+Om4JZlmO7BW7VmEJQH5hemzR+UsHlLnTkWup7KmIYo5IrnL2UE/JjulTA9LtU4 QgNw==
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=6tHxuva10CGAnjeesxz7Fewi9edwaem8WKACJUi/HCE=; b=f/Asz7cIdnuyBODynydXSjOXE9lUbFaE8jbG4c5wdVKsrlV8iug7EPzjgBfFu/Mc8F yN3PVkNaqMvT26WS90IrwiIiqS9dbBpozHAyEMdvftp7a+NF0f0gD4BbohynkAsuCzaC Q/8P1y83MridMb1/dMoUbb6Fmxju9rcVDK2MdEEl+R/h/0Fs78Qu58Bns7rukwX/teRR dfEyNkU7ONidgTdOr59KkQ5rEjWEqNFpqIZsdStelP6pTBcYUjdgRFtr//L0SLnQag5Z gLOZttz2CRDeJsh2HlM+dtlrC5qAqZ7JRK76WQZZP2dAFB9YsV9vGOtwtlIHs5NzcF90 15vw==
X-Gm-Message-State: AHYfb5i/YLzKvyjc2Co1g8XVSmCtxRGEeumM6xkDcSdGiKjFPckOgbw3 Sh5Xblj7FLWu4jaDjD9ux/Q1nHoQrEfV
X-Received: by with SMTP id s10mr130464ybe.204.1502849100262; Tue, 15 Aug 2017 19:05:00 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 15 Aug 2017 19:04:19 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Eric Rescorla <>
Date: Tue, 15 Aug 2017 19:04:19 -0700
Message-ID: <>
To: Martin Thomson <>
Cc: The IESG <>, draft-ietf-webpush-vapid <>, Phil Sorber <>,, "" <>
Content-Type: multipart/alternative; boundary="f4030435c9f0c5f1d10556d55275"
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 02:05:04 -0000

On Tue, Aug 15, 2017 at 6:56 PM, Martin Thomson <>

> On 16 August 2017 at 09:42, Eric Rescorla <> wrote:
> > Ultimately, this is a WG decision, but given that there are designs
> > with much better security properties, I'd like to know that the WG
> > considered and rejected this kind of design alternative before
> > we advance the weaker design.
> We discussed the implications of the bearer token design and concluded
> that this was acceptable.

That's a much easier discussion to have without an alternative.

> We didn't discuss additionally signing
> messages in this way.  Another alternative is to describe how token
> binding could be used to prevent token theft.
> One complaint I get about webpush is the amount of overhead crypto
> adds to sending messages.  Mostly from a complexity standpoint.  It's
> a real implementation barrier.  We've forced people to jump through a
> lot of hoops and that has made them pretty annoyed.  Deploying this as
> a required extension could be additionally annoying, not to mention
> incompatible with the existing deployed code.

The flippant thing to say would be that I-Ds come with a big disclaimer
for exactly this reason. More seriously, the future is bigger than the past
and given that (as you observe) the vapid token is used to identify
what you support, it seems like deploying the new thing would be

I'm not terribly sympathetic to the complexity point: this is a very modest
amount of crypto.

> What is nice about the specific design you describe (and my flippant
> tokbind suggestion as well coincidentally) is that it can be
> incrementally added to this scheme without a complete overhaul,
> probably without even changing the scheme name, suggestions below
> notwithstanding.
> It could be an optional increment, if we could decide that the push
> service doesn't require this additional protection and it was
> primarily for the benefit of application servers.  Yes, there are
> benefits that accrue to push services and user agents alike, but we
> might decide that they don't gain any certainty about these benefits.
> That suggests a second, though less satisfying, path: a new draft
> describing the enhancement.

I agree that that's possible, but it's kind of unsatisfying to be publishing
a draft with this kind of known deficiency.

Maybe the chairs or ART ADs would like to weigh in here?

I did have a stab at fixing your nits here:
> > S 1.
> >    Additionally, this design also relies on endpoint secrecy as any
> >    application server in possession of the endpoint is able to send
> >    messages, albeit without payloads.  In situations where usage of a
> >    subscription can be limited to a single application server, the
> >    ability to associate a subscription with the application server could
> >    reduce the impact of a data leak.
> >
> > I don't understand this text.
> I realize that this is not at all clear.  How about:
> Additionally, the design of RFC 8030 relies considerably on the secrecy of
> push
> subscription URIs.  Any application server in possession of this URI is
> able to
> send messages to the user agent.  If use of a subscription could be
> limited to
> a single application server, this would reduce the impact of the push
> subscription URI being learned by an unauthorized party.
> > S 2.
> >    This JWT is included in an Authorization header field, using an auth-
> >    scheme of "vapid".  A push service MAY reject a request with a 403
> >    (Forbidden) status code [RFC7235] if the JWT signature or its claims
> >    are invalid.
> >
> > Given that "vapid" is tied to "P-256" it seems like it would be better
> > to rename this "vapid-p256"
> That's just a cosmetic change.  If we change the scheme in an
> incompatible way based on the comment above, then a name change might
> come with that, but your design might be able to use the same name.

I agree that it is largely a cosmetic change, which is why it's in the
COMMENT section.
With that said, I don't think it's purely a cosmetic change: given that we
know that
there is diversity along this dimension, why are we baking one identifier
into the

> S 5.
> > You should call out that the email address is just a bare assertion.
> See PR.