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