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

Martin Thomson <> Wed, 02 August 2017 00:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6806F129AAD; Tue, 1 Aug 2017 17:29:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GpeVTZRGccBO; Tue, 1 Aug 2017 17:29:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF9D81277BB; Tue, 1 Aug 2017 17:29:41 -0700 (PDT)
Received: by with SMTP id m88so14419855iod.2; Tue, 01 Aug 2017 17:29:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=uaUhLbUni5P7dgIjzGfxDC1stFJie4kImLPUHvsm2Qs=; b=UpbsFrYBl3aO3htNONxrwa9d6fCbupyaVMV6OzIfAOuS9CbFVlUeWkZ7o/E/O4njsj NXb5/D68P5XbDEBhjJroeJ5F996A4gejgC/0J+guo/NbGuHnWkUTnn4qAQu05jaXNtLl UWq71KBA6oLHSmTKUuOYWi8thK7geyVRGLys3QRwH8Wu9fCimNqlxJ0lgJHQ6TArCrMX J+ZsLi3orsKoS3rFU2C+6RsnlePZI5PWctXepBKKql0vXCjfbSS77pcyKbOAYBpitj0/ YAgcaVaVvzK66isFxJULKaTMUOSwEp5wkn7LAYoAvPtnlkTYm7OoU2qtkyBWReHtPSBr burw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=uaUhLbUni5P7dgIjzGfxDC1stFJie4kImLPUHvsm2Qs=; b=akTKiQQOFFulHl1IyaKCZt2rosSiCxWjVDNl8anvW/PNTrgYFD9NX6F/Ji7uG3QdDB OP7WfV1vtNaQYdvjkBALo70NjM3luig8PJt1qPzRc15V3638vV4lMYR4mlrG1vw7PaiY O4YMacK4OBhOXuQLyCm1zK5xK9IqGPWzQul1YThyawVqmIWmipJozJCpKFni5HoEgDoO g5TP24jjV8wzsqhvoHk9jB6KNcMT9kxP93A0Vt0jCZZfRKYogkCLISAKdmkZnuS0Xpm8 9YSwNpDJXPWZFIlYTpSUYxAw2tOlmgA5xumJ3S9qiGcKwBs6V1DOByqxamm+/zpIQ9uo HhYQ==
X-Gm-Message-State: AIVw1104KnxJTgqZRrTqdi279KtmYkoohBip3/c/0D4IooQmwog6jtfC 8DoXwcDNsGfwo6rc3nNzgR9/O3fP095cVqs=
X-Received: by with SMTP id z62mr23897687iof.74.1501633781055; Tue, 01 Aug 2017 17:29:41 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 1 Aug 2017 17:29:40 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Martin Thomson <>
Date: Wed, 2 Aug 2017 10:29:40 +1000
Message-ID: <>
To: Tim Chown <>
Cc: "" <>, "" <>,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Webpush] Opsdir last call review of draft-ietf-webpush-encryption-08
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of potential IETF work on a web push protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Aug 2017 00:29:43 -0000

Hi Tim, thanks for the review.

(-ietf@ to save inboxes)

On 2 August 2017 at 06:36, Tim Chown <> 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, 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

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 :)