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

Martin Thomson <martin.thomson@gmail.com> Wed, 02 August 2017 00:29 UTC

MIME-Version: 1.0
In-Reply-To: <150161980513.12098.6547423319804689888@ietfa.amsl.com>
References: <150161980513.12098.6547423319804689888@ietfa.amsl.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 02 Aug 2017 10:29:40 +1000
Message-ID: <CABkgnnWfnitgv-KGhnU5uDLY=hyR4eG5xYKABSjNdi3b2C3=8w@mail.gmail.com>
To: Tim Chown <tim.chown@jisc.ac.uk>
Cc: "ops-dir@ietf.org" <ops-dir@ietf.org>, "webpush@ietf.org" <webpush@ietf.org>, draft-ietf-webpush-encryption.all@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/webpush/afyZmrjbFBNvZFm9MCnOZB-fq2Q>
Subject: Re: [Webpush] Opsdir last call review of draft-ietf-webpush-encryption-08
Precedence: list

Hi Tim, thanks for the review.

(-ietf@ to save inboxes)

On 2 August 2017 at 06:36, Tim Chown <tim.chown@jisc.ac.uk> 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 :)

[Webpush] Opsdir last call review of draft-ietf-w… Tim Chown
Re: [Webpush] Opsdir last call review of draft-ie… Martin Thomson
Re: [Webpush] Opsdir last call review of draft-ie… Tim Chown