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

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-webpush-vapid-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-webpush-vapid/



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


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