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

Ben Campbell <> Wed, 16 August 2017 15:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF398132626; Wed, 16 Aug 2017 08:52:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 14xWINgYJRzA; Wed, 16 Aug 2017 08:52:48 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CE6AF132195; Wed, 16 Aug 2017 08:52:48 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id v7GFqhQq074042 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 16 Aug 2017 10:52:44 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ben Campbell <>
In-Reply-To: <>
Date: Wed, 16 Aug 2017 10:52:42 -0500
Cc: The IESG <>, draft-ietf-webpush-vapid <>, Phil Sorber <>,, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Martin Thomson <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [Webpush] Ben Campbell'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 15:52:51 -0000

> On Aug 16, 2017, at 1:09 AM, Martin Thomson <> wrote:
> Hi Ben,
> I've collected the changes mentioned below into a PR here:

That mostly looks good, modulo discussion below. I think you dropped the word “meaning” from the 8174 (was 2119) reference. Also, that RFC recommends specific boilerplate. (I’m not going to get wrapped around whether you use that specific boilerplate, as long as the meaning is clear.)
> On 16 August 2017 at 12:21, Ben Campbell <> wrote:
>> In section 2: "A push service MAY reject a request with a 403 (Forbidden) status
>> code [RFC7235] if the JWT signature or its claims are invalid."
>> This seems to leave the possibility of simply ignoring an invalid VAPID token
>> or signature. Assuming we are talking about push servers that support
>> VAPID in the first place, that seems dangerous. Wouldn't it be safer in
>> the general case to treat a request with an invalid VAPID token as at
>> least a bit fishy?
>> I don't mean to say that ignoring the token is never the right thing to
>> do. But the MAY seems week without some guidance on what other actions
>> might be reasonable under what circumstances.
> I think that "MAY" is entirely appropriate given the non-blocking
> nature of the mechanism. A push service might look at the header
> field, but not require the token. Maybe they just wanted to attach an
> email address to a stream of messages (that's what we do).

I think there’s a fundamental difference between not validating in the first place, and ignoring a failed validation. My point is not to say that ignoring it is the wrong thing to do, just that I think some more elaboration here is needed. Would it make sense to say something of the effect of “SHOULD NOT use the information from a token that has failed validation”?


>> "Some implementations permit the same P-256 key to be used for signing
>> and key exchange.  An application server MUST select a different private
>> key for the key exchange [I-D.ietf-webpush-encryption] and signing the
>> authentication token."
>> I don't understand the intent here. It seems to say some implementations
>> do this, but MUST not. Does "implementations" refer to VAPID or
>> something else?
> In NSS and many elliptic curve libraries, you can create an EC key for
> P-256.  You can then use that key for signing AND key exchange.  You
> shouldn't though.

Would it make sense to say “Some library implementations…”?


>> - 4.2: "A push service MUST reject a message that omits mandatory
>> credentials with a 401 (Unauthorized) status code. "
>> This was already stated in section 2. Please avoid repeating normative
>> text, as it creates ambiguity about which text is authoritative, and can
>> complicate future updates.  This section seems the more detailed, so perhaps
>> section 2 could avoid the 2119 text. (But see my DISCUSS point on section 2.)
> This isn't included in Section 2.  Section 2 defines what a valid
> token is.

Oops, that was a cut and paste error. I meant to quote the following sentence: 

" A push service MAY reject a
   message that includes invalid credentials with a 403 (Forbidden)
   status code. "

>  This section defines behaviour in the case that a
> subscription is limited to a particular application server key.  I
> realize now that this might have been unclear, so I have reworded to:
> "A push service MUST reject a message sent to a restricted push subscription if
> that message includes no "vapid" authentication or invalid "vapid"
> authentication.  A 401 (Unauthorized) status code might be used if the
> authentication is absent; a 403 (Forbidden) status code might be used if
> authentication is invalid."
> This also allows me to clear up a minor gripe about the prescriptive
> nature of the text regarding status codes.

I like that paragraph better, but does it conflict with the text in section 2, as discussed in my DISCUSS?


>> - 6.3: Don't we usually list the IESG as the change controller?
> I'm mostly cargo-culting here.  This choice didn't elicit comment when
> I asked for media-type review.
> For reference, the last one of these that went through the IESG came
> back with very specific instructions, and a citation.  I can't find
> that email, or the citation, but I think that it was RFC 6838, Section
> 3.1, which doesn't seem particularly crisp:
>   The "owner" of a media type registered in the standards tree is
>   assumed to be the standards-related organization itself.
> I did find the documents that I remember: RFCs 8142 and 7946 use
> "Internet Engineering Task Force" and "IETF" respectively.  It seems
> like this isn't entirely consistent though.  I will accept the wisdom
> of the IESG on this matter.

I’ll go with Alexey’s separate response. That is, never mind.