Voluntary Application Server Identification (VAPID) for Web Push
draft-ietf-webpush-vapid-04

[Ballot comment]
UPDATED: I still think this is the wrong design but I'm persuaded that it's
not worth sending it back to the WG.

Abstract
  This identification information can be used to restrict the use of a
  push subscription a single application server.

to a single


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.


S 1.2
  The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this
  document.  It’s not shouting, when they are capitalized, they have
  the special meaning described in [RFC2119].

This seems over-cute. We now have a document that describes this
convention.


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"


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.


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

[Ballot discuss]
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.

[Ballot comment]
Substantive:

I agree with Ekr's DISCUSS.

-3:
"This authentication scheme is intended for use by an application server
when using the Web Push protocol [RFC8030], but it could be used in
other contexts if applicable."

This guidance seems risky without some description of the properties a
given context should have for vapid to be appropriate to use. Please
consider elaborating, or removing the clause after the comma.

"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?

-4.1: "A push service MUST ignore the body of a request that uses a
different media type."

This seems to give VAPID a monopoly on adding
bodies. It precludes adding other media types in future webpush
extensions. Is that the intent?

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

- 8.2:  [I-D.ietf-webpush-encryption] should be normative, since it is
referenced in a MUST level normative requirement in section 3.2. (If
that reference is not intended to be normative, then please rephrase the
referring sentence.)

Editorial:

- Abstract: Please mention the name of the mechanism in the abstract. It
might also be helpful to mention that there are cryptographic signatures
involved. (Same for section 1).

In general, the numerous mentions of "this design" tend to be ambiguous
about whether we talk of the design in this document rather than that of
webpush in general. Once could substitue "VAPID" for many instances.

- 1.0: "Additionally, this design also ..." "Additionally" and "also"
are redundant

- 1.2: Please use the boilerplate from RFC 8174.

- 4.1: "The user agent includes the public key of the application server when
requesting the creation of a push subscription."

I assume this means "A user agent that wishes to create a restricted
subscription...". I know the heading says "Creating a restricted
subscription", but in general the body text make sense even without the
heading.

"The public key is then added to the request to create a push
subscription.  The push subscription request is extended to include a
body.  The body of the request is a JSON object as described in
[RFC7159].  A "vapid" member is added to this JSON object, containing
the public key on the P-256 curve, encoded in the uncompressed form
[X9.62] and base64url encoded [RFC7515].  The media type of the body is
set to "application/webpush-options+json" (see Section 6.3 for
registration of this media type)."

The actor(s) are obscured by the heavy use of passive voice.

- 6.3: Don't we usually list the IESG as the change controller?

[Ballot discuss]
This design seems to have the unfortunate security property that the
JWT is really just a bearer token. The only reason it has to involve
public key cryptography at all is to allow the push cient to refer to
the public key when it makes a subscription. However, as the
Security Considerations acknowledge, this allows a cut-and-paste attack
(more than just replay) by an attacker who acquires any JWT,
because it does not include the message itself.

The primary motivation for this appears to be to minimize CPU cost
on the push service. However, there are designs which do this
without allowing replay. For instance:

- Have the push service have a static public key K_svc which
  is published to application servers (e.g., via well-known).
- In order to form the JWT, have the application server generate
  a fresh DH key K_app, which is embedded in the JWT.
- The message which the app server sends to the push service
  is then MACed with the DH shared secret Z.

This removes the cut-and-paste attack (though of course replay
attacks are still possible) unless the push service keeps a replay
cache. The replay service can trivially amortize the DH computation
(it has to amortize the signature verification in any case to
get any computational benefit) but it's soft state, so it can
just forget it at any time.

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.

[Ballot comment]
Abstract
  This identification information can be used to restrict the use of a
  push subscription a single application server.

to a single


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.


S 1.2
  The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this
  document.  It’s not shouting, when they are capitalized, they have
  the special meaning described in [RFC2119].

This seems over-cute. We now have a document that describes this
convention.


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"


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.


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

[Ballot comment]
Thanks for your work on this draft.

In section 3, it seems that you are just signing the JWK and that seems fine from the text and the purpose listed - origin server authentication.

Then in section 3.2, there's a reference to I-D.ietf-webpush-encryption saying, "An application server MUST select a different
  private key for the key exchange".  This makes me think that encryption is used as well, but I think it would be helpful to see the point made more clear here or in the security considerations section.  Is confidentiality provided/required or just integrity for this draft?

[Ballot comment]
*Very* minor nits:

1: I'm reviewing both this document and draft-ietf-webpush-encryption (both of which have Martin Thomson as an author) -- these use different capitalizations for many terms, for example "user agent" vs "User Agent" -- this document references RFC8030, which has  these lower-case, and so I suspect that it is draft-ietf-webpush-encryption which should change, but I figured I'm mention it here as well.

2: Section 7. Acknowledgements
"This document would have been much worse than it currently is if not for the contributions ..."
Once published as an RFC, it is cast in stone. I support your the above, but think you should remove "currently", so perhaps:
"This document would have been much worse if not for the contributions ..."

Again, these are tiny nits, I don't have enough knowledge of the topic to make more useful comments :-P

Edited: Sorry, managed to click submit before thanking Stefan Winter for his OpsDir review, and the authors for addressing them.

[Ballot comment]
*Very* minor nits:

1: I'm reviewing both this document and draft-ietf-webpush-encryption (both of which have Martin Thomson as an author) -- these use different capitalizations for many terms, for example "user agent" vs "User Agent" -- this document references RFC8030, which has  these lower-case, and so I suspect that it is draft-ietf-webpush-encryption which should change, but I figured I'm mention it here as well.

