Skip to main content

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

Yes

(Adam Roach)

No Objection

(Deborah Brungard)
(Spencer Dawkins)
(Suresh Krishnan)

Note: This ballot was opened for revision 03 and is now closed.

Warren Kumari
No Objection
Comment (2017-08-15 for -03) Unknown
*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.
Adam Roach Former IESG member
Yes
Yes (for -03) Unknown

                            
Ben Campbell Former IESG member
(was Discuss) Yes
Yes (2017-08-16 for -03) Unknown
Thanks for addressing my DISCUSS and COMMENT points.
Alexey Melnikov Former IESG member
(was Discuss) No Objection
No Objection (2017-08-15 for -03) Unknown
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?
Deborah Brungard Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Eric Rescorla Former IESG member
(was Discuss) No Objection
No Objection (2017-10-11) Unknown
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.
Kathleen Moriarty Former IESG member
No Objection
No Objection (2017-08-15 for -03) Unknown
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?
Mirja Kühlewind Former IESG member
No Objection
No Objection (2017-08-15 for -03) Unknown
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.
Spencer Dawkins Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -03) Unknown