[Webpush] Eric Rescorla's No Objection on draft-ietf-webpush-vapid-04: (with COMMENT)

Eric Rescorla <ekr@rtfm.com> Wed, 11 October 2017 16:51 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Eric Rescorla <ekr@rtfm.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-webpush-vapid@ietf.org, Phil Sorber <sorber@apache.org>, webpush-chairs@ietf.org, sorber@apache.org, webpush@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150774068985.24840.6925880744686098654.idtracker@ietfa.amsl.com>
Date: Wed, 11 Oct 2017 09:51:29 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/webpush/xf0op_xOgVMGv05j34sxniUKz7g>
Subject: [Webpush] Eric Rescorla's No Objection on draft-ietf-webpush-vapid-04: (with COMMENT)

Eric Rescorla has entered the following ballot position for
draft-ietf-webpush-vapid-04: No Objection

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/



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

[Webpush] Eric Rescorla's No Objection on draft-i… Eric Rescorla