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

Tim Chown <> Wed, 02 August 2017 08:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 702ED131CFE for <>; Wed, 2 Aug 2017 01:26:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EZyK0nYJfFHf for <>; Wed, 2 Aug 2017 01:26:31 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 915ED131CF2 for <>; Wed, 2 Aug 2017 01:26:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mimecast20170213; t=1501662390; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=c3AP33KD2SJrr/fUp4uGOJskJmqGepp31IGuOAmpiik=; b=FbW/1SttL7968dtP7MCCgcJo1fkcBb9OIW3eJDHBa9pE+eX9CsUuJj/0Uh5a7Sf00yBHQOEiyBAPRdEM5yXYC82HTcHDO8P7jW6/hOLSq8Npt0G6s689ztHyespfWkysXCJo5kKR1UGaOHbw5AwkhbRk+TSpQ3P8/181y5w4H5Q=
Received: from ( []) (Using TLS) by with ESMTP id uk-mta-88-ZM4WyO3VOaGNjEeBAJVCVA-1; Wed, 02 Aug 2017 09:26:26 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.10; Wed, 2 Aug 2017 08:26:25 +0000
Received: from ([fe80::b8a2:fb24:484f:ba3]) by ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1320.010; Wed, 2 Aug 2017 08:26:24 +0000
From: Tim Chown <>
To: Martin Thomson <>
CC: "" <>, "" <>, "" <>
Thread-Topic: Opsdir last call review of draft-ietf-webpush-encryption-08
Date: Wed, 2 Aug 2017 08:26:24 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-mailer: Apple Mail (2.3273)
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB0695; 20:LkaUluQHnEFM+e7X/S7CxWT2VjiHXuxj0y8wVeAJrSLxEK7IF7lD05WossVrDT86DHC+iGwlaUeeySy9kBNktq2XjAZojGpANjXxa+SG+8aEJwQSkIi7F53+Wh2KUxsVCeyPqHhAGZFClmRrZszXPx7d5I94N27jOREqKN5FS7Y=
x-ms-office365-filtering-correlation-id: 22a5dc22-5518-4dd9-2242-08d4d98029e2
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB0695;
x-ms-traffictypediagnostic: AM3PR07MB0695:
x-exchange-antispam-report-test: UriScan:(274715658323672)(158342451672863)(166708455590820);
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6041248)(20161123562025)(20161123555025)(20161123558100)(20161123560025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB0695; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB0695;
x-forefront-prvs: 0387D64A71
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39410400002)(39840400002)(39450400003)(199003)(51914003)(66654002)(24454002)(189002)(50226002)(38730400002)(33656002)(6306002)(6512007)(66066001)(229853002)(5250100002)(97736004)(99286003)(551934003)(72206003)(54906002)(2950100002)(82746002)(6246003)(57306001)(2900100001)(6916009)(53936002)(42882006)(14454004)(83716003)(25786009)(189998001)(101416001)(6486002)(102836003)(6116002)(4326008)(6506006)(110136004)(81156014)(230783001)(7736002)(305945005)(3280700002)(81166006)(50986999)(966005)(5660300001)(6436002)(74482002)(478600001)(76176999)(105586002)(3660700001)(106356001)(36756003)(2906002)(8676002)(86362001)(53546010)(3846002)(8936002)(68736007)(39060400002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0695;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2017 08:26:24.7028 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0695
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
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 08:26:34 -0000

Hi Martin,

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

Best wishes,

> On 2 Aug 2017, at 01:29, Martin Thomson <> wrote:
> 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
> 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
> :)