Summary: Has a DISCUSS. Needs one more YES or NO OBJECTION position to pass.
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.
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.
Thanks for addressing my DISCUSS and COMMENT points.
*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.
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.
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?
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?