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

[Tim Chown <[e-mail]>]

Hi Martin,

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

Best wishes,
Tim 

> On 2 Aug 2017, at 01:29, Martin Thomson <[e-mail]> wrote:
> 
> Hi Tim, thanks for the review.
> 
> (-ietf@ to save inboxes)
> 
> On 2 August 2017 at 06:36, Tim Chown <[e-mail]> wrote:
>> 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?
> 
> The terminology is inherited.  I've added a pointer.
> 
>> 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?
> 
> The editors of that spec (disclaimer: I am one) have been following
> this closely.  I'm fairly confident that this isn't badly skewed.
> 
>> 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?
> 
> 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.
> 
>> 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.
> 
> 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 :)
>