2: Section 7. Acknowledgements
"This document would have been much worse than it currently is if not for the contributions ..."
Once published as an RFC, it is cast in stone. I support your the above, but think you should remove "currently", so perhaps:
"This document would have been much worse if not for the contributions ..."

Again, these are tiny nits, I don't have enough knowledge of the topic to make more useful comments :-P

[Ballot comment]
I have cleared my DISCUSS based on changes in git.

I am looking forward to continuing discussion about advertising support for the "vapid" authentication scheme in WWW-Authenticate:

In Section 3, 3rd para:

  This authentication scheme does not require a challenge.  Clients are
  able to generate the Authorization header field without any
  additional information from a server.  Therefore, a challenge for
  this authentication scheme MUST NOT be sent in a WWW-Authenticate
  header field.

Does this mean that there is no way to discover whether a particular server supports "vapid" HTTP authentication scheme?

[Ballot comment]
Wondering if the new registry in section 6.2 is really needed. Is it expected that new parameters show up any time soon? For me this doc reads like that's the only two parameter you actually need.

[Ballot discuss]
The following is a nit, but I think it is important that it gets fixed:

In Section 4.1:

  The example in Figure 3 shows a restriction to the key used in
  Figure 1.  Extra whitespace is added to meet formatting constraints.

  POST /subscribe/ HTTP/1.1
  Host: push.example.net
  Content-Type: application/webpush-optjons+json;charset=utf-8

Firstly, "optjons" above should be "options". Secondly, the MIME type registration of application/webpush-options+json says that the MIME type has no parameters, yet you use charset above. So which is it?

  Content-Length: 104

  { "vapid": "BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxH
              F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs" }

[Ballot comment]
In Section 3, 3rd para:

  This authentication scheme does not require a challenge.  Clients are
  able to generate the Authorization header field without any
  additional information from a server.  Therefore, a challenge for
  this authentication scheme MUST NOT be sent in a WWW-Authenticate
  header field.

Does this mean that there is no way to discover whether a particular server supports "vapid" HTTP authentication scheme?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-webpush-vapid-03.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the HTTP Authentication Schemes registry on the HTTP Authentication Scheme Registry Page located at:

https://www.iana.org/assignments/http-authschemes/

a single, new entry in the registry will be made as follows:

Authentication Scheme Name: vapid
Reference: [ RFC-to-be ]
Notes: This scheme is origin-server only and does not define a challenge.

Second, a new registry is to be created called the Vapid Authentication Scheme Parameters registry. The new registry will be located on the Web Push Parameters registry page located at:

https://www.iana.org/assignments/webpush-parameters/

The new registry will be maintained via Specification Required as defined by RFC 5226. There are initial registrations in the new registry as follows:

+---------------+-------------------------+-------------------------+
| Parameter | Purpose | Specification |
| Name | | |
+---------------+-------------------------+-------------------------+
| t | JWT authentication | [[RFC-to-be]], Section |
| | token | 3.1 |
| | | |
| k | signing key | [[RFC-to-be]], Section |
| | | 3.2 |
+---------------+-------------------------+-------------------------+

Third, in the application section of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a new media type will be registered as follows:

Name: webpush-options+json
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: adam@nostrum.com, draft-ietf-webpush-vapid@ietf.org, Phil Sorber , sorber@apache.org, webpush-chairs@ietf.org, webpush@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Voluntary Application Server Identification (VAPID) for Web Push) to Proposed Standard


The IESG has received a request from the Web-Based Push Notifications WG
(webpush) to consider the following document: - 'Voluntary Application Server
Identification (VAPID) for Web Push'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-07-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  An application server can use the method described to voluntarily
  identify itself to a push service.  This identification information
  can be used by the push service to attribute requests that are made
  by the same application server to a single entity.  An application
  server can include additional information that the operator of a push
  service can use to contact the operator of the application server.
  This identification information can be used to restrict the use of a
  push subscription a single application server.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-webpush-vapid/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-webpush-vapid/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard.

Yes.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

An application server can voluntarily identify itself to a push
service using the described technique.  This identification
information can be used by the push service to attribute requests
that are made by the same application server to a single entity.
This can be used to reduce the secrecy for push subscription URLs by
being able to restrict subscriptions to a specific application
server.  An application server is further able to include additional
information that the operator of a push service can use to contact
the operator of the application server.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

During my tenure as co-chair and reading back through the mailing
list archives, I did not see anything of note.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

JR Conlin from Mozilla has said that he has an implementation in
a library.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

The Document Shepherd is Phil Sorber and the Responsible Area Director
is Adam Roach.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I've reviewed it and sent a small PR to the authors. They updated the
ID and now it looks good to me.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No, this document is fairly short and simple.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

Lots of silence, with a few individuals concurring.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

"  == The document seems to lack the recommended RFC 2119 boilerplate, even if
    it appears to use RFC 2119 keywords.

    (The document does seem to have the reference to RFC 2119 which the
    ID-Checklist requires)."

It does have the biolerplate, it's just more cleverly worded.

Downrefs listed below (15)

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

None required.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

Yes.

  -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186'

and

  ** Downref: Normative reference to an Informational RFC: RFC 2818

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

All the extensions defined in the draft are listed and specified in
IANA consideration sections.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

This document creates a "Vapid Authentication Scheme Parameters"
registry for parameters to the "vapid" authentication scheme.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Ran nits check. XML is generated from markdown.