Subject: [Webpush] Opsdir last call review of draft-ietf-webpush-encryption-08

From: Tim Chown <[email-masked]>
Date: Tue, 01 Aug 2017 13:36:45 -0700

Reviewer: Tim Chown
Review result: Ready

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 https://w3c.github.io/push-api/, 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”?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 2 Aug 2017 10:29:40 +1000

Hi Tim, thanks for the review.

(-ietf@ to save inboxes)

> would benefit from a terminology section for the specific language used here?

The terminology is inherited.  I've added a pointer.

> [WEBPUSH-ENCRYPTION]. Is the W3C spec for the Push API fully consistent with

The editors of that spec (disclaimer: I am one) have been following
this closely.  I'm fairly confident that this isn't badly skewed.

> perhaps point there, and clarify any additional considerations specific to this

This document really leans heavily on RFC 8030, so I'd prefer to keep
this lean and leave the deeper considerations there.

As for cost of calculation, the computations are done by the initiator
of the transaction (the Application Server), for whom I can say we
aren't concerned about computation cost: the higher the cost, the
fewer messages they send, which might be consider a DoS mitigation
bonus.

The other party is the User agent, for whom the Push Service acts as a
shield - that is basically its primary purpose.  User Agents shouldn't
be getting any more push messages than they can handle, with or
without crypto.  In any case, when it comes to receiving push
messages, the fact that the radio is being turned on completely dwarfs
the energy cost of a few simple cryptographic computations.

> mechanisms in Section 7.1 of RFC8030 are employed? I assume not, but think it’s

Always worth asking, but I don't believe that there are any concerns.
This spec doesn't touch the Push Service at all.

> And one nit:

Good catch, you are the second person to notice both, I fixed these in
https://github.com/webpush-wg/webpush-encryption/pull/16 :)

---

From: Tim Chown <[email-masked]>
Date: Wed, 2 Aug 2017 08:26:24 +0000

Hi Martin,

Many thanks for the responses. I’m happy with these.

Best wishes,
Tim 

> On 2 Aug 2017, at 01:29, Martin Thomson <[email-masked]> wrote:
>