Last Call Review of draft-ietf-webpush-encryption-08

Request Review of draft-ietf-webpush-encryption
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-08-01
Requested 2017-07-11
Authors Martin Thomson
Draft last updated 2017-08-01
Completed reviews Secdir Last Call review of -08 by Liang Xia (diff)
Opsdir Last Call review of -08 by Tim Chown (diff)
Assignment Reviewer Tim Chown
State Completed
Review review-ietf-webpush-encryption-08-opsdir-lc-chown-2017-08-01
Reviewed rev. 08 (document currently at 09)
Review result Ready
Review completed: 2017-08-01


I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments. 

This document specifies a message encryption scheme for the Web Push protocol described in RFC8030. The scheme provides confidentiality and integrity for Push messages sent from an Application Server to a User Agent.  The encryption scheme has also been adopted by W3C.

Note: I have not followed this work, and am not active in the relevant WGs.

The document is well-written, and clear, but noting point 1 below.

Overall I think the document is Ready, though I have some comments below.

1. I looked at RFC8030, the protocol spec for “Generic Event Delivery Using HTTP Push”, and it includes a useful terminology section. Perhaps this draft would benefit from a terminology section for the specific language used here? 

2. If it is not already planned, I would recommend a review by an independent reviewer who follows both the IETF and W3C work.  The Web Push API is described at, where this draft is cited as [WEBPUSH-ENCRYPTION]. Is the W3C spec for the Push API fully consistent with the spec here?

3. Would the “Security Considerations” section benefit from some DoS text, given the computations required at both ends of the subscription channel?  The privacy considerations text is also rather light compared to that in RFC8030 - perhaps point there, and clarify any additional considerations specific to this draft here?

4. Are there any considerations for this spec is the load distribution mechanisms in Section 7.1 of RFC8030 are employed? I assume not, but think it’s worth asking.

And one nit:

1. In Section 3, “application secret” is used, and only used here. Should this be “authentication secret” instead?

2. Section 3.1 para 4, should that be “Application Server”?