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

Martin Thomson <> Wed, 16 August 2017 01:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4329F132424; Tue, 15 Aug 2017 18:56:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 VSOq86ayIyIL; Tue, 15 Aug 2017 18:56:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 211BA126B7E; Tue, 15 Aug 2017 18:56:41 -0700 (PDT)
Received: by with SMTP id o9so8970316iod.1; Tue, 15 Aug 2017 18:56:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZQ5OTTf9UM7geHmu2IqhlbJ78V4kvrLPIAMFzjExPU0=; b=KdGyBjV2U8PNyJaIq/A3iha4LdtY5naqfKw0fsLlF04h7bXW5LmW+1s5F4rKcUU7g1 Q5Uagu02fGMBti7lyZWUBvX8nim6WXmpTz4lD7jvdxHF9mL24sCwaKJ8iNgS011jB+9f i9J6uhHKyMchQnKKUKHFDTU3vgJ8kayhQLqAKqKEN7lu50rcTNC8K8cWK7K/IfXDPXhB v5OXsIMx4PS9Zli2cHKuZKYPVG6w4xC/uopF8L2A+Znk5vQYnJlEVNkUBNKlDpwD0z+N 3S3MKfXmepRrGxqhhZGm9F3PTfr4d71WFnnD6xqPOyYhh0wNLX23c1piP+/KMgcsgkqW uICw==
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=ZQ5OTTf9UM7geHmu2IqhlbJ78V4kvrLPIAMFzjExPU0=; b=mjKTxsXNqw9DrNqZhoxbABbo/LKYtlVsesSMrgCG6AE6yXfYZS/d6kvygyZN2eOfIA WqvMeiQ7i+vEQAV+f4NexNsMaRsT2RM+KwWupjFwSWc3r5iMesT5IsHrAHzxn/G8OvUf M6dwKy7hjuyQTrpODB0oQIQfLWomGGlLe4S8WLgLPUXtH52kudQiEJom95gqF2RXJt6i 30Ds+yO7qPHJBca71buqObsskLr5sJOBMSM+whXhvpNyrIv6Q+K5Nm5QG8+QdJ8zP7a0 y4826GK781bbmdpzUU+una6/m8I//g6KG2Waxa8K7xHnG1QTFSYpwiZhbOsbfVJ1Arcj AZzQ==
X-Gm-Message-State: AHYfb5hOrxUdlKqJW+ka1EmbgROPDL+WJaYer+r0vKwRnqSNyM/k0Dg6 5eLYaw2M6ECl7qNgF/asc/9/MGm6LQ==
X-Received: by with SMTP id u27mr101757iou.107.1502848600386; Tue, 15 Aug 2017 18:56:40 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 15 Aug 2017 18:56:39 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Martin Thomson <>
Date: Wed, 16 Aug 2017 11:56:39 +1000
Message-ID: <>
To: Eric Rescorla <>
Cc: The IESG <>, draft-ietf-webpush-vapid <>, Phil Sorber <>,, "" <>
Content-Type: text/plain; charset="UTF-8"
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 01:56:43 -0000

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

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

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

> S 4.2.
>    When a push subscription has been associated with an application
>    server, the request for push message delivery MUST include proof of
>    possession for the associated private key that was used when creating
>    the push subscription.
> This really isn't a proof of possession, as the Security Considerations
> makes clear.

Reworded in a couple of places to make the weaker claim.

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

See PR.