From nobody Tue Aug 1 12:55:29 2017 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CCB132311; Tue, 1 Aug 2017 12:55:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-webpush-vapid@ietf.org, Phil Sorber , webpush-chairs@ietf.org, sorber@apache.org, webpush@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150161732457.12184.5254423236791059887.idtracker@ietfa.amsl.com> Date: Tue, 01 Aug 2017 12:55:24 -0700 Archived-At: Subject: [Webpush] Alexey Melnikov's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 01 Aug 2017 19:55:25 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-webpush-vapid-03: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-webpush-vapid/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The following is a nit, but I think it is important that it gets fixed: In Section 4.1: The example in Figure 3 shows a restriction to the key used in Figure 1. Extra whitespace is added to meet formatting constraints. POST /subscribe/ HTTP/1.1 Host: push.example.net Content-Type: application/webpush-optjons+json;charset=utf-8 Firstly, "optjons" above should be "options". Secondly, the MIME type registration of application/webpush-options+json says that the MIME type has no parameters, yet you use charset above. So which is it? Content-Length: 104 { "vapid": "BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxH F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs" } ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Section 3, 3rd para: This authentication scheme does not require a challenge. Clients are able to generate the Authorization header field without any additional information from a server. Therefore, a challenge for this authentication scheme MUST NOT be sent in a WWW-Authenticate header field. Does this mean that there is no way to discover whether a particular server supports "vapid" HTTP authentication scheme? From nobody Tue Aug 1 13:34:47 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF14D131838 for ; Tue, 1 Aug 2017 13:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1i5fR2IjaHhQ for ; Tue, 1 Aug 2017 13:34:43 -0700 (PDT) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id 9E41C129B40 for ; Tue, 1 Aug 2017 13:34:43 -0700 (PDT) Received: (qmail 82071 invoked by uid 99); 1 Aug 2017 20:34:42 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Aug 2017 20:34:42 +0000 Received: from mail-it0-f51.google.com (mail-it0-f51.google.com [209.85.214.51]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id AA6A81A00A2; Tue, 1 Aug 2017 20:34:42 +0000 (UTC) Received: by mail-it0-f51.google.com with SMTP id h199so13869280ith.0; Tue, 01 Aug 2017 13:34:42 -0700 (PDT) X-Gm-Message-State: AIVw111DFx14mgEBk543IZw+inhTlJzEULjaU2MzSGkWjjhZnmcBQHu+ 6M22NaJer7hrhc31xefmvHkMdfwGsg== X-Received: by 10.36.66.16 with SMTP id i16mr3317392itb.132.1501619681744; Tue, 01 Aug 2017 13:34:41 -0700 (PDT) MIME-Version: 1.0 References: <150161732457.12184.5254423236791059887.idtracker@ietfa.amsl.com> In-Reply-To: <150161732457.12184.5254423236791059887.idtracker@ietfa.amsl.com> From: Phil Sorber Date: Tue, 01 Aug 2017 20:34:31 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Alexey Melnikov , The IESG Cc: draft-ietf-webpush-vapid@ietf.org, webpush-chairs@ietf.org, webpush@ietf.org Content-Type: multipart/alternative; boundary="001a1145ee9eb7df430555b7135b" Archived-At: Subject: Re: [Webpush] Alexey Melnikov's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT) X-BeenThere: webpush@ietf.org 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: Tue, 01 Aug 2017 20:34:46 -0000 --001a1145ee9eb7df430555b7135b Content-Type: text/plain; charset="UTF-8" For sure the first discuss item has already been addressed in the git repo [1], and there is also a statement that the JSON is UTF-8 encoded now as well. I'm not sure that really resolves the second point though. I'll let the authors address that directly. Martin, Peter, perhaps this is a good opportunity to push a new draft before the telechat? [1] https://github.com/webpush-wg/webpush-vapid/compare/draft-ietf-webpush-vapid-03...master On Tue, Aug 1, 2017 at 1:55 PM Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-webpush-vapid-03: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-webpush-vapid/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > The following is a nit, but I think it is important that it gets fixed: > > In Section 4.1: > > The example in Figure 3 shows a restriction to the key used in > Figure 1. Extra whitespace is added to meet formatting constraints. > > POST /subscribe/ HTTP/1.1 > Host: push.example.net > Content-Type: application/webpush-optjons+json;charset=utf-8 > > Firstly, "optjons" above should be "options". Secondly, the MIME type > registration of application/webpush-options+json says that the MIME type > has no > parameters, yet you use charset above. So which is it? > > Content-Length: 104 > > { "vapid": "BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxH > F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs" } > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In Section 3, 3rd para: > > This authentication scheme does not require a challenge. Clients are > able to generate the Authorization header field without any > additional information from a server. Therefore, a challenge for > this authentication scheme MUST NOT be sent in a WWW-Authenticate > header field. > > Does this mean that there is no way to discover whether a particular server > supports "vapid" HTTP authentication scheme? > > > --001a1145ee9eb7df430555b7135b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For sure the first discuss item has already been addr= essed in the git repo [1], and there is also a statement that the JSON is U= TF-8 encoded now as well. I'm not sure that really resolves the second = point though. I'll let the authors address that directly.

Martin, Peter, perhaps this is a good opportunity to push a= new draft before the telechat?


On Tue, Aug 1, 2017 at 1:55 PM Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
Alexey Melnikov has entered the following = ballot position for
draft-ietf-webpush-vapid-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ie= tf-webpush-vapid/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The following is a nit, but I think it is important that it gets fixed:

In Section 4.1:

=C2=A0 =C2=A0The example in Figure 3 shows a restriction to the key used in=
=C2=A0 =C2=A0Figure 1.=C2=A0 Extra whitespace is added to meet formatting c= onstraints.

=C2=A0 =C2=A0POST /subscribe/ HTTP/1.1
=C2=A0 =C2=A0Host: push.example.net
=C2=A0 =C2=A0Content-Type: application/webpush-optjons+json;charset=3Dutf-8=

Firstly, "optjons" above should be "options". Secondly,= the MIME type
registration of application/webpush-options+json says that the MIME type ha= s no
parameters, yet you use charset above. So which is it?

=C2=A0 =C2=A0Content-Length: 104

=C2=A0 =C2=A0{ "vapid": "BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m16= 4i3MrAIxH
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0F6YK5h4SDYic-dRuU_RC= PCfA5aq9ojSwk5Y2EmClBPs" }


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In Section 3, 3rd para:

=C2=A0 =C2=A0This authentication scheme does not require a challenge.=C2=A0= Clients are
=C2=A0 =C2=A0able to generate the Authorization header field without any =C2=A0 =C2=A0additional information from a server.=C2=A0 Therefore, a chall= enge for
=C2=A0 =C2=A0this authentication scheme MUST NOT be sent in a WWW-Authentic= ate
=C2=A0 =C2=A0header field.

Does this mean that there is no way to discover whether a particular server=
supports "vapid" HTTP authentication scheme?


--001a1145ee9eb7df430555b7135b-- From nobody Tue Aug 1 13:37:00 2017 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4FF129B40; Tue, 1 Aug 2017 13:36:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tim Chown To: Cc: webpush@ietf.org, ietf@ietf.org, draft-ietf-webpush-encryption.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150161980513.12098.6547423319804689888@ietfa.amsl.com> Date: Tue, 01 Aug 2017 13:36:45 -0700 Archived-At: Subject: [Webpush] Opsdir last call review of draft-ietf-webpush-encryption-08 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 01 Aug 2017 20:36:45 -0000 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 nobody Tue Aug 1 17:14:20 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7981275FD; Tue, 1 Aug 2017 17:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAHV8S2SfGRS; Tue, 1 Aug 2017 17:14:10 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E9BA129AAD; Tue, 1 Aug 2017 17:14:10 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id v127so16669984itd.0; Tue, 01 Aug 2017 17:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HxjtZcd7tOxnhcP2gGy60pY8zRHCppO1WDfEW+FIkhA=; b=t9DzJPPmpiEJZjnaBJ2ISGQQNw3NaGd6RfdL7H4fjafYPdLyPx+4kzaf99v2RSVMHM MH6d6ZYBExAWHRlVPAS0ci4THIt8C+kMFAdC1J9kcQA4apX5mmupcniuGOGc7oRIceK3 t8MbuiuJfuCNxHIoQh29qQGzWfB0xToAE30NPtwLG+yGmWDRCWRgj/LRlVCOQvXlgwj2 TzO44xLZ9PAHX3EH8AeRYzmea1psSg/pGT861sP/nQFauzsf3/q3ABHvcGmTPmt9UAZN E+1M1mU9xO91HEerpK8ZcrGv3Qir41LXxOiWid5eWOHv5/OKu5c3N72lhgcA0N7VKiX3 KOkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HxjtZcd7tOxnhcP2gGy60pY8zRHCppO1WDfEW+FIkhA=; b=CohWXHS5dzyzKOPXu7KSbE/IHOXuJH0kRY0b8jKemh9sOgBa8aSklWbWi/fV99XtAT uRCE7tgD1M0hmqX8RB5BBf1TIq9yQL6t1uCCemm1wcdgY12gzk0KgNseFmWI0If4g5AX 85DzY37hAZkS+oi3RIyov6URVjiyLSjNOtSmJ56yh/UCQzf0QNjfnGHFAHsBkN78vcsu GVrs7TJXxgflbNnqzGto2rbjvbz/v2SOiq9mjhnAtpjbpneJWSLbZLdMsMcdBzmfHS0v 066FLy0hlnHGM4X2S9IzwlqvnXec2A4asJWKWTIRqgX/kB9L/8bXrUbSv0+1M1UpqGKL zF7Q== X-Gm-Message-State: AIVw110dovwGtBaOht4EJMJ/dt3iUQLbZ2eQJJ+7YD6ETSuITrDHnp14 14CEktrdZXRjQS9xarDd/Qqsr6KrRw== X-Received: by 10.36.152.198 with SMTP id n189mr3270044itd.79.1501632849581; Tue, 01 Aug 2017 17:14:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Tue, 1 Aug 2017 17:14:09 -0700 (PDT) In-Reply-To: <150161732457.12184.5254423236791059887.idtracker@ietfa.amsl.com> References: <150161732457.12184.5254423236791059887.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Wed, 2 Aug 2017 10:14:09 +1000 Message-ID: To: Alexey Melnikov Cc: The IESG , draft-ietf-webpush-vapid , Phil Sorber , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Webpush] Alexey Melnikov's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT) X-BeenThere: webpush@ietf.org 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:14:12 -0000 On 2 August 2017 at 05:55, Alexey Melnikov wrote: > Firstly, "optjons" above should be "options". Secondly, the MIME type > registration of application/webpush-options+json says that the MIME type has no > parameters, yet you use charset above. So which is it? As Phil notes, the first was corrected already, the second is in c867529 on GitHub. I'll push a new version at Adam's instruction. > In Section 3, 3rd para: > > This authentication scheme does not require a challenge. Clients are > able to generate the Authorization header field without any > additional information from a server. Therefore, a challenge for > this authentication scheme MUST NOT be sent in a WWW-Authenticate > header field. > > Does this mean that there is no way to discover whether a particular server > supports "vapid" HTTP authentication scheme? Not directly. There was a plan to expose this via the User Agent, but we didn't reach a conclusion: https://github.com/w3c/push-api/pull/262 Another document could override this as well, I suppose. The "MUST NOT" exists primarily because we don't define a challenge. From nobody Tue Aug 1 17:29:51 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6806F129AAD; Tue, 1 Aug 2017 17:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpeVTZRGccBO; Tue, 1 Aug 2017 17:29:41 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9D81277BB; Tue, 1 Aug 2017 17:29:41 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id m88so14419855iod.2; Tue, 01 Aug 2017 17:29:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.107.201.65 with SMTP id z62mr23897687iof.74.1501633781055; Tue, 01 Aug 2017 17:29:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Tue, 1 Aug 2017 17:29:40 -0700 (PDT) In-Reply-To: <150161980513.12098.6547423319804689888@ietfa.amsl.com> References: <150161980513.12098.6547423319804689888@ietfa.amsl.com> From: Martin Thomson Date: Wed, 2 Aug 2017 10:29:40 +1000 Message-ID: To: Tim Chown Cc: "ops-dir@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: Subject: Re: [Webpush] Opsdir last call review of draft-ietf-webpush-encryption-08 X-BeenThere: webpush@ietf.org 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 =E2=80=9CGeneric Event Deli= very Using > HTTP Push=E2=80=9D, and it includes a useful terminology section. Perhaps= this draft > would benefit from a terminology section for the specific language used h= ere? The terminology is inherited. I've added a pointer. > 2. If it is not already planned, I would recommend a review by an indepen= dent > reviewer who follows both the IETF and W3C work. The Web Push API is des= cribed > 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 w= ith > 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 =E2=80=9CSecurity Considerations=E2=80=9D section benefit fr= om 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 RFC8= 030 - > perhaps point there, and clarify any additional considerations specific t= o 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 thin= k it=E2=80=99s > 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 :) From nobody Wed Aug 2 01:26:36 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702ED131CFE for ; Wed, 2 Aug 2017 01:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZyK0nYJfFHf for ; Wed, 2 Aug 2017 01:26:31 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (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; d=jisc.ac.uk; 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 EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02lp0048.outbound.protection.outlook.com [213.199.154.48]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-88-ZM4WyO3VOaGNjEeBAJVCVA-1; Wed, 02 Aug 2017 09:26:26 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB0695.eurprd07.prod.outlook.com (10.160.6.149) 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 AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([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: "ops-dir@ietf.org" , "webpush@ietf.org" , "draft-ietf-webpush-encryption.all@ietf.org" Thread-Topic: Opsdir last call review of draft-ietf-webpush-encryption-08 Thread-Index: AQHTCyZxp1CkJnSU+UGiTTOPHKYBJqJwu8EA Date: Wed, 2 Aug 2017 08:26:24 +0000 Message-ID: <9823F2F6-9E80-458D-B957-78703F501C57@jisc.ac.uk> References: <150161980513.12098.6547423319804689888@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [194.82.140.195] 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; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <984C646C05AB70469BE1E19849FC3531@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk 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 X-MC-Unique: ZM4WyO3VOaGNjEeBAJVCVA-1 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-BeenThere: webpush@ietf.org 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 SGkgTWFydGluLA0KDQpNYW55IHRoYW5rcyBmb3IgdGhlIHJlc3BvbnNlcy4gSeKAmW0gaGFwcHkg d2l0aCB0aGVzZS4NCg0KQmVzdCB3aXNoZXMsDQpUaW0gDQoNCj4gT24gMiBBdWcgMjAxNywgYXQg MDE6MjksIE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+IHdyb3RlOg0K PiANCj4gSGkgVGltLCB0aGFua3MgZm9yIHRoZSByZXZpZXcuDQo+IA0KPiAoLWlldGZAIHRvIHNh dmUgaW5ib3hlcykNCj4gDQo+IE9uIDIgQXVndXN0IDIwMTcgYXQgMDY6MzYsIFRpbSBDaG93biA8 dGltLmNob3duQGppc2MuYWMudWs+IHdyb3RlOg0KPj4gT3ZlcmFsbCBJIHRoaW5rIHRoZSBkb2N1 bWVudCBpcyBSZWFkeSwgdGhvdWdoIEkgaGF2ZSBzb21lIGNvbW1lbnRzIGJlbG93Lg0KPj4gDQo+ PiAxLiBJIGxvb2tlZCBhdCBSRkM4MDMwLCB0aGUgcHJvdG9jb2wgc3BlYyBmb3Ig4oCcR2VuZXJp YyBFdmVudCBEZWxpdmVyeSBVc2luZw0KPj4gSFRUUCBQdXNo4oCdLCBhbmQgaXQgaW5jbHVkZXMg YSB1c2VmdWwgdGVybWlub2xvZ3kgc2VjdGlvbi4gUGVyaGFwcyB0aGlzIGRyYWZ0DQo+PiB3b3Vs ZCBiZW5lZml0IGZyb20gYSB0ZXJtaW5vbG9neSBzZWN0aW9uIGZvciB0aGUgc3BlY2lmaWMgbGFu Z3VhZ2UgdXNlZCBoZXJlPw0KPiANCj4gVGhlIHRlcm1pbm9sb2d5IGlzIGluaGVyaXRlZC4gIEkn dmUgYWRkZWQgYSBwb2ludGVyLg0KPiANCj4+IDIuIElmIGl0IGlzIG5vdCBhbHJlYWR5IHBsYW5u ZWQsIEkgd291bGQgcmVjb21tZW5kIGEgcmV2aWV3IGJ5IGFuIGluZGVwZW5kZW50DQo+PiByZXZp ZXdlciB3aG8gZm9sbG93cyBib3RoIHRoZSBJRVRGIGFuZCBXM0Mgd29yay4gIFRoZSBXZWIgUHVz aCBBUEkgaXMgZGVzY3JpYmVkDQo+PiBhdCBodHRwczovL3czYy5naXRodWIuaW8vcHVzaC1hcGkv LCB3aGVyZSB0aGlzIGRyYWZ0IGlzIGNpdGVkIGFzDQo+PiBbV0VCUFVTSC1FTkNSWVBUSU9OXS4g SXMgdGhlIFczQyBzcGVjIGZvciB0aGUgUHVzaCBBUEkgZnVsbHkgY29uc2lzdGVudCB3aXRoDQo+ PiB0aGUgc3BlYyBoZXJlPw0KPiANCj4gVGhlIGVkaXRvcnMgb2YgdGhhdCBzcGVjIChkaXNjbGFp bWVyOiBJIGFtIG9uZSkgaGF2ZSBiZWVuIGZvbGxvd2luZw0KPiB0aGlzIGNsb3NlbHkuICBJJ20g ZmFpcmx5IGNvbmZpZGVudCB0aGF0IHRoaXMgaXNuJ3QgYmFkbHkgc2tld2VkLg0KPiANCj4+IDMu IFdvdWxkIHRoZSDigJxTZWN1cml0eSBDb25zaWRlcmF0aW9uc+KAnSBzZWN0aW9uIGJlbmVmaXQg ZnJvbSBzb21lIERvUyB0ZXh0LA0KPj4gZ2l2ZW4gdGhlIGNvbXB1dGF0aW9ucyByZXF1aXJlZCBh dCBib3RoIGVuZHMgb2YgdGhlIHN1YnNjcmlwdGlvbiBjaGFubmVsPyAgVGhlDQo+PiBwcml2YWN5 IGNvbnNpZGVyYXRpb25zIHRleHQgaXMgYWxzbyByYXRoZXIgbGlnaHQgY29tcGFyZWQgdG8gdGhh dCBpbiBSRkM4MDMwIC0NCj4+IHBlcmhhcHMgcG9pbnQgdGhlcmUsIGFuZCBjbGFyaWZ5IGFueSBh ZGRpdGlvbmFsIGNvbnNpZGVyYXRpb25zIHNwZWNpZmljIHRvIHRoaXMNCj4+IGRyYWZ0IGhlcmU/ DQo+IA0KPiBUaGlzIGRvY3VtZW50IHJlYWxseSBsZWFucyBoZWF2aWx5IG9uIFJGQyA4MDMwLCBz byBJJ2QgcHJlZmVyIHRvIGtlZXANCj4gdGhpcyBsZWFuIGFuZCBsZWF2ZSB0aGUgZGVlcGVyIGNv bnNpZGVyYXRpb25zIHRoZXJlLg0KPiANCj4gQXMgZm9yIGNvc3Qgb2YgY2FsY3VsYXRpb24sIHRo ZSBjb21wdXRhdGlvbnMgYXJlIGRvbmUgYnkgdGhlIGluaXRpYXRvcg0KPiBvZiB0aGUgdHJhbnNh Y3Rpb24gKHRoZSBBcHBsaWNhdGlvbiBTZXJ2ZXIpLCBmb3Igd2hvbSBJIGNhbiBzYXkgd2UNCj4g YXJlbid0IGNvbmNlcm5lZCBhYm91dCBjb21wdXRhdGlvbiBjb3N0OiB0aGUgaGlnaGVyIHRoZSBj b3N0LCB0aGUNCj4gZmV3ZXIgbWVzc2FnZXMgdGhleSBzZW5kLCB3aGljaCBtaWdodCBiZSBjb25z aWRlciBhIERvUyBtaXRpZ2F0aW9uDQo+IGJvbnVzLg0KPiANCj4gVGhlIG90aGVyIHBhcnR5IGlz IHRoZSBVc2VyIGFnZW50LCBmb3Igd2hvbSB0aGUgUHVzaCBTZXJ2aWNlIGFjdHMgYXMgYQ0KPiBz aGllbGQgLSB0aGF0IGlzIGJhc2ljYWxseSBpdHMgcHJpbWFyeSBwdXJwb3NlLiAgVXNlciBBZ2Vu dHMgc2hvdWxkbid0DQo+IGJlIGdldHRpbmcgYW55IG1vcmUgcHVzaCBtZXNzYWdlcyB0aGFuIHRo ZXkgY2FuIGhhbmRsZSwgd2l0aCBvcg0KPiB3aXRob3V0IGNyeXB0by4gIEluIGFueSBjYXNlLCB3 aGVuIGl0IGNvbWVzIHRvIHJlY2VpdmluZyBwdXNoDQo+IG1lc3NhZ2VzLCB0aGUgZmFjdCB0aGF0 IHRoZSByYWRpbyBpcyBiZWluZyB0dXJuZWQgb24gY29tcGxldGVseSBkd2FyZnMNCj4gdGhlIGVu ZXJneSBjb3N0IG9mIGEgZmV3IHNpbXBsZSBjcnlwdG9ncmFwaGljIGNvbXB1dGF0aW9ucy4NCj4g DQo+PiA0LiBBcmUgdGhlcmUgYW55IGNvbnNpZGVyYXRpb25zIGZvciB0aGlzIHNwZWMgaXMgdGhl IGxvYWQgZGlzdHJpYnV0aW9uDQo+PiBtZWNoYW5pc21zIGluIFNlY3Rpb24gNy4xIG9mIFJGQzgw MzAgYXJlIGVtcGxveWVkPyBJIGFzc3VtZSBub3QsIGJ1dCB0aGluayBpdOKAmXMNCj4+IHdvcnRo IGFza2luZy4NCj4gDQo+IEFsd2F5cyB3b3J0aCBhc2tpbmcsIGJ1dCBJIGRvbid0IGJlbGlldmUg dGhhdCB0aGVyZSBhcmUgYW55IGNvbmNlcm5zLg0KPiBUaGlzIHNwZWMgZG9lc24ndCB0b3VjaCB0 aGUgUHVzaCBTZXJ2aWNlIGF0IGFsbC4NCj4gDQo+PiBBbmQgb25lIG5pdDoNCj4gDQo+IEdvb2Qg Y2F0Y2gsIHlvdSBhcmUgdGhlIHNlY29uZCBwZXJzb24gdG8gbm90aWNlIGJvdGgsIEkgZml4ZWQg dGhlc2UgaW4NCj4gaHR0cHM6Ly9naXRodWIuY29tL3dlYnB1c2gtd2cvd2VicHVzaC1lbmNyeXB0 aW9uL3B1bGwvMTYgOikNCj4gDQoNCg== From nobody Mon Aug 14 02:57:26 2017 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1C5120721; Mon, 14 Aug 2017 02:57:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-webpush-encryption@ietf.org, Phil Sorber , webpush-chairs@ietf.org, sorber@apache.org, webpush@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150270464435.416.17538103695372768601.idtracker@ietfa.amsl.com> Date: Mon, 14 Aug 2017 02:57:24 -0700 Archived-At: Subject: [Webpush] Alexey Melnikov's No Objection on draft-ietf-webpush-encryption-08: (with COMMENT) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 14 Aug 2017 09:57:24 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-webpush-encryption-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-webpush-encryption/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is a fine document. One nit: 4. Restrictions on Use of "aes128gcm" Content Coding An Application Server MUST encrypt a push message with a single record. This allows for a minimal receiver implementation that handles a single record. An application server MUST set the "rs" parameter in the "aes128gcm" content coding header to a size that is greater than the some of the length of the plaintext, the padding s/some/sum ? delimiter (1 octet), any padding, and the authentication tag (16 octets). From nobody Mon Aug 14 03:12:35 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4572A132143; Mon, 14 Aug 2017 03:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zF1s588Ynn9A; Mon, 14 Aug 2017 03:12:29 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E74F41320E3; Mon, 14 Aug 2017 03:12:28 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id m34so9912400iti.1; Mon, 14 Aug 2017 03:12:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RZcHBwHFn7tCmnNNQNoMSBidPK6N9PA0EWY3Ye5WESY=; b=ky0d+TWfjOzOu3xzMLsFm8Z7TJirCKQYqQ2+7hJAbd2x2WK3dcnmaUktkOwkVM7PRY kSsPZYzTF4Z5SSBkg7R1A7Mwwho0sY5n5EykJNfat4OrAJpgvWuZbB2apQsGe0MFMD7B htcppTQBUrVZ/VGE5cqmRq+S6fsAlpfA4K3MOMcHxKk71CjjEmUJGBUOypAvQgmLxStl bAquK52IyW4q2n7jsJMUYD0kIvU+DQdh0zpYfOy9Jvp5Wc/jVmOLR9i9lLavTEeFghB3 VNQBo8XRV9aRoabBZz4J5jGFwgJYZ5GmEjzpf1ngHvePQ6BziG4OkoabLZArbkSJbtRC hm/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RZcHBwHFn7tCmnNNQNoMSBidPK6N9PA0EWY3Ye5WESY=; b=Ws0UdOTyEEyPp2F5StHGBK8qPU+LvEudLy3qbZObeleQNdDCKrExtqalXKZuCrnM0t GrCksixFWCaU2kCz04UsfkeS7CbXZ9p/UT1eYtPy0wuIy2wmk3sVZovrMdy2ZLdrdDTO gr7nyxPw02Z0dajH79vzJXMctANMiBR0CNOMO4IjczDoJotqzoeXDx66ha+e6xSo6gUA esBFDEFOIRrKibkmL8q6eh3d/Ra/bLIsJ1shW3UEVZEJ9cK4cxnvIfjHahgkCwu2f+ry D9ZK3gdu7uUHoa5B2LvQ2CYF/3+cn+w5PqD4QXdyW6N2x/zq+PRm7gd8R35ZUus6t28N hXVg== X-Gm-Message-State: AHYfb5jL2CYNgN6gmSO5sMsUMKYQua/g/Ad/KN1qChIskMB8ClOkeCsK TKQa+W80qQj6383f7uQ8qw/yrBfzjw== X-Received: by 10.36.120.16 with SMTP id p16mr3635836itc.151.1502705548240; Mon, 14 Aug 2017 03:12:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Mon, 14 Aug 2017 03:12:27 -0700 (PDT) In-Reply-To: <150270464435.416.17538103695372768601.idtracker@ietfa.amsl.com> References: <150270464435.416.17538103695372768601.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Mon, 14 Aug 2017 20:12:27 +1000 Message-ID: To: Alexey Melnikov Cc: The IESG , draft-ietf-webpush-encryption@ietf.org, Phil Sorber , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Webpush] Alexey Melnikov's No Objection on draft-ietf-webpush-encryption-08: (with COMMENT) X-BeenThere: webpush@ietf.org 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: Mon, 14 Aug 2017 10:12:30 -0000 On 14 August 2017 at 19:57, Alexey Melnikov wrote: > s/some/sum ? This was already fixed in the editor's copy. It's been a while since these went to the various directorates and they caught that one for us. From nobody Mon Aug 14 09:15:27 2017 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0251323A5; Mon, 14 Aug 2017 09:15:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-webpush-encryption@ietf.org, Phil Sorber , webpush-chairs@ietf.org, sorber@apache.org, webpush@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150272732169.470.8131025954910457986.idtracker@ietfa.amsl.com> Date: Mon, 14 Aug 2017 09:15:21 -0700 Archived-At: Subject: [Webpush] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-webpush-encryption-08=3A_=28with_COMMENT=29?= X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 14 Aug 2017 16:15:22 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-webpush-encryption-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-webpush-encryption/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- That would have been fixed by the RFC editor but anyway s/[I-D.ietf-webpush-protocol]/[RFC8030]/ From nobody Mon Aug 14 14:40:56 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70CB132441 for ; Mon, 14 Aug 2017 14:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.42 X-Spam-Level: X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZAvwE4eX6jI for ; Mon, 14 Aug 2017 14:40:53 -0700 (PDT) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id A7ED813243B for ; Mon, 14 Aug 2017 14:40:53 -0700 (PDT) Received: (qmail 23307 invoked by uid 99); 14 Aug 2017 21:40:53 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Aug 2017 21:40:53 +0000 Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.173]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 1FA311A0019; Mon, 14 Aug 2017 21:40:53 +0000 (UTC) Received: by mail-qk0-f173.google.com with SMTP id u139so57425476qka.1; Mon, 14 Aug 2017 14:40:53 -0700 (PDT) X-Gm-Message-State: AHYfb5gRo52K18ItxW8F3qrtUONIOAOZj5gdhTBR52PVnTFPd6DYsJG6 0bfUOkaQ9569K7aHE/jcsfEPoxRy+A== X-Received: by 10.233.232.72 with SMTP id a69mr31066700qkg.330.1502746851709; Mon, 14 Aug 2017 14:40:51 -0700 (PDT) MIME-Version: 1.0 References: <150161732457.12184.5254423236791059887.idtracker@ietfa.amsl.com> In-Reply-To: From: Phil Sorber Date: Mon, 14 Aug 2017 21:40:41 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Martin Thomson , Alexey Melnikov , Adam Roach Cc: The IESG , draft-ietf-webpush-vapid , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0353b84899a40556bd842e" Archived-At: Subject: Re: [Webpush] Alexey Melnikov's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT) X-BeenThere: webpush@ietf.org 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: Mon, 14 Aug 2017 21:40:56 -0000 --94eb2c0353b84899a40556bd842e Content-Type: text/plain; charset="UTF-8" Alexey, It appears that two of the three issues were addressed with changes to the spec. Do you find those changes as well as Martin's explanation of the third point satisfactory? If not, is there some more concrete changes that you would like to see? Thanks. On Tue, Aug 1, 2017 at 6:14 PM Martin Thomson wrote: > On 2 August 2017 at 05:55, Alexey Melnikov wrote: > > Firstly, "optjons" above should be "options". Secondly, the MIME type > > registration of application/webpush-options+json says that the MIME type > has no > > parameters, yet you use charset above. So which is it? > > As Phil notes, the first was corrected already, the second is in > c867529 on GitHub. I'll push a new version at Adam's instruction. > > > In Section 3, 3rd para: > > > > This authentication scheme does not require a challenge. Clients are > > able to generate the Authorization header field without any > > additional information from a server. Therefore, a challenge for > > this authentication scheme MUST NOT be sent in a WWW-Authenticate > > header field. > > > > Does this mean that there is no way to discover whether a particular > server > > supports "vapid" HTTP authentication scheme? > > Not directly. There was a plan to expose this via the User Agent, but > we didn't reach a conclusion: https://github.com/w3c/push-api/pull/262 > > Another document could override this as well, I suppose. The "MUST > NOT" exists primarily because we don't define a challenge. > --94eb2c0353b84899a40556bd842e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alexey,

It appears that two = of the three issues were addressed with changes to the spec. Do you find th= ose changes as well as Martin's explanation of the third point satisfac= tory? If not, is there some more concrete changes that you would like to se= e?

Thanks.

On Tue, Aug 1, 2017 at 6:14 PM Martin Thomson <martin.thomson@gmail.com> = wrote:
On 2 August 2017 at 05:55, A= lexey Melnikov <aamelnikov@fastmail.fm> wrote:
> Firstly, "optjons" above should be "options". Seco= ndly, the MIME type
> registration of application/webpush-options+json says that the MIME ty= pe has no
> parameters, yet you use charset above. So which is it?

As Phil notes, the first was corrected already, the second is in
c867529 on GitHub.=C2=A0 I'll push a new version at Adam's instruct= ion.

> In Section 3, 3rd para:
>
>=C2=A0 =C2=A0 This authentication scheme does not require a challenge.= =C2=A0 Clients are
>=C2=A0 =C2=A0 able to generate the Authorization header field without a= ny
>=C2=A0 =C2=A0 additional information from a server.=C2=A0 Therefore, a = challenge for
>=C2=A0 =C2=A0 this authentication scheme MUST NOT be sent in a WWW-Auth= enticate
>=C2=A0 =C2=A0 header field.
>
> Does this mean that there is no way to discover whether a particular s= erver
> supports "vapid" HTTP authentication scheme?

Not directly.=C2=A0 There was a plan to expose this via the User Agent, but=
we didn't reach a conclusion: https://github.com/w3c/pus= h-api/pull/262

Another document could override this as well, I suppose.=C2=A0 The "MU= ST
NOT" exists primarily because we don't define a challenge.
--94eb2c0353b84899a40556bd842e-- From nobody Tue Aug 15 02:37:04 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBFE132076; Tue, 15 Aug 2017 02:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=D2evsDSi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MFDNipZ8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeLTJV41-RXV; Tue, 15 Aug 2017 02:36:56 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5FDA13203D; Tue, 15 Aug 2017 02:36:56 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 12047219DE; Tue, 15 Aug 2017 05:36:56 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Tue, 15 Aug 2017 05:36:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=HjNdWLLcZLO4PTiapYY7j37T/8PPS Br9KHoFE3HbOSY=; b=D2evsDSih3I7aIxIN+xocc3oBkmIi767aD06qz7Cn+jAe zRXD8vUMeOD3nm/C8d0bFCy6oUChiDU2+ANuEW6pzx+gkY/74rilCIIz5vmFcLRV TfctMRHQUsEFZ6Yxq4Q3ngNiw8LfmHUp6zin5maPK64RSKMd9NbOuVd8Cwl93dFB l6E8OW3laWo5hZ93O3X43HYjuuOQQyu2OcRMygjwfb8VwQk9uI6aPZy21+i8wOrF 4rYdbydnSBxo4G5NA+Ztmr8m26HIPPXN2noWxNXhnEaVhfkZJ/ZxFbimwjvUgVS8 Sh/JZWAg8RlCHPSAUCvwNRZ/QUt4/TyiWMMKz1OaQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=HjNdWL LcZLO4PTiapYY7j37T/8PPSBr9KHoFE3HbOSY=; b=MFDNipZ8r/ndfl9STIpIiF 3PJsfabi2W4nCW9WrdUM5V6q2ONxPILe3KXKZh6Fh/K7n13cSKWLnqZtkQzM7UJG YCx8PiItErz/efW7Ble4qbgQirwCELHOxQwOsxaL3nec2vHX9h+KqpUAyizNiJMK D7SmOLJgQBoaMNZ46+q/BXJq/jy8aK6RSiZwIqKFRLFrsMOnSnOBd0div16ASLA3 TCs2NQv56nBS3oZq1SnIHsEdhLlayC+U9YpeaK1OeyLO5dg+43zDPyvcbMydWCp9 bE/PwEdeuV90Wxtapb5ZXgmpNNbzmzZT8l++UHAJO7kBRonrzvg+VYn1hfElRBtw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id E53BC9E270; Tue, 15 Aug 2017 05:36:55 -0400 (EDT) Message-Id: <1502789815.1179459.1073844136.43E95545@webmail.messagingengine.com> From: Alexey Melnikov To: Martin Thomson Cc: The IESG , "draft-ietf-webpush-vapid" , Phil Sorber , webpush-chairs@ietf.org, webpush@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-ff6d44b3 References: <150161732457.12184.5254423236791059887.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 10:36:55 +0100 In-Reply-To: Archived-At: Subject: Re: [Webpush] Alexey Melnikov's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT) X-BeenThere: webpush@ietf.org 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: Tue, 15 Aug 2017 09:36:58 -0000 On Wed, Aug 2, 2017, at 01:14 AM, Martin Thomson wrote: > On 2 August 2017 at 05:55, Alexey Melnikov > wrote: > > Firstly, "optjons" above should be "options". Secondly, the MIME type > > registration of application/webpush-options+json says that the MIME type has no > > parameters, yet you use charset above. So which is it? > > As Phil notes, the first was corrected already, the second is in > c867529 on GitHub. I'll push a new version at Adam's instruction. I prefer a new draft. What is the URL for the github? I couldn't find it on a quick glance. > > In Section 3, 3rd para: > > > > This authentication scheme does not require a challenge. Clients are > > able to generate the Authorization header field without any > > additional information from a server. Therefore, a challenge for > > this authentication scheme MUST NOT be sent in a WWW-Authenticate > > header field. > > > > Does this mean that there is no way to discover whether a particular server > > supports "vapid" HTTP authentication scheme? > > Not directly. There was a plan to expose this via the User Agent, but > we didn't reach a conclusion: https://github.com/w3c/push-api/pull/262 > > Another document could override this as well, I suppose. The "MUST > NOT" exists primarily because we don't define a challenge. I think all authentication schemes should be discoverable in WWW-Authenticate, as it is a part of HTTP authentication framework. I think it would be good to clarify whether inclusion of "vapid" in WWW-Authenticate without a challenge is allowed. The way your MUST NOT is worded makes me think that this is something that a server implementor can do accidentally. As there is no challenge data, I don't see how this can happen anyway. From nobody Tue Aug 15 04:39:28 2017 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD11C1320BE; Tue, 15 Aug 2017 04:39:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-webpush-vapid@ietf.org, Phil Sorber , webpush-chairs@ietf.org, sorber@apache.org, webpush@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150279716374.21102.11813544027973282978.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 04:39:23 -0700 Archived-At: Subject: [Webpush] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-webpush-vapid-03=3A_=28with_COMMENT=29?= X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 15 Aug 2017 11:39:24 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-webpush-vapid-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-webpush-vapid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Wondering if the new registry in section 6.2 is really needed. Is it expected that new parameters show up any time soon? For me this doc reads like that's the only two parameter you actually need. From nobody Tue Aug 15 08:47:56 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DD9132339 for ; Tue, 15 Aug 2017 08:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.419 X-Spam-Level: X-Spam-Status: No, score=-6.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jj39K9gUWumH for ; Tue, 15 Aug 2017 08:47:53 -0700 (PDT) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id 2F4B51321F1 for ; Tue, 15 Aug 2017 08:47:53 -0700 (PDT) Received: (qmail 23034 invoked by uid 99); 15 Aug 2017 15:41:12 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Aug 2017 15:41:12 +0000 Received: from mail-qt0-f178.google.com (mail-qt0-f178.google.com [209.85.216.178]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 73E101A041A; Tue, 15 Aug 2017 15:41:11 +0000 (UTC) Received: by mail-qt0-f178.google.com with SMTP id s6so6360000qtc.1; Tue, 15 Aug 2017 08:41:11 -0700 (PDT) X-Gm-Message-State: AHYfb5huNaKYI9NfGiseUooqKzOp4L7ak7WQOxeEdNtQLDuLHH5eIItW iwUis/FavrsLYNeyHvzcxuGiXcU9uQ== X-Received: by 10.200.54.210 with SMTP id b18mr41020086qtc.145.1502811669711; Tue, 15 Aug 2017 08:41:09 -0700 (PDT) MIME-Version: 1.0 References: <150161732457.12184.5254423236791059887.idtracker@ietfa.amsl.com> <1502789815.1179459.1073844136.43E95545@webmail.messagingengine.com> In-Reply-To: <1502789815.1179459.1073844136.43E95545@webmail.messagingengine.com> From: Phil Sorber Date: Tue, 15 Aug 2017 15:40:59 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Alexey Melnikov , Martin Thomson Cc: The IESG , draft-ietf-webpush-vapid , webpush-chairs@ietf.org, webpush@ietf.org Content-Type: multipart/alternative; boundary="001a113ad3bebcd5aa0556cc9bec" Archived-At: Subject: Re: [Webpush] Alexey Melnikov's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT) X-BeenThere: webpush@ietf.org 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: Tue, 15 Aug 2017 15:47:55 -0000 --001a113ad3bebcd5aa0556cc9bec Content-Type: text/plain; charset="UTF-8" On Tue, Aug 15, 2017 at 3:37 AM Alexey Melnikov wrote: > On Wed, Aug 2, 2017, at 01:14 AM, Martin Thomson wrote: > > On 2 August 2017 at 05:55, Alexey Melnikov > > wrote: > > > Firstly, "optjons" above should be "options". Secondly, the MIME type > > > registration of application/webpush-options+json says that the MIME > type has no > > > parameters, yet you use charset above. So which is it? > > > > As Phil notes, the first was corrected already, the second is in > > c867529 on GitHub. I'll push a new version at Adam's instruction. > > I prefer a new draft. Understood. The plan is to do that right after the telechat. > > What is the URL for the github? I couldn't find it on a quick glance. > > This is the repo: https://github.com/webpush-wg/webpush-vapid This is a diff of the last draft to current master: https://github.com/webpush-wg/webpush-vapid/compare/draft-ietf-webpush-vapid-03...master > > > In Section 3, 3rd para: > > > > > > This authentication scheme does not require a challenge. Clients > are > > > able to generate the Authorization header field without any > > > additional information from a server. Therefore, a challenge for > > > this authentication scheme MUST NOT be sent in a WWW-Authenticate > > > header field. > > > > > > Does this mean that there is no way to discover whether a particular > server > > > supports "vapid" HTTP authentication scheme? > > > > Not directly. There was a plan to expose this via the User Agent, but > > we didn't reach a conclusion: https://github.com/w3c/push-api/pull/262 > > > > Another document could override this as well, I suppose. The "MUST > > NOT" exists primarily because we don't define a challenge. > > I think all authentication schemes should be discoverable in > WWW-Authenticate, as it is a part of HTTP authentication framework. > > I think it would be good to clarify whether inclusion of "vapid" in > WWW-Authenticate without a challenge is allowed. The way your MUST NOT > is worded makes me think that this is something that a server > implementor can do accidentally. As there is no challenge data, I don't > see how this can happen anyway. > --001a113ad3bebcd5aa0556cc9bec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Aug 15= , 2017 at 3:37 AM Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
On Wed, Aug 2, 2017, at 01:14 AM, Martin Thomson wrote:
> On 2 August 2017 at 05:55, Alexey Melnikov <aamelnikov@fastmail.fm>
> wrote:
> > Firstly, "optjons" above should be "options".= Secondly, the MIME type
> > registration of application/webpush-options+json says that the MI= ME type has no
> > parameters, yet you use charset above. So which is it?
>
> As Phil notes, the first was corrected already, the second is in
> c867529 on GitHub.=C2=A0 I'll push a new version at Adam's ins= truction.

I prefer a new draft.

Understood. The plan = is to do that right after the telechat.
=C2=A0
=C2=A0
What is the URL for the github? I couldn't find it on a quick glance.

This is the repo:

This is a diff of the last = draft to current master:
> > In Section 3, 3rd para:
> >
> >=C2=A0 =C2=A0 This authentication scheme does not require a challe= nge.=C2=A0 Clients are
> >=C2=A0 =C2=A0 able to generate the Authorization header field with= out any
> >=C2=A0 =C2=A0 additional information from a server.=C2=A0 Therefor= e, a challenge for
> >=C2=A0 =C2=A0 this authentication scheme MUST NOT be sent in a WWW= -Authenticate
> >=C2=A0 =C2=A0 header field.
> >
> > Does this mean that there is no way to discover whether a particu= lar server
> > supports "vapid" HTTP authentication scheme?
>
> Not directly.=C2=A0 There was a plan to expose this via the User Agent= , but
> we didn't reach a conclusion: https://github.com/w3= c/push-api/pull/262
>
> Another document could override this as well, I suppose.=C2=A0 The &qu= ot;MUST
> NOT" exists primarily because we don't define a challenge.
I think all authentication schemes should be discoverable in
WWW-Authenticate, as it is a part of HTTP authentication framework.

I think it would be good to clarify whether inclusion of "vapid" = in
WWW-Authenticate without a challenge is allowed. The way your MUST NOT
is worded makes me think that this is something that a server
implementor can do accidentally. As there is no challenge data, I don't=
see how this can happen anyway.
--001a113ad3bebcd5aa0556cc9bec-- From nobody Tue Aug 15 09:15:25 2017 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6EB1320BD; Tue, 15 Aug 2017 09:15:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-webpush-encryption@ietf.org, Phil Sorber , webpush-chairs@ietf.org, sorber@apache.org, webpush@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150281372252.21061.13568867134437858167.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 09:15:22 -0700 Archived-At: Subject: [Webpush] Spencer Dawkins' Yes on draft-ietf-webpush-encryption-08: (with COMMENT) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 15 Aug 2017 16:15:22 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-webpush-encryption-08: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-webpush-encryption/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is really well written and clear. Thank you for that. I found “for efficiency reasons” in this text For efficiency reasons, multiple users of Web Push often share a central agent that aggregates push functionality. To be so broad that I wasn’t sure what you were telling the reader. Are there any specific efficiencies that you could call out, so that we’d better understand why central agents are used? And if that’s already written down someplace, adding a pointer would be even better. I’m curious about algorithm agility, but I’m not the person to ask that question ... From nobody Tue Aug 15 10:10:48 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB6313228D; Tue, 15 Aug 2017 10:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=LfqGMUGy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nhshvkIu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guBuezYLgssS; Tue, 15 Aug 2017 10:10:37 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2B9813238E; Tue, 15 Aug 2017 10:10:35 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 413EE20899; Tue, 15 Aug 2017 13:10:28 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Tue, 15 Aug 2017 13:10:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=zjZA+K4GIj7x7msXF45vciz0sxaa+ ABolkiK6KhhTOQ=; b=LfqGMUGyLyDo6hJIif4dZ5rFEWb0aF/EIKYSGjKFVqUGS 7lOe873kWXL+R95rJm0ihRZxae6kwHyiyPf/0imh+Orj/lPLSq/wiolM3NfiUjYm puyRF5d3AbrLponKMC2NLhOmyEJ6h8omALcupMJBJoHBsZZJXRC3vOr+ifJOHivo 2bZmY+kp0C5J1hGK3BwdJx9ifcGaYnLO+egAyi4s0C8qtcaH003pyYF+Ir79Yyes WWmsngUXfPh5l0jCPtXGfRUiuKNhWxFG9I9emucluiky/+74p67SizK9pvC0yvhd V/IXNrCgfHbl7XPvxxXw87nJWPdf6xN0LNd7QnbSQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=zjZA+K 4GIj7x7msXF45vciz0sxaa+ABolkiK6KhhTOQ=; b=nhshvkIu8IUnYj49u41N33 nMcR9NkTEz2Mu5YWULwTUrvsSq3qWfNyz5rk0siRScgellixz7xcak7yRsIb+aKt IT8sloQGsN8jVexK1Rp6h0l0i5LjIiglvvax4aLkm4UsY5Pa0aR4Fjz6c9SirdOG fk17iey5cAhf1HSLwAWS1DE9qpXhHHjkOWp67jCqt77Kd7jILDTD+x0wL05ST8qT T0wdK2dmkTlKjBDZRz+RtPMP9QttJSxU7YaXUsNKxYmlk7H3nW2U9Ny2feWUkYkB 3ovdyZYBViGadu05dW7kb8GuAI3f95z6YeFmKMDHq2ovw+tAamp7gKqF7xeoCJ3w == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 1D08A9E2AC; Tue, 15 Aug 2017 13:10:28 -0400 (EDT) Message-Id: <1502817028.2069722.1074294944.009E9EE6@webmail.messagingengine.com> From: Alexey Melnikov To: Phil Sorber , Martin Thomson Cc: The IESG , "draft-ietf-webpush-vapid" , webpush-chairs@ietf.org, webpush@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150281702820697220" X-Mailer: MessagingEngine.com Webmail Interface - ajax-ff6d44b3 References: <150161732457.12184.5254423236791059887.idtracker@ietfa.amsl.com> <1502789815.1179459.1073844136.43E95545@webmail.messagingengine.com> In-Reply-To: Date: Tue, 15 Aug 2017 18:10:28 +0100 Archived-At: Subject: Re: [Webpush] Alexey Melnikov's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT) X-BeenThere: webpush@ietf.org 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: Tue, 15 Aug 2017 17:10:41 -0000 This is a multi-part message in MIME format. --_----------=_150281702820697220 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, Aug 15, 2017, at 04:40 PM, Phil Sorber wrote: > On Tue, Aug 15, 2017 at 3:37 AM Alexey Melnikov > wrote:>> On Wed, Aug 2, 2017, at 01:14 AM, Martin Thomson wrote: >> > On 2 August 2017 at 05:55, Alexey Melnikov >> > >> > wrote: >> > > Firstly, "optjons" above should be "options". Secondly, the MIME >> > > type>> > > registration of application/webpush-options+json says that the >> > > MIME type has no>> > > parameters, yet you use charset above. So which is it? >> > >> > As Phil notes, the first was corrected already, the second is in >> > c867529 on GitHub. I'll push a new version at Adam's instruction.>> >> I prefer a new draft. > > Understood. The plan is to do that right after the telechat. > >> >> What is the URL for the github? I couldn't find it on a quick glance.>> > > This is the repo: > https://github.com/webpush-wg/webpush-vapid > > This is a diff of the last draft to current master: > https://github.com/webpush-wg/webpush-vapid/compare/draft-ietf-webpush-vapid-03...master I can clear my DISCUSS based on these changes. > >> > > In Section 3, 3rd para: >> > > >> > > This authentication scheme does not require a challenge. >> > > Clients are>> > > able to generate the Authorization header field without any >> > > additional information from a server. Therefore, a challenge >> > > for>> > > this authentication scheme MUST NOT be sent in a WWW- >> > > Authenticate>> > > header field. >> > > >> > > Does this mean that there is no way to discover whether a >> > > particular server>> > > supports "vapid" HTTP authentication scheme? >> > >> > Not directly. There was a plan to expose this via the User >> > Agent, but>> > we didn't reach a conclusion: >> > https://github.com/w3c/push-api/pull/262>> > >> > Another document could override this as well, I suppose. The >> > "MUST>> > NOT" exists primarily because we don't define a challenge. >> >> I think all authentication schemes should be discoverable in >> WWW-Authenticate, as it is a part of HTTP authentication framework.>> >> I think it would be good to clarify whether inclusion of "vapid" in>> WWW-Authenticate without a challenge is allowed. The way your >> MUST NOT>> is worded makes me think that this is something that a server >> implementor can do accidentally. As there is no challenge data, >> I don't>> see how this can happen anyway. --_----------=_150281702820697220 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, Aug 15, 2017, at 04:40 PM, Phil Sorber wrote:
On Tue, Aug 15, 2017 at 3:37 AM Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
On Wed, Aug 2, 2017, at 01:14 AM, Martin Thomson wrote:
> On 2 August 2017 at 05:55, Alexey Melnikov <aamelnikov@fastmail.fm>
> wrote:
> > Firstly, "optjons" above should be "options". Secondly, the MIME type
> > registration of application/webpush-options+json says that the MIME type has no
> > parameters, yet you use charset above. So which is it?
>
> As Phil notes, the first was corrected already, the second is in
> c867529 on GitHub.  I'll push a new version at Adam's instruction.

I prefer a new draft.

Understood. The plan is to do that right after the telechat.
 
 
What is the URL for the github? I couldn't find it on a quick glance.


This is the repo:

This is a diff of the last draft to current master:

I can clear my DISCUSS based on these changes.

 
> > In Section 3, 3rd para:
> >
> >    This authentication scheme does not require a challenge.  Clients are
> >    able to generate the Authorization header field without any
> >    additional information from a server.  Therefore, a challenge for
> >    this authentication scheme MUST NOT be sent in a WWW-Authenticate
> >    header field.
> >
> > Does this mean that there is no way to discover whether a particular server
> > supports "vapid" HTTP authentication scheme?
>
> Not directly.  There was a plan to expose this via the User Agent, but
> we didn't reach a conclusion: https://github.com/w3c/push-api/pull/262
>
> Another document could override this as well, I suppose.  The "MUST
> NOT" exists primarily because we don't define a challenge.

I think all authentication schemes should be discoverable in
WWW-Authenticate, as it is a part of HTTP authentication framework.

I think it would be good to clarify whether inclusion of "vapid" in
WWW-Authenticate without a challenge is allowed. The way your MUST NOT
is worded makes me think that this is something that a server
implementor can do accidentally. As there is no challenge data, I don't
see how this can happen anyway.

--_----------=_150281702820697220-- From nobody Tue Aug 15 10:12:39 2017 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A0B13228D; Tue, 15 Aug 2017 10:12:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-webpush-vapid@ietf.org, Phil Sorber , webpush-chairs@ietf.org, sorber@apache.org, webpush@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150281715482.21106.3346502830630897599.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 10:12:34 -0700 Archived-At: Subject: [Webpush] Alexey Melnikov's No Objection on draft-ietf-webpush-vapid-03: (with COMMENT) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 15 Aug 2017 17:12:35 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-webpush-vapid-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-webpush-vapid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have cleared my DISCUSS based on changes in git. I am looking forward to continuing discussion about advertising support for the "vapid" authentication scheme in WWW-Authenticate: In Section 3, 3rd para: This authentication scheme does not require a challenge. Clients are able to generate the Authorization header field without any additional information from a server. Therefore, a challenge for this authentication scheme MUST NOT be sent in a WWW-Authenticate header field. Does this mean that there is no way to discover whether a particular server supports "vapid" HTTP authentication scheme? From nobody Tue Aug 15 10:20:29 2017 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9D013219E; Tue, 15 Aug 2017 10:20:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-webpush-vapid@ietf.org, Phil Sorber , webpush-chairs@ietf.org, sorber@apache.org, webpush@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150281762174.21115.10126123891463241768.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 10:20:21 -0700 Archived-At: Subject: [Webpush] Warren Kumari's No Objection on draft-ietf-webpush-vapid-03: (with COMMENT) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 15 Aug 2017 17:20:22 -0000 Warren Kumari has entered the following ballot position for draft-ietf-webpush-vapid-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-webpush-vapid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- *Very* minor nits: 1: I'm reviewing both this document and draft-ietf-webpush-encryption (both of which have Martin Thomson as an author) -- these use different capitalizations for many terms, for example "user agent" vs "User Agent" -- this document references RFC8030, which has these lower-case, and so I suspect that it is draft-ietf-webpush-encryption which should change, but I figured I'm mention it here as well. 2: Section 7. Acknowledgements "This document would have been much worse than it currently is if not for the contributions ..." Once published as an RFC, it is cast in stone. I support your the above, but think you should remove "currently", so perhaps: "This document would have been much worse if not for the contributions ..." Again, these are tiny nits, I don't have enough knowledge of the topic to make more useful comments :-P From nobody Tue Aug 15 10:56:54 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CE6126B6E; Tue, 15 Aug 2017 10:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOjYx2AHlTwl; Tue, 15 Aug 2017 10:56:51 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62DE6120713; Tue, 15 Aug 2017 10:56:51 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id v189so9905342pgd.2; Tue, 15 Aug 2017 10:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Xgu6T4Vc/QuqXhtKugMcZjMYDSCw089heSer/DQ5i8k=; b=TG2maLQG2TiHMQTdGv2yP2c0C2TTnod4Zw337J9fB2g0H55h5TXEhRQ7vnm6rjr1XH tfAxujPbh0YYpEFG/iJSGkQzqm0KZj517XFZ02B3tJtDGozyT7h51A9AV6nNWMnDtZqs whDIgyKitcc0Vs5EUOT8StwJNrswElEMBLepM/rGCpDaWl3lLsQXtvfFyt42pYCe33sa Dgz5vvYmpZDorbSR+JUR+dT4006MtEiFAsw4KnpmEiIZFnMZbbEianraoqITeLJhlSBJ gGih8fO3oyJrUKT8JZpQURpNRR385cIAv/+s00/u1R8+8/HY/qvXCcjhBwE9dKj+tHp/ GdNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Xgu6T4Vc/QuqXhtKugMcZjMYDSCw089heSer/DQ5i8k=; b=k3SvxXk7fwdHlth5sj6IB7V1F0RewU7PL45ZEeTiMp1yF+u+8AWMphVFHFcyxJ5ETe iwnFiYrqYjc2HCQGoQ31Tn6i3gOI2pGa/KNocZ0ZTlNZ6DqbeGPT6UD5YJ8puFUiQYrZ P2nXhPCy46DOESqQGZOqHYOsQO7YyE25GzWe3Ugsm2k4Q1o9OHEjohlRglgkyXWWNgHq gg2/uxltgjAiNn24C1Fndy5hXQcTTDcKiO7QAVIQek4Mw1r2YTiB2Tm9YpI8UsBX8jtt q4CUYY5MfxP0aRtAGuvAd6NSxA0PFoc1bAHCVgj/9lhmK8dIYWoGg9HkP7vHyAZ+d6Dc 0O0w== X-Gm-Message-State: AHYfb5gkdEXXF6J57ppLeLy+e5YW/JjOTXfdhKJTa8Y7gLwpwFVRzH7A 9zw8/K0WSh8Q2v+ZHD90T6s9eAzioSIK X-Received: by 10.98.223.68 with SMTP id u65mr28459777pfg.98.1502819810841; Tue, 15 Aug 2017 10:56:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.138.76 with HTTP; Tue, 15 Aug 2017 10:56:50 -0700 (PDT) In-Reply-To: <150281715482.21106.3346502830630897599.idtracker@ietfa.amsl.com> References: <150281715482.21106.3346502830630897599.idtracker@ietfa.amsl.com> From: Costin Manolache Date: Tue, 15 Aug 2017 10:56:50 -0700 Message-ID: To: Alexey Melnikov Cc: The IESG , draft-ietf-webpush-vapid@ietf.org, webpush-chairs@ietf.org, "webpush@ietf.org" , sorber@apache.org Content-Type: multipart/alternative; boundary="94eb2c14fdbcfc99140556ce80ed" Archived-At: Subject: Re: [Webpush] Alexey Melnikov's No Objection on draft-ietf-webpush-vapid-03: (with COMMENT) X-BeenThere: webpush@ietf.org 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: Tue, 15 Aug 2017 17:56:53 -0000 --94eb2c14fdbcfc99140556ce80ed Content-Type: text/plain; charset="UTF-8" IMHO out-of-band discovery may be sufficient - in webpush it is implicit or can be part of the subscribe handshake. If VAPID is used with an API the supported auth may be part of the API schema/discovery. I think in future it may be valuable to add an optional certificate - either as an extra header or parameter - to allow authentication without a database RT. In such mode a mechanism to discover supported roots may be needed - however it can also be done out-of-band. B Costin On Tue, Aug 15, 2017 at 10:12 AM, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-webpush-vapid-03: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-webpush-vapid/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I have cleared my DISCUSS based on changes in git. > > I am looking forward to continuing discussion about advertising support > for the > "vapid" authentication scheme in WWW-Authenticate: > > In Section 3, 3rd para: > > This authentication scheme does not require a challenge. Clients are > able to generate the Authorization header field without any > additional information from a server. Therefore, a challenge for > this authentication scheme MUST NOT be sent in a WWW-Authenticate > header field. > > Does this mean that there is no way to discover whether a particular server > supports "vapid" HTTP authentication scheme? > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --94eb2c14fdbcfc99140556ce80ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
IMHO out-of-band discovery may be sufficient - in webpush = it is implicit or can be part of the
subscribe handshake. If VAPID is u= sed with an API the supported auth may be part of the API
schema/= discovery.

I think in future it may be valuable to add a= n optional certificate - either as an extra header or parameter -=C2=A0
to allow authentication without a database RT. In such mode a mechan= ism to discover supported
roots may be needed - however it can al= so be done out-of-band.

B

Costin


On Tue, Aug 15, 2017 at 10:12 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
Alexey Melnikov has entered the following ballot position for
draft-ietf-webpush-vapid-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-webpush-vapid/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I have cleared my DISCUSS based on changes in git.

I am looking forward to continuing discussion about advertising support for= the
"vapid" authentication scheme in WWW-Authenticate:

In Section 3, 3rd para:

=C2=A0 =C2=A0This authentication scheme does not require a challenge.=C2=A0= Clients are
=C2=A0 =C2=A0able to generate the Authorization header field without any =C2=A0 =C2=A0additional information from a server.=C2=A0 Therefore, a chall= enge for
=C2=A0 =C2=A0this authentication scheme MUST NOT be sent in a WWW-Authentic= ate
=C2=A0 =C2=A0header field.

Does this mean that there is no way to discover whether a particular server=
supports "vapid" HTTP authentication scheme?


_______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush<= br>

--94eb2c14fdbcfc99140556ce80ed-- From nobody Tue Aug 15 11:00:03 2017 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7538F126B6E; Tue, 15 Aug 2017 10:59:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-webpush-encryption@ietf.org, Phil Sorber , webpush-chairs@ietf.org, sorber@apache.org, webpush@ietf.org, tim.chown@jisc.ac.uk X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150281999738.21016.2164260159984776251.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 10:59:57 -0700 Archived-At: Subject: [Webpush] Warren Kumari's No Objection on draft-ietf-webpush-encryption-08: (with COMMENT) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 15 Aug 2017 17:59:57 -0000 Warren Kumari has entered the following ballot position for draft-ietf-webpush-encryption-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-webpush-encryption/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Firstly, thanks to Tim Chown for his helpful OpsDir review ( https://datatracker.ietf.org/doc/review-ietf-webpush-encryption-08-opsdir-lc-chown-2017-08-01/ ) and for your response. I only have nits on this document: 1: I reviewed this and draft-ietf-webpush-vapid together. This document uses title case for "User Agent" (and many other terms), while draft-ietf-webpush-vapid and RFC8030 uses lower-case. Consistency would be nice here. 2: Section 2: "In addition to the reasons described in [I-D.ietf-webpush-protocol], this ensures that the authentication secret is not revealed to unauthorized entities, which can be used to generate push messages that will be accepted by the User Agent." -- this is ambiguous / confusing. It is unclear which which is which. I'd suggest rewording to something like "... to unauthorized entities, which would allow that entities to generate push messages that would be accepted by the User Agent as valid" (or similar) 3: Section 7. Security Considerations "In particular, any HTTP header fields are not protected by the content encoding scheme." -- I think you may mean "In particular, no HTTP header fields are protected ..." (or similar) From nobody Tue Aug 15 11:50:25 2017 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 460A5132256; Tue, 15 Aug 2017 11:50:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-webpush-vapid@ietf.org, Phil Sorber , webpush-chairs@ietf.org, sorber@apache.org, webpush@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150282302424.20984.16954614287039839165.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 11:50:24 -0700 Archived-At: Subject: [Webpush] Kathleen Moriarty's No Objection on draft-ietf-webpush-vapid-03: (with COMMENT) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 15 Aug 2017 18:50:24 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-webpush-vapid-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-webpush-vapid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for your work on this draft. In section 3, it seems that you are just signing the JWK and that seems fine from the text and the purpose listed - origin server authentication. Then in section 3.2, there's a reference to I-D.ietf-webpush-encryption saying, "An application server MUST select a different private key for the key exchange". This makes me think that encryption is used as well, but I think it would be helpful to see the point made more clear here or in the security considerations section. Is confidentiality provided/required or just integrity for this draft? From nobody Tue Aug 15 16:42:36 2017 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2EF3132666; Tue, 15 Aug 2017 16:42:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-webpush-vapid@ietf.org, Phil Sorber , webpush-chairs@ietf.org, sorber@apache.org, webpush@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150284054989.12518.11340069078773708886.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 16:42:29 -0700 Archived-At: Subject: [Webpush] Eric Rescorla's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 15 Aug 2017 23:42:30 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-webpush-vapid-03: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-webpush-vapid/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This design seems to have the unfortunate security property that the JWT is really just a bearer token. The only reason it has to involve public key cryptography at all is to allow the push cient to refer to the public key when it makes a subscription. However, as the Security Considerations acknowledge, this allows a cut-and-paste attack (more than just replay) by an attacker who acquires any JWT, because it does not include the message itself. The primary motivation for this appears to be to minimize CPU cost on the push service. However, there are designs which do this without allowing replay. For instance: - Have the push service have a static public key K_svc which is published to application servers (e.g., via well-known). - In order to form the JWT, have the application server generate a fresh DH key K_app, which is embedded in the JWT. - The message which the app server sends to the push service is then MACed with the DH shared secret Z. This removes the cut-and-paste attack (though of course replay attacks are still possible) unless the push service keeps a replay cache. The replay service can trivially amortize the DH computation (it has to amortize the signature verification in any case to get any computational benefit) but it's soft state, so it can just forget it at any time. Ultimately, this is a WG decision, but given that there are designs with much better security properties, I'd like to know that the WG considered and rejected this kind of design alternative before we advance the weaker design. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Abstract This identification information can be used to restrict the use of a push subscription a single application server. to a single S 1. Additionally, this design also relies on endpoint secrecy as any application server in possession of the endpoint is able to send messages, albeit without payloads. In situations where usage of a subscription can be limited to a single application server, the ability to associate a subscription with the application server could reduce the impact of a data leak. I don't understand this text. S 1.2 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this document. It’s not shouting, when they are capitalized, they have the special meaning described in [RFC2119]. This seems over-cute. We now have a document that describes this convention. S 2. This JWT is included in an Authorization header field, using an auth- scheme of "vapid". A push service MAY reject a request with a 403 (Forbidden) status code [RFC7235] if the JWT signature or its claims are invalid. Given that "vapid" is tied to "P-256" it seems like it would be better to rename this "vapid-p256" S 4.2. When a push subscription has been associated with an application server, the request for push message delivery MUST include proof of possession for the associated private key that was used when creating the push subscription. This really isn't a proof of possession, as the Security Considerations makes clear. S 5. You should call out that the email address is just a bare assertion. From nobody Tue Aug 15 17:04:15 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6126E13244A; Tue, 15 Aug 2017 17:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LqGg-_dqxG2; Tue, 15 Aug 2017 17:03:51 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C3B132435; Tue, 15 Aug 2017 17:03:51 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id m34so11003354iti.1; Tue, 15 Aug 2017 17:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=BGTfInT/IREdmipskIiMHOi7AxxlfiknrRE5264Krhc=; b=VA2KekIONCBfeGXn4G/926nImhYuvMMQdO/KsZ9010oO7gWD6hAXlae1m8tR+6K3o3 aXhtpo5SbZrOjQQhgh0s0KEHJibGJN+hcQmjpJH5SFGhZOG1eJrVIBkvjcdjpfMHwvAX DKA7hQlIVpgIDhZxykSEiV6gLzdwdIJ7ZSA+Hk0pY9UQNg+/9pRiUUc3z5bAnvD2cLZ7 Bm98N8LEIhuH/Ha8RGvdSdka2muiXkoyavNljjwSFl3H/pWfGx/skfNbMu19DYqdOfRn hU0eQUPhrC86vi1YiQay9RZ8YYCEiznB5B+OiZW+vHh5AUn6zBCe+p2oEuInb7KGnMtW 5sqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=BGTfInT/IREdmipskIiMHOi7AxxlfiknrRE5264Krhc=; b=MAb0nBbZF6ravVjNclm+5SoSwBw7hjrCrjLkwwOvjYsfyJACbSsDCZYeO9+jSUm6/F hJBWjmm+Wm5X7T/UQodObwyhISI4QRWSba/c49p7wHlUIskmMXS1ucZcWxhHylmSjxFB AJL6jMy6QZ/Isxb6jeSPC7V2pYsmNIdm49QaPBQbeMSgpPkut+GkMrwolnXkxDuh+wCf Yi6wZ5oHwKwXHNm5teazQhab0fg2wGiiuzeMRGNP8N4M2L3XGmHjSy6OAev0m9dqayVo lqWO96n4rNcniwLMqmHN5JVz96GZGnnpbRzNrImGFeF7AKjpCioBCu6sNk5NwqtwAQiU NONQ== X-Gm-Message-State: AHYfb5htk29LPp/Vs/QVWbSkcU6jWOq8pxQP4HJ16PRT+vOSw4iNZUgZ o5pTVx+FQPW/zvQj7kbZ4ckJGgMosg== X-Received: by 10.36.107.68 with SMTP id v65mr324939itc.129.1502841830964; Tue, 15 Aug 2017 17:03:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Tue, 15 Aug 2017 17:03:50 -0700 (PDT) In-Reply-To: <150281372252.21061.13568867134437858167.idtracker@ietfa.amsl.com> References: <150281372252.21061.13568867134437858167.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Wed, 16 Aug 2017 10:03:50 +1000 Message-ID: To: Spencer Dawkins Cc: The IESG , draft-ietf-webpush-encryption@ietf.org, Phil Sorber , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Webpush] Spencer Dawkins' Yes on draft-ietf-webpush-encryption-08: (with COMMENT) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 00:04:00 -0000 On 16 August 2017 at 02:15, Spencer Dawkins wrote: > I found =E2=80=9Cfor efficiency reasons=E2=80=9D in this text > > For efficiency reasons, multiple users of Web Push often share a > central agent that aggregates push functionality. > > To be so broad that I wasn=E2=80=99t sure what you were telling the reade= r. Are there > any specific efficiencies that you could call out, so that we=E2=80=99d b= etter > understand why central agents are used? And if that=E2=80=99s already wri= tten down > someplace, adding a pointer would be even better. It's engineering efficiency more than anything else. On mobile platforms, this is the platform; on browsers, the browser. If I remove the "for efficiency reasons" clause, I don't think we lose anything. > I=E2=80=99m curious about algorithm agility, but I=E2=80=99m not the pers= on to ask that > question ... It's a common question. Common enough that I'll add some text and avoid future occurrences. We have deployment experience with this already. We deployed an earlier version, then had to change it a few times. So we know how to do this. The User Agent tells the application what content codings it likes. The W3C spec has a supportedContentEncodings parameter on the PushManager interface that does this (https://w3c.github.io/push-api/#pushmanager-interface). For you: https://github.com/webpush-wg/webpush-encryption/pull/18 From nobody Tue Aug 15 17:05:10 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6ECC1323AC; Tue, 15 Aug 2017 17:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_QG0Lcp_2e4; Tue, 15 Aug 2017 17:05:07 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCA451323BE; Tue, 15 Aug 2017 17:05:07 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id 76so11212553ith.0; Tue, 15 Aug 2017 17:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NRY3aCYU83bqKmtv4qbLvkXkalNN7O1vEytf9esjLw0=; b=rYmY/jYV2NM1DEet+MbBektkwV0ZgCX4MqleEe86AMxbDgad6PsCRUSHkPHO3zyp+J yu54TlsocZcyrxQmosCSxy3hl3my/IrwiyABjTLArixsxmuH9kkqX6uTw25rzSO89mGW H0BoNoSnL0DaMZr6klgtROd8QYUweUEHJ1eE3GWJRLbBiPB/TIRY65XmpsYrFMSeCf6L C1lIcY4oDOp4v4MsH783RvzwGXwheHWFL+eIvMdpur0+LVzCZKtnmEZzPhykQECC422q 4SPas4JkjeUbAvDlDRSbTu9GIbTy4sxRQSPoji5NQd2m/tCe86blJAy1HlasfNd0Jmjr FYQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=NRY3aCYU83bqKmtv4qbLvkXkalNN7O1vEytf9esjLw0=; b=MOPqGIL3pNmSy2GudmP0B9Lsg7wcLPIa07SaifHdM8PF9osAzPT4lx4h7C5QUbj+km 5MfucTbYjz6aiAVZ2nw0WHMdF64yG4WSshTJTlZxlRGVZTyvo9/y+V7OjfNXo7i0OacR 17vnAn4oODnUP2xcq4cqkAku/UzOwee6mgutzmuRDSbw4a/BRlpOfinFmjj8yJnKBAJE qhMiOaPwn74uUZXUGRNJTcWuwzpF4sXvSSccIEf0ich6oelphdIqBbvHoSmdwSCim+oX nO+dHvayrjSCNX50NX65xSzPiQ+fnxeXUwNqZIY7OohMRqz0SbAvUcEnpEphVCVCZL3g 6LnA== X-Gm-Message-State: AHYfb5jDn+ZfcZ2Xnrg2XLDYeWDUuz2eQfpmW3mvxYXO4afV5ruOJE+1 o4zevjuBTSvzWpmB/fIpMjtiM4xnoHzY X-Received: by 10.36.193.199 with SMTP id e190mr316058itg.122.1502841907191; Tue, 15 Aug 2017 17:05:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Tue, 15 Aug 2017 17:05:06 -0700 (PDT) In-Reply-To: <150279716374.21102.11813544027973282978.idtracker@ietfa.amsl.com> References: <150279716374.21102.11813544027973282978.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Wed, 16 Aug 2017 10:05:06 +1000 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , draft-ietf-webpush-vapid , Phil Sorber , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Webpush] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-webpush-vapid-03=3A_=28with_COMMENT=29?= X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 00:05:10 -0000 On 15 August 2017 at 21:39, Mirja K=C3=BChlewind wrot= e: > Wondering if the new registry in section 6.2 is really needed. Is it expe= cted > that new parameters show up any time soon? For me this doc reads like tha= t's > the only two parameter you actually need. I think that ekr's DISCUSS might make it clear that it isn't a complete waste of effort :) From nobody Tue Aug 15 17:16:24 2017 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBDC1321AC; Tue, 15 Aug 2017 17:16:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-webpush-encryption@ietf.org, Phil Sorber , webpush-chairs@ietf.org, sorber@apache.org, webpush@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150284258239.12573.16971816775097833907.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 17:16:22 -0700 Archived-At: Subject: [Webpush] Eric Rescorla's Discuss on draft-ietf-webpush-encryption-08: (with DISCUSS and COMMENT) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 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, 16 Aug 2017 00:16:22 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-webpush-encryption-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-webpush-encryption/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Given that you have a static key on the UA, the security considerations should discuss point verification, or why it's not needed. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- S 1. This document describes how messages sent using this protocol can be secured against inspection, modification and falsification by a Push Service. "forgery" is more customary than falsification. S 3.3. key_info = "WebPush: info" || 0x00 || ua_public || as_public You should make clear that the string is not null-terminated. Ugh, I know. S 3.4. You should clearly separate which pieces are defined in this document and which are defined in the HTTP encryption document. From nobody Tue Aug 15 17:16:45 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408621323C8; Tue, 15 Aug 2017 17:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ew-B2s2dIbNh; Tue, 15 Aug 2017 17:16:28 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D15AE1321AC; Tue, 15 Aug 2017 17:16:27 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id 77so11314074itj.1; Tue, 15 Aug 2017 17:16:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qo6uSLbZXqjXdOMcYzPTTzviiK45WYoKeoreptsbOP4=; b=jeix2Z8MmefOoOlF79vvy80j+4j/FDZko4r68ZvbEcu7khYMBJBM7y/S+TKfpqro5+ Gvq07qB1wWFal2H2RMEEBfnUFu6o9p50AUvX2Fz41eqVHwcqZOGjhMM/6QTcNcKzTAvT VxjRmysyaZZSr7e+x58OjhR9/LaEMYQRWzswU1snqXq5DtNHwPvFY5R5tlu9TxCg7y0P aHvEvRj8ZkYtbrJHFgh8/hMutQMJUMVEO7Ja/ApS9OizRRvb7ZNbW2VqrnfeuqkQCsVn kG6nx0i1UnjJOCAG9yU4LM5IvlKI0JT7JuSG3mTOObIpfEU3Oh+gjmy1MKO5kDRXR/Yj ySmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qo6uSLbZXqjXdOMcYzPTTzviiK45WYoKeoreptsbOP4=; b=rGepY5/QaMwGtsEvTMOpScito7R5zsI93J/hKM+l76duMO40NnZhr13zLW/XN5uaC7 WGPp1ZYu64nDVYN8cOBkZl75FYG6akZfNtvDqIV7dQ1lvFEeeiHY3qVJuPbGQIdE4fQs bjSfOB0LuVVyuPkz9g4W+9kbygdGWahEkSOu9TlyCgqP5yx5/MTLAt6DhPd+Z/VHdCw/ FYV3JTkQqzw8Eb6GauNGVCRkaqwO/Yo4BntSJujk2zuatjTpW9IqtiqfPs8bcm9cnNaJ rFXYg131rTQ/Z7xneSieS4up/oQc9k6pN4Z2OdhiBKioGT1IrVoSLEbM7DjlNzVyA7yD RxCw== X-Gm-Message-State: AHYfb5gguVcfc9RNGD5SNOQgRQNwmYximHwamfR0wSZUY+imX9smv8UY pVO5nEIw44k1jL1b+vPAhORoD1OYoQ== X-Received: by 10.36.107.68 with SMTP id v65mr363063itc.129.1502842587206; Tue, 15 Aug 2017 17:16:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Tue, 15 Aug 2017 17:16:26 -0700 (PDT) In-Reply-To: <150281999738.21016.2164260159984776251.idtracker@ietfa.amsl.com> References: <150281999738.21016.2164260159984776251.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Wed, 16 Aug 2017 10:16:26 +1000 Message-ID: To: Warren Kumari Cc: The IESG , Tim Chown , draft-ietf-webpush-encryption@ietf.org, webpush-chairs@ietf.org, "webpush@ietf.org" , Phil Sorber Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Webpush] Warren Kumari's No Objection on draft-ietf-webpush-encryption-08: (with COMMENT) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 00:16:34 -0000 Hi Warren, I resolved your nits here: https://github.com/webpush-wg/webpush-encryption/pull/19 On 16 August 2017 at 03:59, Warren Kumari wrote: > Warren Kumari has entered the following ballot position for > draft-ietf-webpush-encryption-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-webpush-encryption/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Firstly, thanks to Tim Chown for his helpful OpsDir review ( > https://datatracker.ietf.org/doc/review-ietf-webpush-encryption-08-opsdir-lc-chown-2017-08-01/ > ) and for your response. > > I only have nits on this document: > 1: I reviewed this and draft-ietf-webpush-vapid together. This document uses > title case for "User Agent" (and many other terms), while > draft-ietf-webpush-vapid and RFC8030 uses lower-case. Consistency would be nice > here. > > 2: Section 2: > "In addition to the reasons described in [I-D.ietf-webpush-protocol], this > ensures that the authentication secret is not revealed to unauthorized > entities, which can be used to generate push messages that will be accepted by > the User Agent." -- this is ambiguous / confusing. It is unclear which which is > which. I'd suggest rewording to something like "... to unauthorized entities, > which would allow that entities to generate push messages that would be > accepted by the User Agent as valid" (or similar) > > 3: Section 7. Security Considerations > "In particular, any HTTP header fields are not protected by the content > encoding scheme." -- I think you may mean "In particular, no HTTP header fields > are protected ..." (or similar) > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush From nobody Tue Aug 15 17:20:06 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D841323C8 for ; Tue, 15 Aug 2017 17:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSq916PGe7T5 for ; Tue, 15 Aug 2017 17:19:54 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6315213240E for ; Tue, 15 Aug 2017 17:19:51 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id f15so21270687wmg.1 for ; Tue, 15 Aug 2017 17:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eVQ0PHA2lNhwdVD4UyJCgNW6HY1nnocVTl0+vor6SMA=; b=qNr0bLAMU14YqECG/39dzDNsn+ZfgKukjkugbRPaZZGMeGHrqFxEKbMUE/1kTqGzRO 7mWLkJ/0DKwZZnKaHwKxy2/PTaGPVf16xt4FtZhwClncecHMUhPSVsxexFmlngCuMHBS NDPEYFOXuzcz0YNugen8uD6eQg0jV+dHi1LlbN20jkUru9UoG+d2VQVCq9N0Er180tNJ ZO4nqzy8DhAgV5bElLzh+5K7gKNuOPGViDGt1xDJaNrQdFJcls29+slIcCnXEth5Oe3v k3D83IsIGc1LPBRQ9VVmkOcwrjKxf0CItvmzNA+nAwi9xzwjS+AHh1OcDBmfhmQHrNnz axKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eVQ0PHA2lNhwdVD4UyJCgNW6HY1nnocVTl0+vor6SMA=; b=SBEZxKU9F7o5XXzWyT8AvcO8yMrFyaYM/+ImrfcmeHppUrXfPqw35lIxpBu637rdKn tZSaH0VHzRI4r1C0lHm15Ee9ljey3vB3OCU4EFHgfRmmZKPMCF7FPWZB4u5hVYcC2NAq FdxNUL76m2mMP7C6vxSnC85xfGm28zsVXoMOAC8SBiIINwdFvo5y3vAbWzqZPnldKZH6 UhyjjS6lsnzhrntzfwAQtrPVmL8fvjpkfdL7Q83cWp0N1LFhG8rrO1HbwkzBV9ULwXcy XgQV8KKdNiMPUQvZyohAM01yq1aFxsbrbtqtJH9SUS/hEG4isHiWtfAK7mJNcChPwpoY fbJA== X-Gm-Message-State: AHYfb5g03Ba7V7+dY3NC9grhJ3OmY2jD4y8xrzH5PREFBe8Uhs0ScmtK pw+Yv1EAbgu1umL5rVHLoXSH2NdTO/Vp X-Received: by 10.28.113.203 with SMTP id d72mr137291wmi.109.1502842789815; Tue, 15 Aug 2017 17:19:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.135 with HTTP; Tue, 15 Aug 2017 17:19:09 -0700 (PDT) In-Reply-To: References: <150281999738.21016.2164260159984776251.idtracker@ietfa.amsl.com> From: Warren Kumari Date: Tue, 15 Aug 2017 20:19:09 -0400 Message-ID: To: Martin Thomson Cc: The IESG , Tim Chown , draft-ietf-webpush-encryption@ietf.org, webpush-chairs@ietf.org, "webpush@ietf.org" , Phil Sorber Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Webpush] Warren Kumari's No Objection on draft-ietf-webpush-encryption-08: (with COMMENT) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 00:19:57 -0000 Awesome, thank you, LGTM. W On Tue, Aug 15, 2017 at 8:16 PM, Martin Thomson wrote: > Hi Warren, > > I resolved your nits here: > https://github.com/webpush-wg/webpush-encryption/pull/19 > > On 16 August 2017 at 03:59, Warren Kumari wrote: >> Warren Kumari has entered the following ballot position for >> draft-ietf-webpush-encryption-08: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-webpush-encryption/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Firstly, thanks to Tim Chown for his helpful OpsDir review ( >> https://datatracker.ietf.org/doc/review-ietf-webpush-encryption-08-opsdir-lc-chown-2017-08-01/ >> ) and for your response. >> >> I only have nits on this document: >> 1: I reviewed this and draft-ietf-webpush-vapid together. This document uses >> title case for "User Agent" (and many other terms), while >> draft-ietf-webpush-vapid and RFC8030 uses lower-case. Consistency would be nice >> here. >> >> 2: Section 2: >> "In addition to the reasons described in [I-D.ietf-webpush-protocol], this >> ensures that the authentication secret is not revealed to unauthorized >> entities, which can be used to generate push messages that will be accepted by >> the User Agent." -- this is ambiguous / confusing. It is unclear which which is >> which. I'd suggest rewording to something like "... to unauthorized entities, >> which would allow that entities to generate push messages that would be >> accepted by the User Agent as valid" (or similar) >> >> 3: Section 7. Security Considerations >> "In particular, any HTTP header fields are not protected by the content >> encoding scheme." -- I think you may mean "In particular, no HTTP header fields >> are protected ..." (or similar) >> >> >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Aug 15 17:22:31 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694FA1323B5; Tue, 15 Aug 2017 17:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvaEu3eWphdY; Tue, 15 Aug 2017 17:22:22 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7F31323B0; Tue, 15 Aug 2017 17:22:22 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id j32so8460944iod.0; Tue, 15 Aug 2017 17:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w0G4BjWJC4egOBLFNXfhHZBMC0clObs7ecamOv1BcpQ=; b=eaMfnkvvFS2wq4MpSBR3e8wXgbEZw+hQh4+QkXAqrTUMJWF7ReIB0Qg6zcxfmqwqgc oh+gL2o0xp/5V8es6k+/9YTiOthyz595eZDrOTavSqj22ZstChipYWLoe5F0FwHtVO8+ j16LzvnfxAo4I235q8gWlq0BemDZha5ZxJSzFiPP3PvksRUrVTy02jyZrqNkiBpOVXn6 6b4/3Mn2Z3SkNg+sH61ikQoiZ7Np18W4QKsZmReAcK+JGtndwiMYM2pe+EAUVvFx0mlf RvXpYBs38iZRtLhIXmbh7PCHPoom1DV3QHcgYdr3q9DTu7c8A6eHVx1reOcy0zkDfyyg az9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=w0G4BjWJC4egOBLFNXfhHZBMC0clObs7ecamOv1BcpQ=; b=VUFBL6w9an68C+hPhU3e1Dm9ZwBHYTVNxOzAOa++AYqI8OYXc+c4lRgsqoGSilOlWa bfqJVvWw9LbUhRTrQrgyp8WWccfNhgQerYnXJ88dITUSxvarPCWSi5hu9uumJW9F56F4 IuR4UPC/qOWnqWcxXNAC+3bq20YsSTbj69f7ZkODk++8yGlV/kOFfuJatdhoPZ2AEI1Z gI5XroimTKrV5h+5utBpcc5spgmWGRkagR8/EDMPC/J21W2SzRPzIwzfaRVvqOBraESR VeeJintHkMgPbXGAm8tJ4T2hKjr1QXCPCpmHlklTCrkQEZhmYjXYfuN5/L0oPexozeKE Q+Wg== X-Gm-Message-State: AHYfb5gi52WBhwGTOxcEBdoTC89szoLWaF3bnxVvROgbct1dvm0ogfgr /zuDmZ/DAkYm2s8DfiaNv5z25TUbyg== X-Received: by 10.107.137.30 with SMTP id l30mr26193145iod.279.1502842941929; Tue, 15 Aug 2017 17:22:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Tue, 15 Aug 2017 17:22:21 -0700 (PDT) In-Reply-To: <150281762174.21115.10126123891463241768.idtracker@ietfa.amsl.com> References: <150281762174.21115.10126123891463241768.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Wed, 16 Aug 2017 10:22:21 +1000 Message-ID: To: Warren Kumari Cc: The IESG , draft-ietf-webpush-vapid , Phil Sorber , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Webpush] Warren Kumari's No Objection on draft-ietf-webpush-vapid-03: (with COMMENT) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 00:22:24 -0000 Capitalization here was fine, but I trimmed the "currently". Thanks. On 16 August 2017 at 03:20, Warren Kumari wrote: > Warren Kumari has entered the following ballot position for > draft-ietf-webpush-vapid-03: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-webpush-vapid/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > *Very* minor nits: > > 1: I'm reviewing both this document and draft-ietf-webpush-encryption (both of > which have Martin Thomson as an author) -- these use different capitalizations > for many terms, for example "user agent" vs "User Agent" -- this document > references RFC8030, which has these lower-case, and so I suspect that it is > draft-ietf-webpush-encryption which should change, but I figured I'm mention it > here as well. > > 2: Section 7. Acknowledgements > "This document would have been much worse than it currently is if not for the > contributions ..." Once published as an RFC, it is cast in stone. I support > your the above, but think you should remove "currently", so perhaps: "This > document would have been much worse if not for the contributions ..." > > Again, these are tiny nits, I don't have enough knowledge of the topic to make > more useful comments :-P > > From nobody Tue Aug 15 17:22:48 2017 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE181323C9; Tue, 15 Aug 2017 17:22:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-webpush-encryption@ietf.org, Phil Sorber , webpush-chairs@ietf.org, sorber@apache.org, webpush@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150284295232.12589.16313686807738978537.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 17:22:32 -0700 Archived-At: Subject: [Webpush] Eric Rescorla's No Objection on draft-ietf-webpush-encryption-08: (with COMMENT) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 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, 16 Aug 2017 00:22:32 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-webpush-encryption-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-webpush-encryption/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Moving to No Objection because my DISCUSS is fixed in: https://github.com/webpush-wg/webpush-encryption/commit/645a04b3b86ffe10322134e27a3d3c5eb5a8b06b Note, I think technically only the UA needs to do point verification if the app generates a fresh key as implied by S 2. It would also be nice to have a cite to how to do the point verification. This text can be stolen from TLS 1.3. S 1. This document describes how messages sent using this protocol can be secured against inspection, modification and falsification by a Push Service. "forgery" is more customary than falsification. S 3.3. key_info = "WebPush: info" || 0x00 || ua_public || as_public You should make clear that the string is not null-terminated. Ugh, I know. S 3.4. You should clearly separate which pieces are defined in this document and which are defined in the HTTP encryption document. From nobody Tue Aug 15 17:47:42 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7196132409; Tue, 15 Aug 2017 17:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKWQLQx59LH9; Tue, 15 Aug 2017 17:47:38 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9659113226B; Tue, 15 Aug 2017 17:47:38 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id g71so8526667ioe.5; Tue, 15 Aug 2017 17:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9rB0Yd0Bcm98nnxtVpDjJN0YHR1N9n4XRAZDkE0+tFI=; b=S/OVX6E8U4YsXj/xuMFacfnYEScKeC5x2Y+dM8JL+ZxoOsQeLHArxC1ovBid29Qh5U FWZf+ro7OnriKuOPFs3FecU1+lC/fx2bl4nzSBMhd3CeoSwP7qwGZ7uVj3FkJMCi+rJn rQsJak5KlRU/J4mpfpbahZfdkk67she+3pRSkLqAP9dUDXATCUvb/O/59ss7Prc041Fw T39khVx4suoYM8Kpvd+wLcBz/O+PR5oGSNzW7yF90cH+hkpKJRLTI/+lZVyJyooXKyZm l8XtZUYahDgOGc/66J6gv1Ofo6fFlGBUK0Ci/Rjexzq9kUjzstUiGE9iw+/GOoYC9LHy ndsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9rB0Yd0Bcm98nnxtVpDjJN0YHR1N9n4XRAZDkE0+tFI=; b=XqDJxyneTCSUWPbD4/e3JLqsvhDVJfkT9YsDxTTJH+BCKFhbqTYp4mkZ+y+pq62MYJ uG1nfua08g9E4aK0RMldLXBvEDyWXaOrfCKT8zHHZ4UEDaDsnn+3D2bX60sUTS9Q4woe 5MDZasW3vBXeUdPGChseySY72VR0QvzZE259x6bVs7vMwRIKgsqNPRdoq5a8uGgwGcZL LZxKEeGeSQ1tNKMPQ5gMudZV0ammgijvvwFazsP5ZOq2TuQFyZKRMdcCO+C3O5IWyeyp JvRI4nfKmBvwxHiNfG6TpR+1IxLGi4KzrVXfaGt9ZfJ6V+qXrWVS96gx9paQK3unQkkx R5FA== X-Gm-Message-State: AIVw111vei0qg4GmcCdbI86RGflyxRIwrvu/2fyGKDk/Trha5ElVJRLm ec4LgQiDPtrguJsdEgy2Uu+BgIasJg== X-Received: by 10.107.134.196 with SMTP id q65mr23493393ioi.193.1502844457821; Tue, 15 Aug 2017 17:47:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Tue, 15 Aug 2017 17:47:37 -0700 (PDT) In-Reply-To: <150284295232.12589.16313686807738978537.idtracker@ietfa.amsl.com> References: <150284295232.12589.16313686807738978537.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Wed, 16 Aug 2017 10:47:37 +1000 Message-ID: To: Eric Rescorla Cc: The IESG , draft-ietf-webpush-encryption@ietf.org, Phil Sorber , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Webpush] Eric Rescorla's No Objection on draft-ietf-webpush-encryption-08: (with COMMENT) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 00:47:41 -0000 Thanks ekr, your PR is here: https://github.com/webpush-wg/webpush-encryption/pull/20 I ripped off your text. On 16 August 2017 at 10:22, Eric Rescorla wrote: > Eric Rescorla has entered the following ballot position for > draft-ietf-webpush-encryption-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-webpush-encryption/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Moving to No Objection because my DISCUSS is fixed in: > https://github.com/webpush-wg/webpush-encryption/commit/645a04b3b86ffe10322134e27a3d3c5eb5a8b06b > > Note, I think technically only the UA needs to do point verification if the app > generates a fresh key as implied by S 2. It would also be nice to have a cite > to how to do the point verification. This text can be stolen from TLS 1.3. > > S 1. > This document describes how messages sent using this protocol can be > secured against inspection, modification and falsification by a Push > Service. > > "forgery" is more customary than falsification. > > S 3.3. > > key_info = "WebPush: info" || 0x00 || ua_public || as_public > > You should make clear that the string is not null-terminated. Ugh, I know. > > S 3.4. > You should clearly separate which pieces are defined in this document > and which are defined in the HTTP encryption document. > > From nobody Tue Aug 15 18:11:12 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727FF132076; Tue, 15 Aug 2017 18:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkMkf3E-B3Bh; Tue, 15 Aug 2017 18:11:04 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0661321F0; Tue, 15 Aug 2017 18:11:04 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id g71so8635250ioe.5; Tue, 15 Aug 2017 18:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0opyc7/E762GRZSiARV/i6g4GLy0HVSPoHOBdM/7ejg=; b=NzuWJt+FuHD49Km2r2TNz+fxhH5H3KTmhsuZWMoai0sFOj6WQh29H2CVFooT+JBALn d9ZD5hxDtzHGZa58shdlwwDc08S9+OHHL9ZIAExEdLU/0+LVP9lRFSKg4WuhkpwMQHIl DcG9IwFByvj4CkJmpwSMb5QOr+cPT5v2aBZ2acNN2Lq95or8jcxt5YSsy1k+QqSVMQOB EBy2oVwa1YLtuBJZ/z6Vx8Wu81w/j9xHEARTf7ZOkFbu/0lZ8/KWfPV4IXvh9hZYZ1Wc Kmp0XugtZS+89MVd5/VrJs4qOeRiOHKsB6p4J6cIdGDAEA8kwhNRrzpAWcOxC6DFKB9D +OQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0opyc7/E762GRZSiARV/i6g4GLy0HVSPoHOBdM/7ejg=; b=e8Wxyu+PU+ObgV4CwdwFJdyhhh5ttH501b2EfWkc2GD0m1Hdb6Rf5SHK5Ubqkv7mpX /oNZLioV8lQcjEqslxIcGZmTiTlvNKec39EHeMFYPKBAww8qaMMWTBcQQXYHo3gsmJtd avlL1duUrvia9bIba3QNCj92VPtYltIBjx/OGSW/KwsE/DXjNIqcqZEuFF6eRQFtWH+j lw1ze6QKIvSf66aKiwgcK+JZ21GQVB0XB2Hk5j6Y4FYTfyaVGybD80AIla6rLVV7Gqm4 5suqTXoIh2YJ7RcztULVz2MmWul324eZV5gqP7WtoVLd7hB/D+naRtaYNqKvgEsMZzGD xqDw== X-Gm-Message-State: AHYfb5iQ2vEyPS339c94X8ZjHWr+MdhTQJj8b52xkKgcDJaU+/GxEQnd F1nKdn/6e9tTrS0n4TaQm2ZnTQNXRw== X-Received: by 10.107.134.196 with SMTP id q65mr24601ioi.193.1502845863828; Tue, 15 Aug 2017 18:11:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Tue, 15 Aug 2017 18:11:03 -0700 (PDT) In-Reply-To: <150282302424.20984.16954614287039839165.idtracker@ietfa.amsl.com> References: <150282302424.20984.16954614287039839165.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Wed, 16 Aug 2017 11:11:03 +1000 Message-ID: To: Kathleen Moriarty Cc: The IESG , draft-ietf-webpush-vapid , Phil Sorber , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Webpush] Kathleen Moriarty's No Objection on draft-ietf-webpush-vapid-03: (with COMMENT) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 01:11:06 -0000 On 16 August 2017 at 04:50, Kathleen Moriarty wrote: > In section 3, it seems that you are just signing the JWK and that seems fine > from the text and the purpose listed - origin server authentication. > > Then in section 3.2, there's a reference to I-D.ietf-webpush-encryption saying, > "An application server MUST select a different > private key for the key exchange". This makes me think that encryption is > used as well, but I think it would be helpful to see the point made more > clear here or in the security considerations section. Is confidentiality > provided/required or just integrity for this draft? There are two separate mechanisms. -encryption sends a message to the user agent. That message has confidentiality and integrity protection - the push service can't see or modify that message. In the envelope of that message, we have this JWT. The confidentiality/integrity protection for that is HTTPS. Confidentiality is required to prevent theft of the token, as stated in the security considerations. What I now realize is that I didn't actually reiterate the requirement for HTTPS from 8030. https://github.com/webpush-wg/webpush-vapid/pull/41 The text you cite is included specifically to maybe prevent someone from incorrectly using the same key for signing (in -vapid) and encryption (in -encryption). Unfortunately, this specific type of misuse is possible in a lot of codebases and does happen. From nobody Tue Aug 15 18:24:27 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2615B13238E; Tue, 15 Aug 2017 18:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCdtL08j-K2J; Tue, 15 Aug 2017 18:24:17 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D718F120713; Tue, 15 Aug 2017 18:24:16 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id 77so11776829itj.1; Tue, 15 Aug 2017 18:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+NYGfQ0yWGYQ/d/2HLBeuqywQmbru3Rjf59Gxj+n/kQ=; b=HnYvgWgQ/P2V9GUK7RUY23TTyQPnuNfp2ZJSpgxBOL4FLXMa0zGMy1asmjlsw623qP TEgNWH0BVtlV0Mc+ogecsIthKzZAuDzmJ2VCP3uegkXWN/n/tGxwebNx6dn4272nLIXY yEzJtHr2PSL3JU9GrIUugCn/oiAYHhnRoKHQlLKcurq9Zbv1BG4McmRdGozTdRpot0yz f9tfosHM6UA3ysJckgBIS4H9FMVsj11knaFUeVvvq4LpwYRx5SUdmkSjzix5tOhOvQ8/ TYG7eyO9TXiiM9cBhYQ5+nToONNk/m8XXoKYmakwlXtww7mi5CKwVQi2GvJ4zwoS1lA5 uIww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+NYGfQ0yWGYQ/d/2HLBeuqywQmbru3Rjf59Gxj+n/kQ=; b=sXliwKN9mbaCVv0XQOiP8t8IpFMkO29vtHbycpllNFg2KaDxIn9G4ZhsTblUEeo+df 3x8VNZ1grXXljrwsBa+ASXqbCKEoAQcBah9XjVIv8zQNg3daJVcHYLedln3eBs+3ULGy BBcNeZZDvj615bGVeLGJfM434eC3Nod8JubsqCz40jb7eAJTSs5oULR/XN3oDQG9z2BH P2dUCUA/vHkbWo4iRSfzzzfnbEPm/eyEqpTkYrfP3TAHtzSgMb7eYfCS2Kf7hbUSML31 LS0DHNuGEcU22ZqKemN8mvgMinOSQHbgs2NtzP+pOxRdJZw42S5l804dY6nkH36asUjH BEBg== X-Gm-Message-State: AHYfb5icIBfTX4rdYIxiVGFXWOCVSrr9U95zpOBsmNgifBSaydyGwbEI SLDrAKC4PnWQ7sM3zISXJxPTHNttkQ== X-Received: by 10.36.120.16 with SMTP id p16mr404989itc.151.1502846656156; Tue, 15 Aug 2017 18:24:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Tue, 15 Aug 2017 18:24:15 -0700 (PDT) In-Reply-To: References: <150281715482.21106.3346502830630897599.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Wed, 16 Aug 2017 11:24:15 +1000 Message-ID: To: Costin Manolache Cc: Alexey Melnikov , The IESG , draft-ietf-webpush-vapid , webpush-chairs@ietf.org, "webpush@ietf.org" , Phil Sorber Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Webpush] Alexey Melnikov's No Objection on draft-ietf-webpush-vapid-03: (with COMMENT) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 01:24:19 -0000 We have previously discussed the problem of discovering whether a server supports a particular authentication scheme. On the API side, we didn't resolve to make a change that would add a mechanism similar to what we use for content coding (see https://github.com/w3c/push-api/pull/262 for that discussion). This is approximately what Costin is talking about here. What has changed since that time is that I have learned that some push services *require* authentication. For that reason, though it adds delays to sending when authentication fails, I'm inclined to add a challenge. It would be empty, but it would allow a server to insist on authentication in a transparent way. It IS easy to define: https://github.com/webpush-wg/webpush-vapid/pull/42 On 16 August 2017 at 03:56, Costin Manolache wrote: > IMHO out-of-band discovery may be sufficient - in webpush it is implicit or > can be part of the > subscribe handshake. If VAPID is used with an API the supported auth may be > part of the API > schema/discovery. > > I think in future it may be valuable to add an optional certificate - either > as an extra header or parameter - > to allow authentication without a database RT. In such mode a mechanism to > discover supported > roots may be needed - however it can also be done out-of-band. > > B > > Costin > > > On Tue, Aug 15, 2017 at 10:12 AM, Alexey Melnikov > wrote: >> >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-webpush-vapid-03: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-webpush-vapid/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I have cleared my DISCUSS based on changes in git. >> >> I am looking forward to continuing discussion about advertising support >> for the >> "vapid" authentication scheme in WWW-Authenticate: >> >> In Section 3, 3rd para: >> >> This authentication scheme does not require a challenge. Clients are >> able to generate the Authorization header field without any >> additional information from a server. Therefore, a challenge for >> this authentication scheme MUST NOT be sent in a WWW-Authenticate >> header field. >> >> Does this mean that there is no way to discover whether a particular >> server >> supports "vapid" HTTP authentication scheme? >> >> >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush > > From nobody Tue Aug 15 18:35:45 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1AA71323A3; Tue, 15 Aug 2017 18:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UNq7tor-gpS; Tue, 15 Aug 2017 18:35:40 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8775C120713; Tue, 15 Aug 2017 18:35:40 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id l82so14564159ywc.2; Tue, 15 Aug 2017 18:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hT/M2LER/NKsNxqjJZ7r4D0IEF9OO0YWJ/KFSdUxCK0=; b=mxPRwrNSCVwZ6EbUsNTT79Js9wXecrgkxd6VH3ds58OOSi/Y8AQSNRrQoYk3WyqQBl hXrpPgud8A2YtC7hL7u586ncpHbz3zwATRcmXZ7+zM+Jl+Fb8fQACwg07o0+5Deerw0a 0RPyrXn+4etUw/oVMfH7rrrtCFS4yI9JfJK+l+5cCohOmi0XpGhQG+obkwiojpSbCRBO qGqbja3IJg/T3rskintshXFWkILWc9TzQsYWlqyI1pqRnClEvKcttkc8+DIOAdsSQnAx XYE+Xxvtl+s47Lvpz0yN8HUSRFCvjb84cgX0uhWn13+3CDBKCkYwTxfk9avR/8eEVlFO iuEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hT/M2LER/NKsNxqjJZ7r4D0IEF9OO0YWJ/KFSdUxCK0=; b=OP88QLN4REyFaN2Z1WluQRg/Gvw56oqPI+nT7URFX50Da5pPQjoltprDUWWgh7qEIz zvghH46U+wfGAZ5leO009DpWGW70Gu5edGhgGzV90s6GJckxByax9IQzw4/3fmz5KhVt O3hnzz4FIJ4YwBM6lVQNeR4fhS7BgsVQzknSpbKJwgj3Vudb5YpXG9ZaUWzZ5YmSlLnF 86etRQXfZFUoZ7lmG/9l6ueRBv7J9xlVMeoNpPJUO5SKuKZ0war5D9Tb3zc2U+UjF4Y5 WyzFihfXaNfuOkQ7gxEyCVYft25kXX5jnBZgKreP/LeiBy/6LXyWu6FM9aH9dpELCPjj NjHA== X-Gm-Message-State: AHYfb5jNBXYnIST0kJNHLex1uuInr44ocLRl7QVSRpfdqOB//vKlXVn5 H5YzfDCmBJM14pJS7JpXbs2WHYzNsQ== X-Received: by 10.37.52.201 with SMTP id b192mr44771yba.293.1502847339646; Tue, 15 Aug 2017 18:35:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.40.194 with HTTP; Tue, 15 Aug 2017 18:35:39 -0700 (PDT) In-Reply-To: References: <150281372252.21061.13568867134437858167.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Tue, 15 Aug 2017 20:35:39 -0500 Message-ID: To: Martin Thomson Cc: The IESG , draft-ietf-webpush-encryption@ietf.org, Phil Sorber , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Type: multipart/alternative; boundary="001a1147cb6cd4d9170556d4e9b8" Archived-At: Subject: Re: [Webpush] Spencer Dawkins' Yes on draft-ietf-webpush-encryption-08: (with COMMENT) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 01:35:43 -0000 --001a1147cb6cd4d9170556d4e9b8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Martin, Top posting to say this looks like a plan. Thanks! Spencer On Tue, Aug 15, 2017 at 7:03 PM, Martin Thomson wrote: > On 16 August 2017 at 02:15, Spencer Dawkins > wrote: > > I found =E2=80=9Cfor efficiency reasons=E2=80=9D in this text > > > > For efficiency reasons, multiple users of Web Push often share a > > central agent that aggregates push functionality. > > > > To be so broad that I wasn=E2=80=99t sure what you were telling the rea= der. Are > there > > any specific efficiencies that you could call out, so that we=E2=80=99d= better > > understand why central agents are used? And if that=E2=80=99s already w= ritten > down > > someplace, adding a pointer would be even better. > > It's engineering efficiency more than anything else. On mobile > platforms, this is the platform; on browsers, the browser. If I > remove the "for efficiency reasons" clause, I don't think we lose > anything. > > > I=E2=80=99m curious about algorithm agility, but I=E2=80=99m not the pe= rson to ask that > > question ... > > It's a common question. Common enough that I'll add some text and > avoid future occurrences. > > We have deployment experience with this already. We deployed an > earlier version, then had to change it a few times. So we know how to > do this. The User Agent tells the application what content codings it > likes. The W3C spec has a supportedContentEncodings parameter on the > PushManager interface that does this > (https://w3c.github.io/push-api/#pushmanager-interface). > > For you: > https://github.com/webpush-wg/webpush-encryption/pull/18 > --001a1147cb6cd4d9170556d4e9b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Martin,=C2=A0

Top posting to say th= is looks like a plan. Thanks!

Spencer
<= div class=3D"gmail_extra">
On Tue, Aug 15, 20= 17 at 7:03 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 16 August 2017 at 02:15, Sp= encer Dawkins
<spenc= erdawkins.ietf@gmail.com> wrote:
> I found =E2=80=9Cfor efficiency reasons=E2=80=9D in this text
>
>=C2=A0 =C2=A0For efficiency reasons, multiple users of Web Push often s= hare a
>=C2=A0 =C2=A0 central agent that aggregates push functionality.
>
> To be so broad that I wasn=E2=80=99t sure what you were telling the re= ader. Are there
> any specific efficiencies that you could call out, so that we=E2=80=99= d better
> understand why central agents are used? And if that=E2=80=99s already = written down
> someplace, adding a pointer would be even better.

It's engineering efficiency more than anything else.=C2=A0 On mo= bile
platforms, this is the platform; on browsers, the browser.=C2=A0 If I
remove the "for efficiency reasons" clause, I don't think we = lose
anything.

> I=E2=80=99m curious about algorithm agility, but I=E2=80=99m not the p= erson to ask that
> question ...

It's a common question.=C2=A0 Common enough that I'll add so= me text and
avoid future occurrences.

We have deployment experience with this already.=C2=A0 We deployed an
earlier version, then had to change it a few times.=C2=A0 So we know how to=
do this.=C2=A0 The User Agent tells the application what content codings it=
likes.=C2=A0 The W3C spec has a supportedContentEncodings parameter on the<= br> PushManager interface that does this
(https://w3c.github.io/push-api/#pushmanag= er-interface).

For you:
=C2=A0 https://github.com/webpush-wg/we= bpush-encryption/pull/18

--001a1147cb6cd4d9170556d4e9b8-- From nobody Tue Aug 15 18:56:45 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4329F132424; Tue, 15 Aug 2017 18:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSOq86ayIyIL; Tue, 15 Aug 2017 18:56:41 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 211BA126B7E; Tue, 15 Aug 2017 18:56:41 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id o9so8970316iod.1; Tue, 15 Aug 2017 18:56:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZQ5OTTf9UM7geHmu2IqhlbJ78V4kvrLPIAMFzjExPU0=; b=KdGyBjV2U8PNyJaIq/A3iha4LdtY5naqfKw0fsLlF04h7bXW5LmW+1s5F4rKcUU7g1 Q5Uagu02fGMBti7lyZWUBvX8nim6WXmpTz4lD7jvdxHF9mL24sCwaKJ8iNgS011jB+9f i9J6uhHKyMchQnKKUKHFDTU3vgJ8kayhQLqAKqKEN7lu50rcTNC8K8cWK7K/IfXDPXhB v5OXsIMx4PS9Zli2cHKuZKYPVG6w4xC/uopF8L2A+Znk5vQYnJlEVNkUBNKlDpwD0z+N 3S3MKfXmepRrGxqhhZGm9F3PTfr4d71WFnnD6xqPOyYhh0wNLX23c1piP+/KMgcsgkqW uICw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZQ5OTTf9UM7geHmu2IqhlbJ78V4kvrLPIAMFzjExPU0=; b=mjKTxsXNqw9DrNqZhoxbABbo/LKYtlVsesSMrgCG6AE6yXfYZS/d6kvygyZN2eOfIA WqvMeiQ7i+vEQAV+f4NexNsMaRsT2RM+KwWupjFwSWc3r5iMesT5IsHrAHzxn/G8OvUf M6dwKy7hjuyQTrpODB0oQIQfLWomGGlLe4S8WLgLPUXtH52kudQiEJom95gqF2RXJt6i 30Ds+yO7qPHJBca71buqObsskLr5sJOBMSM+whXhvpNyrIv6Q+K5Nm5QG8+QdJ8zP7a0 y4826GK781bbmdpzUU+una6/m8I//g6KG2Waxa8K7xHnG1QTFSYpwiZhbOsbfVJ1Arcj AZzQ== X-Gm-Message-State: AHYfb5hOrxUdlKqJW+ka1EmbgROPDL+WJaYer+r0vKwRnqSNyM/k0Dg6 5eLYaw2M6ECl7qNgF/asc/9/MGm6LQ== X-Received: by 10.107.46.155 with SMTP id u27mr101757iou.107.1502848600386; Tue, 15 Aug 2017 18:56:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Tue, 15 Aug 2017 18:56:39 -0700 (PDT) In-Reply-To: <150284054989.12518.11340069078773708886.idtracker@ietfa.amsl.com> References: <150284054989.12518.11340069078773708886.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Wed, 16 Aug 2017 11:56:39 +1000 Message-ID: To: Eric Rescorla Cc: The IESG , draft-ietf-webpush-vapid , Phil Sorber , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Webpush] Eric Rescorla's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 01:56:43 -0000 On 16 August 2017 at 09:42, Eric Rescorla wrote: > Ultimately, this is a WG decision, but given that there are designs > with much better security properties, I'd like to know that the WG > considered and rejected this kind of design alternative before > we advance the weaker design. We discussed the implications of the bearer token design and concluded that this was acceptable. We didn't discuss additionally signing messages in this way. Another alternative is to describe how token binding could be used to prevent token theft. One complaint I get about webpush is the amount of overhead crypto adds to sending messages. Mostly from a complexity standpoint. It's a real implementation barrier. We've forced people to jump through a lot of hoops and that has made them pretty annoyed. Deploying this as a required extension could be additionally annoying, not to mention incompatible with the existing deployed code. What is nice about the specific design you describe (and my flippant tokbind suggestion as well coincidentally) is that it can be incrementally added to this scheme without a complete overhaul, probably without even changing the scheme name, suggestions below notwithstanding. It could be an optional increment, if we could decide that the push service doesn't require this additional protection and it was primarily for the benefit of application servers. Yes, there are benefits that accrue to push services and user agents alike, but we might decide that they don't gain any certainty about these benefits. That suggests a second, though less satisfying, path: a new draft describing the enhancement. I did have a stab at fixing your nits here: https://github.com/webpush-wg/webpush-vapid/pull/43 > S 1. > Additionally, this design also relies on endpoint secrecy as any > application server in possession of the endpoint is able to send > messages, albeit without payloads. In situations where usage of a > subscription can be limited to a single application server, the > ability to associate a subscription with the application server could > reduce the impact of a data leak. > > I don't understand this text. I realize that this is not at all clear. How about: Additionally, the design of RFC 8030 relies considerably on the secrecy of push subscription URIs. Any application server in possession of this URI is able to send messages to the user agent. If use of a subscription could be limited to a single application server, this would reduce the impact of the push subscription URI being learned by an unauthorized party. > S 2. > This JWT is included in an Authorization header field, using an auth- > scheme of "vapid". A push service MAY reject a request with a 403 > (Forbidden) status code [RFC7235] if the JWT signature or its claims > are invalid. > > Given that "vapid" is tied to "P-256" it seems like it would be better > to rename this "vapid-p256" That's just a cosmetic change. If we change the scheme in an incompatible way based on the comment above, then a name change might come with that, but your design might be able to use the same name. > S 4.2. > When a push subscription has been associated with an application > server, the request for push message delivery MUST include proof of > possession for the associated private key that was used when creating > the push subscription. > > This really isn't a proof of possession, as the Security Considerations > makes clear. Reworded in a couple of places to make the weaker claim. > S 5. > You should call out that the email address is just a bare assertion. See PR. From nobody Tue Aug 15 19:05:05 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9106132459 for ; Tue, 15 Aug 2017 19:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEWkbbB5t2p5 for ; Tue, 15 Aug 2017 19:05:01 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 263CF132430 for ; Tue, 15 Aug 2017 19:05:01 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id l82so14825991ywc.2 for ; Tue, 15 Aug 2017 19:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6tHxuva10CGAnjeesxz7Fewi9edwaem8WKACJUi/HCE=; b=l9Yr2riK9H8prq6gjgkO1p2zp1opoZajrEf+mbSXJcHOtoe9Z37aZ7dM/PAk/KWMSv 2OpejXdLbXEGJI+Wpkw/OGDnMaoOr7zwKxfCIVP0SlSgV5OjsZCutfwDu91I3DL223ri SnpY81MCgh8XZeLHxOuXE71hJS0vzMpFRSmgRc+f1QtzciLBHzSNLVwf3Twna/Lpelrp Y/WkkIfjdgys486Th87TpCMa/qGrPnGEb4lK0CNl9LC7koyHZh5d7bGRiFhoHFXGPki+ 92Olf+Om4JZlmO7BW7VmEJQH5hemzR+UsHlLnTkWup7KmIYo5IrnL2UE/JjulTA9LtU4 QgNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6tHxuva10CGAnjeesxz7Fewi9edwaem8WKACJUi/HCE=; b=f/Asz7cIdnuyBODynydXSjOXE9lUbFaE8jbG4c5wdVKsrlV8iug7EPzjgBfFu/Mc8F yN3PVkNaqMvT26WS90IrwiIiqS9dbBpozHAyEMdvftp7a+NF0f0gD4BbohynkAsuCzaC Q/8P1y83MridMb1/dMoUbb6Fmxju9rcVDK2MdEEl+R/h/0Fs78Qu58Bns7rukwX/teRR dfEyNkU7ONidgTdOr59KkQ5rEjWEqNFpqIZsdStelP6pTBcYUjdgRFtr//L0SLnQag5Z gLOZttz2CRDeJsh2HlM+dtlrC5qAqZ7JRK76WQZZP2dAFB9YsV9vGOtwtlIHs5NzcF90 15vw== X-Gm-Message-State: AHYfb5i/YLzKvyjc2Co1g8XVSmCtxRGEeumM6xkDcSdGiKjFPckOgbw3 Sh5Xblj7FLWu4jaDjD9ux/Q1nHoQrEfV X-Received: by 10.37.45.74 with SMTP id s10mr130464ybe.204.1502849100262; Tue, 15 Aug 2017 19:05:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Tue, 15 Aug 2017 19:04:19 -0700 (PDT) In-Reply-To: References: <150284054989.12518.11340069078773708886.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Tue, 15 Aug 2017 19:04:19 -0700 Message-ID: To: Martin Thomson Cc: The IESG , draft-ietf-webpush-vapid , Phil Sorber , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Type: multipart/alternative; boundary="f4030435c9f0c5f1d10556d55275" Archived-At: Subject: Re: [Webpush] Eric Rescorla's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 02:05:04 -0000 --f4030435c9f0c5f1d10556d55275 Content-Type: text/plain; charset="UTF-8" On Tue, Aug 15, 2017 at 6:56 PM, Martin Thomson wrote: > On 16 August 2017 at 09:42, Eric Rescorla wrote: > > Ultimately, this is a WG decision, but given that there are designs > > with much better security properties, I'd like to know that the WG > > considered and rejected this kind of design alternative before > > we advance the weaker design. > > We discussed the implications of the bearer token design and concluded > that this was acceptable. That's a much easier discussion to have without an alternative. > We didn't discuss additionally signing > messages in this way. Another alternative is to describe how token > binding could be used to prevent token theft. > > One complaint I get about webpush is the amount of overhead crypto > adds to sending messages. Mostly from a complexity standpoint. It's > a real implementation barrier. We've forced people to jump through a > lot of hoops and that has made them pretty annoyed. Deploying this as > a required extension could be additionally annoying, not to mention > incompatible with the existing deployed code. > The flippant thing to say would be that I-Ds come with a big disclaimer for exactly this reason. More seriously, the future is bigger than the past and given that (as you observe) the vapid token is used to identify what you support, it seems like deploying the new thing would be straightforward. I'm not terribly sympathetic to the complexity point: this is a very modest amount of crypto. > What is nice about the specific design you describe (and my flippant > tokbind suggestion as well coincidentally) is that it can be > incrementally added to this scheme without a complete overhaul, > probably without even changing the scheme name, suggestions below > notwithstanding. > > It could be an optional increment, if we could decide that the push > service doesn't require this additional protection and it was > primarily for the benefit of application servers. Yes, there are > benefits that accrue to push services and user agents alike, but we > might decide that they don't gain any certainty about these benefits. > That suggests a second, though less satisfying, path: a new draft > describing the enhancement. I agree that that's possible, but it's kind of unsatisfying to be publishing a draft with this kind of known deficiency. Maybe the chairs or ART ADs would like to weigh in here? I did have a stab at fixing your nits here: > https://github.com/webpush-wg/webpush-vapid/pull/43 > > > S 1. > > Additionally, this design also relies on endpoint secrecy as any > > application server in possession of the endpoint is able to send > > messages, albeit without payloads. In situations where usage of a > > subscription can be limited to a single application server, the > > ability to associate a subscription with the application server could > > reduce the impact of a data leak. > > > > I don't understand this text. > > I realize that this is not at all clear. How about: > > Additionally, the design of RFC 8030 relies considerably on the secrecy of > push > subscription URIs. Any application server in possession of this URI is > able to > send messages to the user agent. If use of a subscription could be > limited to > a single application server, this would reduce the impact of the push > subscription URI being learned by an unauthorized party. > > > S 2. > > This JWT is included in an Authorization header field, using an auth- > > scheme of "vapid". A push service MAY reject a request with a 403 > > (Forbidden) status code [RFC7235] if the JWT signature or its claims > > are invalid. > > > > Given that "vapid" is tied to "P-256" it seems like it would be better > > to rename this "vapid-p256" > > That's just a cosmetic change. If we change the scheme in an > incompatible way based on the comment above, then a name change might > come with that, but your design might be able to use the same name. > I agree that it is largely a cosmetic change, which is why it's in the COMMENT section. With that said, I don't think it's purely a cosmetic change: given that we know that there is diversity along this dimension, why are we baking one identifier into the name > S 5. > > You should call out that the email address is just a bare assertion. > > See PR. > --f4030435c9f0c5f1d10556d55275 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Aug 15, 2017 at 6:56 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 16 August 2017 at 09:42, Eric Rescorla <ekr@rtfm.com> wrote:
> Ultimately, this is a WG decision, but given that there are designs > with much better security properties, I'd like to know that the WG=
> considered and rejected this kind of design alternative before
> we advance the weaker design.

We discussed the implications of the bearer token design and conclud= ed
that this was acceptable.=C2=A0

That's= a much easier discussion to have without an alternative.

=C2=A0
We didn't discuss ad= ditionally signing
messages in this way.=C2=A0 Another alternative is to describe how token binding could be used to prevent token theft.

One complaint I get about webpush is the amount of overhead crypto
adds to sending messages.=C2=A0 Mostly from a complexity standpoint.=C2=A0 = It's
a real implementation barrier.=C2=A0 We've forced people to jump throug= h a
lot of hoops and that has made them pretty annoyed.=C2=A0 Deploying this as=
a required extension could be additionally annoying, not to mention
incompatible with the existing deployed code.

The flippant thing to say would be that I-Ds come with a big disclai= mer
for exactly this reason. More seriously, the future is bigger= than the past
and given that (as you observe) the vapid token is= used to identify
what you support, it seems like deploying the n= ew thing would be
straightforward.

I'= ;m not terribly sympathetic to the complexity point: this is a very modest<= /div>
amount of crypto.



What is nice about the specific design you describe (and my flippant
tokbind suggestion as well coincidentally) is that it can be
incrementally added to this scheme without a complete overhaul,
probably without even changing the scheme name, suggestions below
notwithstanding.

It could be an optional increment, if we could decide that the push
service doesn't require this additional protection and it was
primarily for the benefit of application servers.=C2=A0 Yes, there are
benefits that accrue to push services and user agents alike, but we
might decide that they don't gain any certainty about these benefits. That suggests a second, though less satisfying, path: a new draft
describing the enhancement.

I agree that th= at's possible, but it's kind of unsatisfying to be publishing
=
a draft with this kind of known deficiency.

M= aybe the chairs or ART ADs would like to weigh in here?


I did have a stab at fixing your nits here:
=C2=A0 https://github.com/webpush-wg/webpus= h-vapid/pull/43

> S 1.
>=C2=A0 =C2=A0 Additionally, this design also relies on endpoint secrecy= as any
>=C2=A0 =C2=A0 application server in possession of the endpoint is able = to send
>=C2=A0 =C2=A0 messages, albeit without payloads.=C2=A0 In situations wh= ere usage of a
>=C2=A0 =C2=A0 subscription can be limited to a single application serve= r, the
>=C2=A0 =C2=A0 ability to associate a subscription with the application = server could
>=C2=A0 =C2=A0 reduce the impact of a data leak.
>
> I don't understand this text.

I realize that this is not at all clear.=C2=A0 How about:

Additionally, the design of RFC 8030 relies considerably on the secrecy of = push
subscription URIs.=C2=A0 Any application server in possession of this URI i= s able to
send messages to the user agent.=C2=A0 If use of a subscription could be li= mited to
a single application server, this would reduce the impact of the push
subscription URI being learned by an unauthorized party.

> S 2.
>=C2=A0 =C2=A0 This JWT is included in an Authorization header field, us= ing an auth-
>=C2=A0 =C2=A0 scheme of "vapid".=C2=A0 A push service MAY rej= ect a request with a 403
>=C2=A0 =C2=A0 (Forbidden) status code [RFC7235] if the JWT signature or= its claims
>=C2=A0 =C2=A0 are invalid.
>
> Given that "vapid" is tied to "P-256" it seems lik= e it would be better
> to rename this "vapid-p256"

That's just a cosmetic change.=C2=A0 If we change the scheme in = an
incompatible way based on the comment above, then a name change might
come with that, but your design might be able to use the same name.

I agree that it is largely a cosmetic change, = which is why it's in the COMMENT section.
With that said, I d= on't think it's purely a cosmetic change: given that we know that
there is diversity along this dimension, why are we baking one ide= ntifier into the
name


> S 5.
> You should call out that the email address is just a bare assertion.
See PR.

--f4030435c9f0c5f1d10556d55275-- From nobody Tue Aug 15 19:21:35 2017 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F13B1323C1; Tue, 15 Aug 2017 19:21:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-webpush-vapid@ietf.org, Phil Sorber , webpush-chairs@ietf.org, sorber@apache.org, webpush@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150285009047.12577.1184580798882485308.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 19:21:30 -0700 Archived-At: Subject: [Webpush] Ben Campbell's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 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, 16 Aug 2017 02:21:30 -0000 Ben Campbell has entered the following ballot position for draft-ietf-webpush-vapid-03: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-webpush-vapid/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- In section 2: "A push service MAY reject a request with a 403 (Forbidden) status code [RFC7235] if the JWT signature or its claims are invalid." This seems to leave the possibility of simply ignoring an invalid VAPID token or signature. Assuming we are talking about push servers that support VAPID in the first place, that seems dangerous. Wouldn't it be safer in the general case to treat a request with an invalid VAPID token as at least a bit fishy? I don't mean to say that ignoring the token is never the right thing to do. But the MAY seems week without some guidance on what other actions might be reasonable under what circumstances. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive: I agree with Ekr's DISCUSS. -3: "This authentication scheme is intended for use by an application server when using the Web Push protocol [RFC8030], but it could be used in other contexts if applicable." This guidance seems risky without some description of the properties a given context should have for vapid to be appropriate to use. Please consider elaborating, or removing the clause after the comma. "Some implementations permit the same P-256 key to be used for signing and key exchange. An application server MUST select a different private key for the key exchange [I-D.ietf-webpush-encryption] and signing the authentication token." I don't understand the intent here. It seems to say some implementations do this, but MUST not. Does "implementations" refer to VAPID or something else? -4.1: "A push service MUST ignore the body of a request that uses a different media type." This seems to give VAPID a monopoly on adding bodies. It precludes adding other media types in future webpush extensions. Is that the intent? - 4.2: "A push service MUST reject a message that omits mandatory credentials with a 401 (Unauthorized) status code. " This was already stated in section 2. Please avoid repeating normative text, as it creates ambiguity about which text is authoritative, and can complicate future updates. This section seems the more detailed, so perhaps section 2 could avoid the 2119 text. (But see my DISCUSS point on section 2.) - 8.2: [I-D.ietf-webpush-encryption] should be normative, since it is referenced in a MUST level normative requirement in section 3.2. (If that reference is not intended to be normative, then please rephrase the referring sentence.) Editorial: - Abstract: Please mention the name of the mechanism in the abstract. It might also be helpful to mention that there are cryptographic signatures involved. (Same for section 1). In general, the numerous mentions of "this design" tend to be ambiguous about whether we talk of the design in this document rather than that of webpush in general. Once could substitue "VAPID" for many instances. - 1.0: "Additionally, this design also ..." "Additionally" and "also" are redundant - 1.2: Please use the boilerplate from RFC 8174. - 4.1: "The user agent includes the public key of the application server when requesting the creation of a push subscription." I assume this means "A user agent that wishes to create a restricted subscription...". I know the heading says "Creating a restricted subscription", but in general the body text make sense even without the heading. "The public key is then added to the request to create a push subscription. The push subscription request is extended to include a body. The body of the request is a JSON object as described in [RFC7159]. A "vapid" member is added to this JSON object, containing the public key on the P-256 curve, encoded in the uncompressed form [X9.62] and base64url encoded [RFC7515]. The media type of the body is set to "application/webpush-options+json" (see Section 6.3 for registration of this media type)." The actor(s) are obscured by the heavy use of passive voice. - 6.3: Don't we usually list the IESG as the change controller? From nobody Tue Aug 15 19:31:44 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7A7132468 for ; Tue, 15 Aug 2017 19:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcIqWEmmTBtp for ; Tue, 15 Aug 2017 19:31:41 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F1A6132467 for ; Tue, 15 Aug 2017 19:31:41 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7G2VbJ9034466 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 15 Aug 2017 21:31:38 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Tue, 15 Aug 2017 21:31:36 -0500 Cc: Martin Thomson , "webpush@ietf.org" , draft-ietf-webpush-vapid , webpush-chairs@ietf.org, The IESG , Phil Sorber Content-Transfer-Encoding: quoted-printable Message-Id: <4125C183-E369-47EA-999A-0080BDF01B4A@nostrum.com> References: <150284054989.12518.11340069078773708886.idtracker@ietfa.amsl.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Webpush] Eric Rescorla's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 02:31:42 -0000 > On Aug 15, 2017, at 9:04 PM, Eric Rescorla wrote: >=20 >=20 >=20 >> On Tue, Aug 15, 2017 at 6:56 PM, Martin Thomson = wrote: >>> On 16 August 2017 at 09:42, Eric Rescorla wrote: >>> > Ultimately, this is a WG decision, but given that there are = designs >>> > with much better security properties, I'd like to know that the WG >>> > considered and rejected this kind of design alternative before >>> > we advance the weaker design. >>>=20 >> We discussed the implications of the bearer token design and = concluded >> that this was acceptable.=20 >=20 > That's a much easier discussion to have without an alternative. >=20 > =20 >> We didn't discuss additionally signing >> messages in this way. Another alternative is to describe how token >> binding could be used to prevent token theft. >>=20 >> One complaint I get about webpush is the amount of overhead crypto >> adds to sending messages. Mostly from a complexity standpoint. It's >> a real implementation barrier. We've forced people to jump through a >> lot of hoops and that has made them pretty annoyed. Deploying this = as >> a required extension could be additionally annoying, not to mention >> incompatible with the existing deployed code. >>=20 > The flippant thing to say would be that I-Ds come with a big = disclaimer > for exactly this reason. More seriously, the future is bigger than the = past > and given that (as you observe) the vapid token is used to identify > what you support, it seems like deploying the new thing would be > straightforward. >=20 > I'm not terribly sympathetic to the complexity point: this is a very = modest > amount of crypto. >=20 >=20 >=20 >> What is nice about the specific design you describe (and my flippant >> tokbind suggestion as well coincidentally) is that it can be >> incrementally added to this scheme without a complete overhaul, >> probably without even changing the scheme name, suggestions below >> notwithstanding. >>=20 >> It could be an optional increment, if we could decide that the push >> service doesn't require this additional protection and it was >> primarily for the benefit of application servers. Yes, there are >> benefits that accrue to push services and user agents alike, but we >> might decide that they don't gain any certainty about these benefits. >> That suggests a second, though less satisfying, path: a new draft >> describing the enhancement. >>=20 > I agree that that's possible, but it's kind of unsatisfying to be = publishing > a draft with this kind of known deficiency. >=20 > Maybe the chairs or ART ADs would like to weigh in here? >=20 >=20 Weighing in as an irresponsible (for this draft) ART AD: My knee jerk response is to agree with Ekr. But it=E2=80=99s worth = discussing how big of an incompatibility with existing code people are = talking about. Are there a lot of deployed services that support vapid? = Do people think that existing implementors will choose not to = implement/deploy the additional protection? Ben. [=E2=80=A6] From nobody Tue Aug 15 19:36:16 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C4C13246F; Tue, 15 Aug 2017 19:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlY3MPxlYaG4; Tue, 15 Aug 2017 19:36:06 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3B1132478; Tue, 15 Aug 2017 19:35:54 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7G2ZlLC035244 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 15 Aug 2017 21:35:48 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Ben Campbell , Eric Rescorla Cc: Martin Thomson , draft-ietf-webpush-vapid , Phil Sorber , The IESG , webpush-chairs@ietf.org, "webpush@ietf.org" References: <150284054989.12518.11340069078773708886.idtracker@ietfa.amsl.com> <4125C183-E369-47EA-999A-0080BDF01B4A@nostrum.com> From: Adam Roach Message-ID: <716e5820-e57f-b7c9-b3b4-3cf387409575@nostrum.com> Date: Tue, 15 Aug 2017 21:35:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <4125C183-E369-47EA-999A-0080BDF01B4A@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Webpush] Eric Rescorla's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 02:36:08 -0000 On 8/15/17 9:31 PM, Ben Campbell wrote: > My knee jerk response is to agree with Ekr. But it’s worth discussing how big of an incompatibility with existing code people are talking about. Are there a lot of deployed services that support vapid? Do people think that existing implementors will choose not to implement/deploy the additional protection? My inclination is to ask the WG to weigh in on this issue in particular. I've received some pretty confident responses indicating that VAPID has no issues with crypto-agility. Given that such is the case, it seems like the question of how many deployed implementations we have is pretty irrelevant: if we can't change crypto schemes at scale, then we shouldn't publish this document anyway. /a From nobody Tue Aug 15 20:25:28 2017 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 596051323B7; Tue, 15 Aug 2017 20:25:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-webpush-encryption@ietf.org, Phil Sorber , webpush-chairs@ietf.org, sorber@apache.org, webpush@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150285392127.12601.16486468628540142046.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 20:25:21 -0700 Archived-At: Subject: [Webpush] Ben Campbell's Yes on draft-ietf-webpush-encryption-08: (with COMMENT) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 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, 16 Aug 2017 03:25:21 -0000 Ben Campbell has entered the following ballot position for draft-ietf-webpush-encryption-08: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-webpush-encryption/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just a few minor and editorial comments: Substantive: - 1: "For efficiency reasons, multiple users of Web Push often share a central agent that aggregates push functionality." Is the "central agent" a push server, application server, or something else? Editorial: -1: "Web Push messages are the payload of an HTTP message " - Plural disagreement. -1.1: Please consider using the boilerplate from RFC 8174. -4, first paragraph: s/ "... some of the length..." / "... sum of the length ..." From nobody Tue Aug 15 22:09:54 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A9A1323C8; Tue, 15 Aug 2017 22:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-qhmYpRZYK0; Tue, 15 Aug 2017 22:09:44 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71E371321A5; Tue, 15 Aug 2017 22:09:44 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id 76so12936589ith.0; Tue, 15 Aug 2017 22:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dqkq/BJ5S3M4gyVwuUp8CgWCC/dg8hkBWDCBOsIpeVY=; b=DE6dsbM/9pHEMwO5y8YQpUtFYEOwJHEuWpBy9rgNo9tR0Y/5vyCILlUme2zwWCsreL 2ItRoMhH474QKA2DBT67IO0SRFQy/nRUzW5ZSfxvwGEDervapV9AcqiG2JGlHKKXakRJ ndmTrb0ljwBMWnc9w+f7U8MOnoIbQ0/ni+SQERbwWMWO27+1YoAhFF8oa+pxDxoNprL6 eN/+PUM6o+3x2TxIDbfKt4xWSmlwHoNP2GRa4UwVnrMAi/StOQeEQJNVczjN3tQXN+Aj h5+A/Z7EkusYOlHbmOMLvUpbsme0kDfdNPkb8ESPPS71PohnacKoNSJ4rZv0xHC1zBKl D5lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dqkq/BJ5S3M4gyVwuUp8CgWCC/dg8hkBWDCBOsIpeVY=; b=e61s25lla5pxq44KqAgkTRTIoe6jRipSD6vTinuodz3zxcw24it5mmGFhtb/l55QeW UzolCJ1CjtE4lQ1oYDXxkDLcAS16fzt9yTYFSx5gI+Syk9wz3/Oo/Bw/nhtm89mJV0q6 9mnm0/f9Sjwxg/3KAJuwZD/Kyf7gdfa2YMOzvDVuYk5CMvjFMajZj9L2Ooa9gaR34yb1 fzpPic6CrvTIxfIljZGLE0iici9hq79yuyPzGO0JnTWywW8xxsRZI8+4/8+8f0R1c4dm 0vWhrG2cgRw8rYd4Ue55yMK7fBmgv7lq7r53+VM1ZeIWP1FjlwlEjJkkEHi5qobQjXd2 XOAw== X-Gm-Message-State: AHYfb5jefL/r4AaT39Lc1kWQlw/TrvRGm+6cPM+berYKKIafoqphrnL0 2mt1ObnnBT/To4ydBvSaKqH567BLWQ== X-Received: by 10.36.107.68 with SMTP id v65mr962701itc.129.1502860183071; Tue, 15 Aug 2017 22:09:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Tue, 15 Aug 2017 22:09:42 -0700 (PDT) In-Reply-To: <716e5820-e57f-b7c9-b3b4-3cf387409575@nostrum.com> References: <150284054989.12518.11340069078773708886.idtracker@ietfa.amsl.com> <4125C183-E369-47EA-999A-0080BDF01B4A@nostrum.com> <716e5820-e57f-b7c9-b3b4-3cf387409575@nostrum.com> From: Martin Thomson Date: Wed, 16 Aug 2017 15:09:42 +1000 Message-ID: To: Adam Roach Cc: Ben Campbell , Eric Rescorla , draft-ietf-webpush-vapid , Phil Sorber , The IESG , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Webpush] Eric Rescorla's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 05:09:47 -0000 On 16 August 2017 at 12:35, Adam Roach wrote: > On 8/15/17 9:31 PM, Ben Campbell wrote: >> >> My knee jerk response is to agree with Ekr. But it=E2=80=99s worth discu= ssing how >> big of an incompatibility with existing code people are talking about. A= re >> there a lot of deployed services that support vapid? Do people think tha= t >> existing implementors will choose not to implement/deploy the additional >> protection? > > > > My inclination is to ask the WG to weigh in on this issue in particular. > I've received some pretty confident responses indicating that VAPID has n= o > issues with crypto-agility. Given that such is the case, it seems like th= e > question of how many deployed implementations we have is pretty irrelevan= t: > if we can't change crypto schemes at scale, then we shouldn't publish thi= s > document anyway. No change is free. We'd first have to establish whether the change is a net gain. The presumption here seems to be that the presented design is unconditionally superior. That's not true. This is a trade-off, and - in my opinion - not one that favours any change. For me the important point here is that the proposed change (in any form) is of fairly marginal value. Yes, the IETF is investing in anti-bearer-token-theft technology, but in this case what you get is the ability to send a message to user agent and wake it up. You get that after stealing two pieces of information: the push subscription URI and this token. (That's assuming that the first was not already sufficient, which it is in some cases.) You can't send arbitrary data, for that you need two more pieces of information: a public key and authorization code, and neither of these appear on the HTTPS connection from which the other items were stolen. So that's benefits. Let's talk about costs. If we take the suggested design the biggest challenge is key management for K_p (the key that the push service would have to maintain). Maintaining a set of keys across a globally-distributed service isn't free. Given that key compromise would undermine the effort we'd be putting in here, you also need a strategy for updating those keys and revocation of old or compromised keys. For that you want multiple keys, which means key identifiers in messages. You also need some way of having application servers update their view of what keys are current, maybe using expiration times. Technically, we also have to work out what to cover with the MAC. My experience with HTTP and signing suggests that this isn't as trivial as it might seem. I think that we could canonicalize the push subscription URI, Content-Encoding header field and payload and be reasonably sure that the MAC couldn't be transplanted. Probably also the RFC 8030 TTL, Urgency and Topic header fields, which suggests that there needs to be a way to sign any new and relevant header fields that might be added later. This would need some more analysis than I've given it here. Then we have to decide whether this is a mandatory part of the mechanism. It's marginally easier if it isn't, but the arguments ekr has presented suggest that he thinks it should be. That makes the deployment story harder. For that, we really would want to exercise the cryptographic agility Adam refers to here. It's possible that we don't need to worry too much about removing the old stuff on the basis that it's all voluntary anyway, but now there are two things that need to be implemented and supported. What incentive have we provided to use the new thing as opposed to the old thing? To answer Ben's question: there are a small number of push services (one for each browser, effectively http://caniuse.com/#feat=3Dpush-api), but a LOT of application servers. And to briefly address the costs of the other alternative: Doing something like token binding has a bunch of implementation costs. It cross layers in ways that make it difficult to both implement and deploy. For instance, we couldn't deploy it without draft-campbell-tokbind-ttrp being supported by our vendors. This is the same reason we considered and rejected client certificates for this - one of the many alternatives that were considered. p.s., It's been a while since I've been on the receiving end of the old "your code doesn't matter, you took a risk implementing an I-D" argument. As an argument it kinda stinks. I'm embarrassed to confess that I've used it in the past, despite reminding myself not to. I'd be interested in learning whether the IESG has an opinion on the subject. A statement of policy might be valuable. From nobody Tue Aug 15 22:20:06 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7362E132494; Tue, 15 Aug 2017 22:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sdy6_HbE5HAz; Tue, 15 Aug 2017 22:19:47 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A6691200C5; Tue, 15 Aug 2017 22:19:47 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id j32so9848379iod.0; Tue, 15 Aug 2017 22:19:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GrvLCXNOLmFt8aAP4xutJcO8he5hgkT+qikGKaLdmwc=; b=PNLwy9o5Yp8uIVGiX3+dNrRu/0TVGNvPcr+7cIpcsRYli6BHrd1Rrx76GB0Xzw+3D+ CdkFz0wF//mTsIOFvkqo910hxx9U61hHMo+96ko2j4LeJ6bT9bMsuBH4AShEkn9wXEL5 qnhplpVPF4eSsxY62lUI6SGG4aS4qqfRnpkiWJVRrcMgf/CWh+XbOtFW8+CwmfJkxB3n OJeroHdHnlqpgywKIqRY5ShnLFBtGvGA8Ktw/dQu9oE3nssHs9EGOfz0bkE7RiRnUXZ8 WHY+JSqZmmQi7cflKof4QrR/DdDfSaPuysE4pplGSJWyGdc91pKeeu6B6Px3tREySKMo pMdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GrvLCXNOLmFt8aAP4xutJcO8he5hgkT+qikGKaLdmwc=; b=bmcxYIQn3o4YE4NoRczDXu7sGYuBJRbWxiTJW/DYIXS0vn3nFct9tuHe75Ws/AKNki khFmIAI+RM9GI00wth+SJ8GU+W7wP/t1yjeEcMoWIF71CWWXmGSJ87Ygx4Kr94lyVB6z oIuGswUseLY479NyvRDCTiuQYjdlkn4URv3FWYhmiohcQMqkooyxq2QO/Z6X096qhnJ7 tVq8OO2cjZGf+Pu+Kl0Ye+mFIeMxtx006Mz3cf/fPke3f6EmEl5F7wFy/a5625WBIZr3 QBSRNwMOzufTwsLppvClrz5mf8SYgq6L16o/IPa7ys4lO1DnX2JOV+VVd80ZFNnKVhbF tm8Q== X-Gm-Message-State: AHYfb5jOSphqsAtTjWjiwc/AViQD3Gkqqxzmhk1mfciW48NmxJt6Nr9t iCETlQpEVH5kIS5xDU38Z+SlXEMxlQ== X-Received: by 10.107.16.196 with SMTP id 65mr467008ioq.297.1502860786871; Tue, 15 Aug 2017 22:19:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Tue, 15 Aug 2017 22:19:46 -0700 (PDT) In-Reply-To: <150285392127.12601.16486468628540142046.idtracker@ietfa.amsl.com> References: <150285392127.12601.16486468628540142046.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Wed, 16 Aug 2017 15:19:46 +1000 Message-ID: To: Ben Campbell Cc: The IESG , draft-ietf-webpush-encryption@ietf.org, Phil Sorber , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Webpush] Ben Campbell's Yes on draft-ietf-webpush-encryption-08: (with COMMENT) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 05:19:50 -0000 On 16 August 2017 at 13:25, Ben Campbell wrote: > - 1: "For efficiency reasons, multiple users of Web Push often share a > central agent that aggregates push functionality." > > Is the "central agent" a push server, application server, or something else? With Spencer's comment addressed, this is now: Multiple users of Web Push at the same user agent often share a central agent that aggregates push functionality. Does that make sense now? PR here: https://github.com/webpush-wg/webpush-encryption/pull/21 > -1: "Web Push messages are the payload of an HTTP message " - Plural disagreement. Fixed previously in response to directorate review or by a PR. > -4, first paragraph: s/ "... some of the length..." / "... sum of the length ..." As above. From nobody Tue Aug 15 22:41:59 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0F31321A5; Tue, 15 Aug 2017 22:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vx632WCw78Wp; Tue, 15 Aug 2017 22:41:51 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65CC2126C2F; Tue, 15 Aug 2017 22:41:51 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7G5fYV9066593 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 16 Aug 2017 00:41:35 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Martin Thomson Cc: Ben Campbell , Eric Rescorla , draft-ietf-webpush-vapid , Phil Sorber , The IESG , webpush-chairs@ietf.org, "webpush@ietf.org" References: <150284054989.12518.11340069078773708886.idtracker@ietfa.amsl.com> <4125C183-E369-47EA-999A-0080BDF01B4A@nostrum.com> <716e5820-e57f-b7c9-b3b4-3cf387409575@nostrum.com> From: Adam Roach Message-ID: <972ccc4e-da47-cb56-addc-ba7b02b94e67@nostrum.com> Date: Wed, 16 Aug 2017 00:41:33 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Webpush] Breaking Changes (was Re: Eric Rescorla's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT)) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 05:41:54 -0000 On 8/16/17 12:09 AM, Martin Thomson wrote: > p.s., It's been a while since I've been on the receiving end of the > old "your code doesn't matter, you took a risk implementing an I-D" > argument. As an argument it kinda stinks. I'm embarrassed to confess > that I've used it in the past, despite reminding myself not to. I'd > be interested in learning whether the IESG has an opinion on the > subject. A statement of policy might be valuable. Given that the alternative is effectively forbidding breaking changes after WG adoption -- which is clearly untenable -- I'm not sure what kind of policy you're looking for here. Can you clarify? /a From nobody Tue Aug 15 23:09:42 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D990A124BAC; Tue, 15 Aug 2017 23:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-EO_bYWcaKY; Tue, 15 Aug 2017 23:09:33 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0BA1241F5; Tue, 15 Aug 2017 23:09:33 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id g71so10026035ioe.5; Tue, 15 Aug 2017 23:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yRbq9DqQhgGPeh4tvDtNjgNUGurIfmAmnuzQBiSm0Ro=; b=gPrUiJxmIyBrydA71qhGYzBsKvQwB2CXgraUGlVy1dFd/d0GlTcB2v+7DkqCkKi65S LJxqPEVO6H8gaBpfH4yAnxhtk02wC91WlVNTSryF7F3h8+K7XDY9+lvdik7mDHrSYJWh eZUuPoFKLiItHWJdm0zsEpnEV2sSHpCj3Pp0hd77nwyqHeuwDpalm8FCyKHFZoi0xtKz N4w5GBMBL2mfHl3V57VK3iI3s0OveK4J3XMyoDECDKS+lRHxZ742mVRcv9MBtyXpf69C 37EpWSagkAqoqeP0XCjyzY/qHbR+dYvZGbr7cQuXfa3w46SceimA0WxaHt8mtiGlLIdK eZCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yRbq9DqQhgGPeh4tvDtNjgNUGurIfmAmnuzQBiSm0Ro=; b=E/uxEm0q6g8XqinnWL+p/l2xUvoz325LxApA8CflpVzqSkHHAmm3hdeST7jF424JGv bSEVg2zQ9Co09ZFfIBMt8AbAFoTV8RU6yF0wSnsI/gY/rMJZHkyk+FUWdavCSWcCJsft dm5ga3adtWV8hqMN/PyekNkx7K62aj9LXjCWw5edGs83ihnZCstTmQUrwfou3gz86zeq bLN1TYLeM4uDJ77aJtl5QxfWXndmYcAhRVY1h+od8hFIx700fOzPmGjkoio1cuWCmcRH qxDsGIk7mMDIMS0NR2dYv+Kj9241LTf9vlGWB9d1eXVbfvQjM434a289itLd4lKmgDj4 oRvQ== X-Gm-Message-State: AHYfb5hiNtL1pC+0BOl8jtb/mD7Maw/rU5PjoaCO8C/Q5qOiGGhRLUiV ool/SSgHlf37+uEYBfd1TZjbHBLBRw== X-Received: by 10.107.134.196 with SMTP id q65mr485526ioi.193.1502863772364; Tue, 15 Aug 2017 23:09:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Tue, 15 Aug 2017 23:09:31 -0700 (PDT) In-Reply-To: <150285009047.12577.1184580798882485308.idtracker@ietfa.amsl.com> References: <150285009047.12577.1184580798882485308.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Wed, 16 Aug 2017 16:09:31 +1000 Message-ID: To: Ben Campbell Cc: The IESG , draft-ietf-webpush-vapid , Phil Sorber , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Webpush] Ben Campbell's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 06:09:36 -0000 Hi Ben, I've collected the changes mentioned below into a PR here: https://github.com/webpush-wg/webpush-vapid/pull/44 On 16 August 2017 at 12:21, Ben Campbell wrote: > In section 2: "A push service MAY reject a request with a 403 (Forbidden) status > code [RFC7235] if the JWT signature or its claims are invalid." > > This seems to leave the possibility of simply ignoring an invalid VAPID token > or signature. Assuming we are talking about push servers that support > VAPID in the first place, that seems dangerous. Wouldn't it be safer in > the general case to treat a request with an invalid VAPID token as at > least a bit fishy? > > I don't mean to say that ignoring the token is never the right thing to > do. But the MAY seems week without some guidance on what other actions > might be reasonable under what circumstances. I think that "MAY" is entirely appropriate given the non-blocking nature of the mechanism. A push service might look at the header field, but not require the token. Maybe they just wanted to attach an email address to a stream of messages (that's what we do). > -3: > "This authentication scheme is intended for use by an application server > when using the Web Push protocol [RFC8030], but it could be used in > other contexts if applicable." > > This guidance seems risky without some description of the properties a > given context should have for vapid to be appropriate to use. Please > consider elaborating, or removing the clause after the comma. I forget how that got there. Unless someone screams, I've removed the clause in your PR. If it was critical somehow, there isn't anything stopping someone finding a use for this and reusing it without the clause. > "Some implementations permit the same P-256 key to be used for signing > and key exchange. An application server MUST select a different private > key for the key exchange [I-D.ietf-webpush-encryption] and signing the > authentication token." > > I don't understand the intent here. It seems to say some implementations > do this, but MUST not. Does "implementations" refer to VAPID or > something else? In NSS and many elliptic curve libraries, you can create an EC key for P-256. You can then use that key for signing AND key exchange. You shouldn't though. > -4.1: "A push service MUST ignore the body of a request that uses a > different media type." > > This seems to give VAPID a monopoly on adding > bodies. It precludes adding other media types in future webpush > extensions. Is that the intent? No, changed to "can" instead. The intent was to allow for extension, not prohibit it. > - 4.2: "A push service MUST reject a message that omits mandatory > credentials with a 401 (Unauthorized) status code. " > > This was already stated in section 2. Please avoid repeating normative > text, as it creates ambiguity about which text is authoritative, and can > complicate future updates. This section seems the more detailed, so perhaps > section 2 could avoid the 2119 text. (But see my DISCUSS point on section 2.) This isn't included in Section 2. Section 2 defines what a valid token is. This section defines behaviour in the case that a subscription is limited to a particular application server key. I realize now that this might have been unclear, so I have reworded to: "A push service MUST reject a message sent to a restricted push subscription if that message includes no "vapid" authentication or invalid "vapid" authentication. A 401 (Unauthorized) status code might be used if the authentication is absent; a 403 (Forbidden) status code might be used if authentication is invalid." This also allows me to clear up a minor gripe about the prescriptive nature of the text regarding status codes. > - 8.2: [I-D.ietf-webpush-encryption] should be normative, since it is > referenced in a MUST level normative requirement in section 3.2. (If > that reference is not intended to be normative, then please rephrase the > referring sentence.) Normative is easier than thinking about rephrasing :) > Editorial: > > - Abstract: Please mention the name of the mechanism in the abstract. It > might also be helpful to mention that there are cryptographic signatures > involved. (Same for section 1). A legacy of the history of the document - it started as a survey of alternatives and the abstract never got cleaned up fully. > In general, the numerous mentions of "this design" tend to be ambiguous > about whether we talk of the design in this document rather than that of > webpush in general. Once could substitue "VAPID" for many instances. Corrected as I saw them. Of the two instances of the word "design", one was corrected already (see below) and the other I have corrected to reference RFC 8030, which is the subject in both cases. > - 1.0: "Additionally, this design also ..." "Additionally" and "also" > are redundant Hopefully fixed in the changes I made in response to ekr's review: https://github.com/webpush-wg/webpush-vapid/pull/43/files > - 4.1: "The user agent includes the public key of the application server when > requesting the creation of a push subscription." > > I assume this means "A user agent that wishes to create a restricted > subscription...". I know the heading says "Creating a restricted > subscription", but in general the body text make sense even without the > heading. > > "The public key is then added to the request to create a push > subscription. The push subscription request is extended to include a > body. The body of the request is a JSON object as described in > [RFC7159]. A "vapid" member is added to this JSON object, containing > the public key on the P-256 curve, encoded in the uncompressed form > [X9.62] and base64url encoded [RFC7515]. The media type of the body is > set to "application/webpush-options+json" (see Section 6.3 for > registration of this media type)." > > The actor(s) are obscured by the heavy use of passive voice. I made a couple of changes. > - 6.3: Don't we usually list the IESG as the change controller? I'm mostly cargo-culting here. This choice didn't elicit comment when I asked for media-type review. For reference, the last one of these that went through the IESG came back with very specific instructions, and a citation. I can't find that email, or the citation, but I think that it was RFC 6838, Section 3.1, which doesn't seem particularly crisp: The "owner" of a media type registered in the standards tree is assumed to be the standards-related organization itself. I did find the documents that I remember: RFCs 8142 and 7946 use "Internet Engineering Task Force" and "IETF" respectively. It seems like this isn't entirely consistent though. I will accept the wisdom of the IESG on this matter. From nobody Tue Aug 15 23:22:32 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3D2126B71; Tue, 15 Aug 2017 23:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MavJEnbNrVtV; Tue, 15 Aug 2017 23:22:28 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAFE8124217; Tue, 15 Aug 2017 23:22:27 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id c74so10104174iod.4; Tue, 15 Aug 2017 23:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pZ1C8BdcW1+Xc4nLaz2uV9gOu9M5a8eULvS4auyyFDU=; b=XWoMZDIqi4vP8kVaI/tkbjkx97N34IGRh2apdX1mH0tCm2ZjDxPnyfZjZ9Ahyxd5iY K0A3FsbaNbg32IoxKoknHH10I/yIjks1YoO67R+M7tTTIHEehrAmKiKaLC/DBHXhq39i gTKn5rl91jTvMYe6dGUD9ACUTVO9qfABTWN+T/oxJ1Y+xGA6SiCg79ZiY+1QgOCEEEGc LLVWFBxh0aELSD5zdEyrdlV/pqmwverVcJRcslr4y7txOlin5UAXZSzYessits9RLxNm mpRbzTm4n2dSZYtK6EPt8ORPQ8k0VGM5rSJ/KGBG28o6Zd3ICkG1Bdb9ZTSQw2BR+WBj gIsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pZ1C8BdcW1+Xc4nLaz2uV9gOu9M5a8eULvS4auyyFDU=; b=lq8IABUOpYq9jCIO+IgWZKWSdm1du5e4XP1ISs48d1Mpf+pekHLhe12AZ2oUkeNfah ECbSu43I4DYHpF83jc2M+ysAqWBicOxttF+2bBVn0qqZkaj5+YgK9AYG9YN5hfC+Qha+ eIFC2G7quXIvPukd5bsPpUhtEhOrcusZxU+pdAGbMnGBgm6p9G/n1bLuwW3B6uXng1q0 Uzu5QnBSou625k5aSRkRiwNGGP+p6QceWX/m3Nw1eyTXsiHOpMQ03iPmzPInMQutO/y+ WqiW17aDtzWFQ/wVJKE3MZxLslrghopq1OPLXc6Kc6noolFryXD3i29I4fTTx1N/DYI7 Ok4w== X-Gm-Message-State: AHYfb5gnQ/cH0d6QY68Pl8o+Ym1bdeypC1odfiyxhk6Gj4AfbnWyTPcD Z+Lvi922BKBbtG5n4roCRRDx6efslQ== X-Received: by 10.107.46.155 with SMTP id u27mr489859iou.107.1502864547227; Tue, 15 Aug 2017 23:22:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Tue, 15 Aug 2017 23:22:26 -0700 (PDT) In-Reply-To: <972ccc4e-da47-cb56-addc-ba7b02b94e67@nostrum.com> References: <150284054989.12518.11340069078773708886.idtracker@ietfa.amsl.com> <4125C183-E369-47EA-999A-0080BDF01B4A@nostrum.com> <716e5820-e57f-b7c9-b3b4-3cf387409575@nostrum.com> <972ccc4e-da47-cb56-addc-ba7b02b94e67@nostrum.com> From: Martin Thomson Date: Wed, 16 Aug 2017 16:22:26 +1000 Message-ID: To: Adam Roach Cc: Ben Campbell , Eric Rescorla , draft-ietf-webpush-vapid , Phil Sorber , The IESG , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Webpush] Breaking Changes (was Re: Eric Rescorla's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT)) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 06:22:30 -0000 On 16 August 2017 at 15:41, Adam Roach wrote: > On 8/16/17 12:09 AM, Martin Thomson wrote: >> >> p.s., It's been a while since I've been on the receiving end of the >> old "your code doesn't matter, you took a risk implementing an I-D" >> argument. As an argument it kinda stinks. I'm embarrassed to confess >> that I've used it in the past, despite reminding myself not to. I'd >> be interested in learning whether the IESG has an opinion on the >> subject. A statement of policy might be valuable. > > Given that the alternative is effectively forbidding breaking changes after > WG adoption -- which is clearly untenable -- I'm not sure what kind of > policy you're looking for here. Can you clarify? (Hmm, I got this message twice...) The usual exchange goes a: "I have code", b: "you implemented an I-D, that's your problem". Some guidance about how to manage this situation would be appreciated. I'm not looking for a prohibition on changes at any point in the process. That's ludicrous, after all, people do understand what it means to implement an I-D. But statements like "there is code" or "there is deployed code" are valid and useful input to a discussion and not just as proof that a given thing is possible. That means potentially affecting the outcome of a decision. In this particular case, the arguments presented weren't problematic, because the real arguments was actually "well, this change doesn't seem that bad to me". But it's not the first time someone has opened with that argument and it annoyed me enough to comment. From nobody Wed Aug 16 01:42:48 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28452132656; Wed, 16 Aug 2017 01:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=P21gOeRc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mveI1Rw8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8wglE1O-tAK; Wed, 16 Aug 2017 01:42:39 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3840132641; Wed, 16 Aug 2017 01:42:39 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E324E210F0; Wed, 16 Aug 2017 04:42:37 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 16 Aug 2017 04:42:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=oriPyOGPAfysKVtSjU +j7GuZ+POD8O5IOH8X9CBABVc=; b=P21gOeRcoAyZC3ehhJUK/A7uBWFPUKKjfB Yu2qqUxT+2RsF9rtoQIR6OqWfyH1yeshF+TWhUhpz0RjSQpSX7DJTygXPO4uFFjs u9vMRWKEvcOUlG6e83Lk3c2kG9t4uJjY3ZARYnSEGT00n4yIpUXACYtnK2sHHQ4X GVFRHopGZ/FcBHajo8SJgHGLphbvR9EFdoz5QSY7suqStZOy2uQcGP57V8F6T8qc mzKXQd3lSZEizW2J51PLUw0URimo5AU4rvyQxCmqYf+Hd1whuorG8XLfg3e3LRim XrvEEAcgepx2k5xMQTD6gmmYq+8pVrlrib0BCHF20GsBqFLmfvCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=oriPyOGPAfysKVtSjU+j7GuZ+POD8O5IOH8X9CBABVc=; b=mveI1Rw8 a73kXRwIDwHwD4uRcAznk6r2qkEzp4PSga099WCSgK3Gr3RNbJoCNKBNWeuObwyx oRxmh5NdiVd+zoiYUzo1RZ2MLZaUOU3SVKMgx3nDZHmsPXVpVqehD1TrMhIZPMBE ea98a73P8VhaMW0aQvVVs3jiuQecjWuhLYNBlSQ3dpHun5Ac4qPJY/5vc78zRzOA UWzrBq9faDVU0VRgYtC6w7zG/17xre5jQ6ErgS4wjQfjE2t3endkFkY7/olgAg/a s7nsN9ZNNlkc36rSSM8YUVQyc3o5ZGjK4+Q6HQ0uLA22DEVppaOchtuIuUT9JVA1 0iMYkGMZLzH1bg== X-ME-Sender: X-Sasl-enc: uiW/U1KIzAOFyp4CHmdE1Nqnh6yVjxA3S4uF9Q0K5uKL 1502872957 Received: from [192.168.0.6] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by mail.messagingengine.com (Postfix) with ESMTPA id 933E87E8C7; Wed, 16 Aug 2017 04:42:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (14F89) In-Reply-To: Date: Wed, 16 Aug 2017 09:44:11 +0100 Cc: Costin Manolache , The IESG , draft-ietf-webpush-vapid , webpush-chairs@ietf.org, "webpush@ietf.org" , Phil Sorber Content-Transfer-Encoding: quoted-printable Message-Id: <3E387AA4-840C-4B05-8534-3DFE1228B2F0@fastmail.fm> References: <150281715482.21106.3346502830630897599.idtracker@ietfa.amsl.com> To: Martin Thomson Archived-At: Subject: Re: [Webpush] Alexey Melnikov's No Objection on draft-ietf-webpush-vapid-03: (with COMMENT) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 08:42:42 -0000 Hi Martin, > On 16 Aug 2017, at 02:24, Martin Thomson wrote:= >=20 > We have previously discussed the problem of discovering whether a > server supports a particular authentication scheme. On the API side, > we didn't resolve to make a change that would add a mechanism similar > to what we use for content coding (see > https://github.com/w3c/push-api/pull/262 for that discussion). This > is approximately what Costin is talking about here. >=20 > What has changed since that time is that I have learned that some push > services *require* authentication. >=20 > For that reason, though it adds delays to sending when authentication > fails, I'm inclined to add a challenge. It would be empty, but it > would allow a server to insist on authentication in a transparent way. >=20 > It IS easy to define: https://github.com/webpush-wg/webpush-vapid/pull/42 Just returning auth-scheme with no parameter is exactly what I was talking a= bout. I like this change. >=20 >> On 16 August 2017 at 03:56, Costin Manolache wrote: >> IMHO out-of-band discovery may be sufficient - in webpush it is implicit o= r >> can be part of the >> subscribe handshake. If VAPID is used with an API the supported auth may b= e >> part of the API >> schema/discovery. >>=20 >> I think in future it may be valuable to add an optional certificate - eit= her >> as an extra header or parameter - >> to allow authentication without a database RT. In such mode a mechanism t= o >> discover supported >> roots may be needed - however it can also be done out-of-band. >>=20 >> B >>=20 >> Costin >>=20 >>=20 >> On Tue, Aug 15, 2017 at 10:12 AM, Alexey Melnikov >> wrote: >>>=20 >>> Alexey Melnikov has entered the following ballot position for >>> draft-ietf-webpush-vapid-03: No Objection >>>=20 >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-webpush-vapid/ >>>=20 >>>=20 >>>=20 >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>>=20 >>> I have cleared my DISCUSS based on changes in git. >>>=20 >>> I am looking forward to continuing discussion about advertising support >>> for the >>> "vapid" authentication scheme in WWW-Authenticate: >>>=20 >>> In Section 3, 3rd para: >>>=20 >>> This authentication scheme does not require a challenge. Clients are >>> able to generate the Authorization header field without any >>> additional information from a server. Therefore, a challenge for >>> this authentication scheme MUST NOT be sent in a WWW-Authenticate >>> header field. >>>=20 >>> Does this mean that there is no way to discover whether a particular >>> server >>> supports "vapid" HTTP authentication scheme? >>>=20 >>>=20 >>> _______________________________________________ >>> Webpush mailing list >>> Webpush@ietf.org >>> https://www.ietf.org/mailman/listinfo/webpush >>=20 >>=20 From nobody Wed Aug 16 01:52:55 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1DA132670; Wed, 16 Aug 2017 01:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=CyQw52dv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eaOjsuVG Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdZVvZy3rrV6; Wed, 16 Aug 2017 01:52:53 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0E501323C8; Wed, 16 Aug 2017 01:52:52 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 54D86209F9; Wed, 16 Aug 2017 04:52:52 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 16 Aug 2017 04:52:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=DjcUuQk+irn3GjCuer 2dCHxwXvPhIyujys5WYHy2BSo=; b=CyQw52dvCkxvpZVCje0OhJ+lDomFDMEyoP Svv/GwtYEOGm9mxv/qxRncyYV54pomcWfbCt5jq647iybNaVdTSU2R7bcGpqblS4 NsylxbCEs97O1LuluIHYKG5R8Gv1j0Wb6/x9tyofqcgogf2oPvV32NYMA/2faf/B KQxYbTFE9qjL4GhEdvZnhQmblrFwMu635ujppDWvz5l/Swxr+hTVPs5xLUpNKRtV rNecC5XY0LSmWl9X6yLtyEBuVQeM6Aq+lPZDZ8dONotVsZ+aJcask8LcBOWwQ/+n GCFDgeBwT3U6H8yCaD0ExIUqhivLPifoEhIqeccYA3yXM0mrh35w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=DjcUuQk+irn3GjCuer2dCHxwXvPhIyujys5WYHy2BSo=; b=eaOjsuVG N2ZTo0QUrwEZHq7Pl/asIqF2vOEcuJNCoVEEj4zaxI8R4KfvESPenAwRuFF1AZNO 0XeyVCVJyWkKXCD5+jxlrxDYZzv/EDKuzefobrlY7bZzwOR2Dgpal8OHxfGvgory eCgei7wx5Jvb456FCu5ZWV92vuyAltRK0xajlCzFxYftDODbwQSjNPDn6i3tdGIr WEyZgdT/fTWCc22HsMhNw+jUKCGoHHrpng4xQMjWQnxOFzzNKTZWG9P4ZN4og4Qe Qd33UZIZVaMegY+eTMHc6kBei2G/Viy/XjY0C4u/icpQ9BmGJBshf1zUkTrqgFeK DeqcI8WTIyuB5w== X-ME-Sender: X-Sasl-enc: V1DxSR+zGPckfTMC4wTRtpYQcW/nCPg1qGlPWEuQvYbE 1502873571 Received: from [192.168.0.6] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by mail.messagingengine.com (Postfix) with ESMTPA id AA4EE7F986; Wed, 16 Aug 2017 04:52:51 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (14F89) In-Reply-To: Date: Wed, 16 Aug 2017 09:54:24 +0100 Cc: Ben Campbell , "webpush@ietf.org" , draft-ietf-webpush-vapid , webpush-chairs@ietf.org, The IESG , Phil Sorber Content-Transfer-Encoding: 7bit Message-Id: <6B34A056-0C43-4065-839D-86BE93EF56FA@fastmail.fm> References: <150285009047.12577.1184580798882485308.idtracker@ietfa.amsl.com> To: Martin Thomson Archived-At: Subject: Re: [Webpush] Ben Campbell's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 08:52:54 -0000 On 16 Aug 2017, at 07:09, Martin Thomson wrote: >> - 6.3: Don't we usually list the IESG as the change controller? > > I'm mostly cargo-culting here. This choice didn't elicit comment when > I asked for media-type review. > > For reference, the last one of these that went through the IESG came > back with very specific instructions, and a citation. I can't find > that email, or the citation, but I think that it was RFC 6838, Section > 3.1, which doesn't seem particularly crisp: > > The "owner" of a media type registered in the standards tree is > assumed to be the standards-related organization itself. > > I did find the documents that I remember: RFCs 8142 and 7946 use > "Internet Engineering Task Force" and "IETF" respectively. It seems > like this isn't entirely consistent though. I will accept the wisdom > of the IESG on this matter. IMHO, either IESG or IETF is fine. In both cases we know what you mean. From nobody Wed Aug 16 05:56:24 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD1113219A for ; Wed, 16 Aug 2017 05:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8UNd4E7U2Ba for ; Wed, 16 Aug 2017 05:56:17 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B20A11326B8 for ; Wed, 16 Aug 2017 05:56:14 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id l82so21842120ywc.2 for ; Wed, 16 Aug 2017 05:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XUkSofcTw53DIS6kRFZCLEq/DdfuDLW1L+V0Nqo/+ik=; b=BpdG8R1K/zecLHe8uOp5KTpVLdFSIZvgsfi7+r+CmzzCToqYPlBKagX0trN8gR3aui UIVB0OYYoinbwsFsLxEVXK2e0p9h6jmHSZyKjQmeKqe4RmW65wqcOQLHiK2lnWKVIJPb emfvN5ku+ehyDRXsbnqBlktUWEXOGAYXVwkxC49oqc1o/TNQ9ci3evHP7gC2DcWy6hga SN6QCWk7X8kiMpTUJeEWxmwnSbnqusDC8Tazwt5u95FWSLmnpsUtW3yYFzC0VGwGftZa PtWPQE8uOCa8Sdju95C5fd5AnLJ+TzrxDbgasbVreWF7tKoRj9c6R9ppl0hOggJcJO8K Cm2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XUkSofcTw53DIS6kRFZCLEq/DdfuDLW1L+V0Nqo/+ik=; b=TywM4RqCbAn+6G8GXMCPsryOKKdWUyDm96P9UNAShVZlzqaNF1KlJU3/mYbdy/NajH /lCxzihEeRBlxF6KXvwbXcXhce46AvvD9cQhQEAPwFCh14HZnXHhb+k568T+VjdnrDr7 52Q7xj4Ar+BHh6sndRTO1s1ImjMJNvSj4+4SAJ/8Y1A3aCyZfzmAEFlq1ynM8xMprK7T dCsBU6974RPJ4KPMqXVbeI7qy5K4TLizMIcFK3O0mhq3RAxshcyfwa6ML+FXgx3z2kUh AhzfMBtkC56PDncWBdt928cGrt/GsHUWvqgh576mk4N/QyFd3uH6OF0pCHQST/gKtGcr Rsgg== X-Gm-Message-State: AHYfb5hA1QebdeGS3NZTFhA/GB/txY9xrcHn7g/LxHYmy0ppm8ZxWfPy 7YanwTaE3Eu3NlPMcirN/jYwtCmVrx1U X-Received: by 10.129.115.195 with SMTP id o186mr1299482ywc.222.1502888173879; Wed, 16 Aug 2017 05:56:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Wed, 16 Aug 2017 05:55:33 -0700 (PDT) In-Reply-To: References: <150284054989.12518.11340069078773708886.idtracker@ietfa.amsl.com> <4125C183-E369-47EA-999A-0080BDF01B4A@nostrum.com> <716e5820-e57f-b7c9-b3b4-3cf387409575@nostrum.com> From: Eric Rescorla Date: Wed, 16 Aug 2017 05:55:33 -0700 Message-ID: To: Martin Thomson Cc: Adam Roach , Ben Campbell , draft-ietf-webpush-vapid , Phil Sorber , The IESG , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Type: multipart/alternative; boundary="001a11493408bde1380556de6b2d" Archived-At: Subject: Re: [Webpush] Eric Rescorla's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 12:56:19 -0000 --001a11493408bde1380556de6b2d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 15, 2017 at 10:09 PM, Martin Thomson wrote: > On 16 August 2017 at 12:35, Adam Roach wrote: > > On 8/15/17 9:31 PM, Ben Campbell wrote: > >> > >> My knee jerk response is to agree with Ekr. But it=E2=80=99s worth dis= cussing > how > >> big of an incompatibility with existing code people are talking about. > Are > >> there a lot of deployed services that support vapid? Do people think > that > >> existing implementors will choose not to implement/deploy the addition= al > >> protection? > > > > > > > > My inclination is to ask the WG to weigh in on this issue in particular= . > > I've received some pretty confident responses indicating that VAPID has > no > > issues with crypto-agility. Given that such is the case, it seems like > the > > question of how many deployed implementations we have is pretty > irrelevant: > > if we can't change crypto schemes at scale, then we shouldn't publish > this > > document anyway. > > No change is free. We'd first have to establish whether the change is > a net gain. > > The presumption here seems to be that the presented design is > unconditionally superior. That's not true. This is a trade-off, and > - in my opinion - not one that favours any change. > > For me the important point here is that the proposed change (in any > form) is of fairly marginal value. Yes, the IETF is investing in > anti-bearer-token-theft technology, but in this case what you get is > the ability to send a message to user agent and wake it up. > > You get that after stealing two pieces of information: the push > subscription URI and this token. (That's assuming that the first was > not already sufficient, which it is in some cases.) You can't send > arbitrary data, for that you need two more pieces of information: a > public key and authorization code, and neither of these appear on the > HTTPS connection from which the other items were stolen. > This is a rather odd argument, as it also applies to the mechanism in this document as a whole. So that's benefits. Let's talk about costs. > > If we take the suggested design the biggest challenge is key > management for K_p (the key that the push service would have to > maintain). Maintaining a set of keys across a globally-distributed > service isn't free. Given that key compromise would undermine the > effort we'd be putting in here, you also need a strategy for updating > those keys and revocation of old or compromised keys. For that you > want multiple keys, which means key identifiers in messages. You also > need some way of having application servers update their view of what > keys are current, maybe using expiration times. > You raise several issues here: 1. The cost of coordinating the key. I agree that this is a real cost to the mechanism I proposed here, though it's possible to mitigate it in a number of ways (e.g., by having a centralized oracle for doing the verification, given that you don't need to do a lot of EC computation here). 2. The need for revocation. You don't actually need that here, just a key update mechanism and a way to tell the app server "use this new key". But this latter mechanism is the same one you use for key updates and for updates to the mechanism, which this document implies the WG thinks is easy= . 3. Key identifiers in messages are just specification work, so I don't think that that's a strong argument (see below). 4. Yes, it's a concern if these keys are compromised, but note that even if that's so, the security of the system reduces back to a bearer token (because you need the DH public key and the signed JWT), so that doesn't seem like much of a cost. Technically, we also have to work out what to cover with the MAC. My > experience with HTTP and signing suggests that this isn't as trivial > as it might seem. I think that we could canonicalize the push > subscription URI, Content-Encoding header field and payload and be > reasonably sure that the MAC couldn't be transplanted. Probably also > the RFC 8030 TTL, Urgency and Topic header fields, which suggests that > there needs to be a way to sign any new and relevant header fields > that might be added later. This would need some more analysis than > I've given it here. > I agree that there are complexities here, but they're complexities that are motivated by actually trying to design something with stronger security properties. More generally, they are costs to the WG, but not really costs to the world at large. Finally, I think this discussion has ratholed a bit on this particular counter-proposal. My point isn't that you should do this particular thing but rather that it seems like the WG decided on a bearer-token model without giving sufficient consideration to alternatives that have better security (of which this is merely one). The fact that I was able to produce two such alternatives in a few hours (which I'll concede are not in every way superior) and your response was not "yes, we considered those and here is a pointer to the WG archives" seems to lend that point some plausibility= . As I said initially, this is ultimately a WG decision and I'm fine with being told by the ADs and the Chairs that they believe sufficient consideration has been given, in which case I'll withdraw my discuss. So far I haven't heard that. -Ekr p.s., It's been a while since I've been on the receiving end of the > old "your code doesn't matter, you took a risk implementing an I-D" > argument. As an argument it kinda stinks. I'm embarrassed to confess > that I've used it in the past, despite reminding myself not to. I think I explicitly labelled this argument as flippant, but I also don't think it's valueless, especially when put up against "Three large companies implemented and are too lazy to change". --001a11493408bde1380556de6b2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Aug 15, 2017 at 10:09 PM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:
On 16 August 2017 at 12:35, Adam Roach &= lt;adam@nostrum.com> wrote:
> On 8/15/17 9:31 PM, Ben Campbell wrote:
>>
>> My knee jerk response is to agree with Ekr. But it=E2=80=99s worth= discussing how
>> big of an incompatibility with existing code people are talking ab= out. Are
>> there a lot of deployed services that support vapid? Do people thi= nk that
>> existing implementors will choose not to implement/deploy the addi= tional
>> protection?
>
>
>
> My inclination is to ask the WG to weigh in on this issue in particula= r.
> I've received some pretty confident responses indicating that VAPI= D has no
> issues with crypto-agility. Given that such is the case, it seems like= the
> question of how many deployed implementations we have is pretty irrele= vant:
> if we can't change crypto schemes at scale, then we shouldn't = publish this
> document anyway.

No change is free.=C2=A0 We'd first have to establish whether th= e change is
a net gain.

The presumption here seems to be that the presented design is
unconditionally superior.=C2=A0 That's not true.=C2=A0 This is a trade-= off, and
- in my opinion - not one that favours any change.

For me the important point here is that the proposed change (in any
form) is of fairly marginal value.=C2=A0 Yes, the IETF is investing in
anti-bearer-token-theft technology, but in this case what you get is
the ability to send a message to user agent and wake it up.

You get that after stealing two pieces of information: the push
subscription URI and this token.=C2=A0 (That's assuming that the first = was
not already sufficient, which it is in some cases.)=C2=A0 You can't sen= d
arbitrary data, for that you need two more pieces of information: a
public key and authorization code, and neither of these appear on the
HTTPS connection from which the other items were stolen.

This is a rather odd argument, as it also applies to the = mechanism in this document as a whole.


<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> So that's benefits.=C2=A0 Let's talk about costs.

If we take the suggested design the biggest challenge is key
management for K_p (the key that the push service would have to
maintain).=C2=A0 Maintaining a set of keys across a globally-distributed service isn't free.=C2=A0 Given that key compromise would undermine the=
effort we'd be putting in here, you also need a strategy for updating those keys and revocation of old or compromised keys.=C2=A0 For that you want multiple keys, which means key identifiers in messages.=C2=A0 You also=
need some way of having application servers update their view of what
keys are current, maybe using expiration times.

You raise several issues here:

1. The cos= t of coordinating the key. I agree that this is a real cost to the mechanis= m I proposed here, though it's possible to mitigate it in a number of w= ays (e.g., by having a centralized oracle for doing the verification, given= that you don't need to do a lot of EC computation here). =C2=A0
<= div>
2. The need for revocation. You don't actually need = that here, just a key update mechanism and a way to tell the app server &qu= ot;use this new key". But this latter mechanism is the same one you us= e for key updates and for updates to the mechanism, which this document imp= lies the WG thinks is easy.

3. Key identifiers in = messages are just specification work, so I don't think that that's = a strong argument (see below).

4. Yes, it's a = concern if these keys are compromised, but note that even if that's so,= the security of the system reduces back to a bearer token (because you nee= d the DH public key and the signed JWT), so that doesn't seem like much= of a cost.


Technically, we also have to work out what to cover with the MAC.=C2=A0 My<= br> experience with HTTP and signing suggests that this isn't as trivial as it might seem.=C2=A0 I think that we could canonicalize the push
subscription URI, Content-Encoding header field and payload and be
reasonably sure that the MAC couldn't be transplanted.=C2=A0 Probably a= lso
the RFC 8030 TTL, Urgency and Topic header fields, which suggests that
there needs to be a way to sign any new and relevant header fields
that might be added later.=C2=A0 This would need some more analysis than I've given it here.

I agree that th= ere are complexities here, but they're complexities that are motivated = by actually trying to design something with stronger security properties. M= ore generally, they are costs to the WG, but not really costs to the world = at large.


Finally, I think this dis= cussion has ratholed a bit on this particular counter-proposal. My point is= n't that you should do this particular thing but rather that it seems l= ike the WG decided on a bearer-token model without giving sufficient consid= eration to alternatives that have better security (of which this is merely = one). The fact that I was able to produce two such alternatives in a few ho= urs (which I'll concede are not in every way superior) and your respons= e was not "yes, we considered those and here is a pointer to the WG ar= chives" seems to lend that point some plausibility.

As I said initially, this is ultimately a WG decision and I'm fi= ne with being told by the ADs and the Chairs that they believe sufficient c= onsideration has been given, in which case I'll withdraw my discuss. So= far I haven't heard that.

-Ekr

=
p.s., It's been a while since I've been on the receiving end of the=
old "your code doesn't matter, you took a risk implementing an I-D= "
argument.=C2=A0 As an argument it kinda stinks.=C2=A0 I'm embarrassed t= o confess
that I've used it in the past, despite reminding myself not to.=C2=A0

I think I explicitly labelled this argument = as flippant, but I also don't think it's valueless, especially when= put up against "Three large companies implemented and are too lazy to= change".


--001a11493408bde1380556de6b2d-- From nobody Wed Aug 16 06:01:52 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F385913219C; Wed, 16 Aug 2017 06:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoRcDco-tLo9; Wed, 16 Aug 2017 06:01:42 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 829691325E2; Wed, 16 Aug 2017 06:01:40 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id l82so21933822ywc.2; Wed, 16 Aug 2017 06:01:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vlEnseVe2t+MC/0+KTy0v9PfFaJFdE2+J4+bbM99eTA=; b=vfzgINVKBU6uFrygSbMz8lS3WopFyBVEEmf8wVBnjbpDmWXGqjnHLr3AWTbfUowKBu zhvX/DXCGeXcW6gZ3jrjU9TiVtNiQXXTP204e57abt7DmqM+MjlERxYhRCU1JdkxAruw MdiSIfY6ADbt6AZXPGuPMNZgxhdFbTu+WnV+VaivxNQ9OMnwb/Vd9bMC+EFD44Z6yoHT LvK7DHAGcRqwX3tBT7kglkH87Jmsz9ZUP+ckxGwVXWf4H0mdDQGt6XORNpJuNG2G1MRI fUzvX1kca3712v3990SnDv6gMo74Vr8rKuX/E08j3YSB8t/yeKYgEbBiVtVumHu5pdm8 uG9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vlEnseVe2t+MC/0+KTy0v9PfFaJFdE2+J4+bbM99eTA=; b=JanKRcWPkNGl+w9RteREyO6PzYci3+TBkW6Bexff/1XgXRsBePD35QcVKXnoYWzXHo q/NaUrRpps0ww5vb1Z86Eng+7Ts1B1pOfc1jiri7XeClnxNPBsIFEm3moSGgJCdeInBn b0QFst1Uv+fUlSTu+AtFvqFvkr9bbBUgLcsxXxoOobxyjUef51zS4PPzIv8/7w4OlUBu AISVXYT73zKuQ7pIZ5uY6Vhnhlr7XhMB1LzP33A3g/12IzM8ozJ211cRnSzQvS+CwBWA wnO6TwL0NeRo6D+cPE9mJnxLBYEBIcOHf2gW6+JbuJBYZqS3sTZ7w3iuNRFhEkA4cTly yqTQ== X-Gm-Message-State: AHYfb5hR3oU6dYinFgrsK1q5nNXmwuEPNlRBN4rbJKa3cpprS8XBOijU ZaU4KgVtpzXYFLZVOG23I+Xd5CM4Xw== X-Received: by 10.13.213.148 with SMTP id x142mr1243253ywd.311.1502888499404; Wed, 16 Aug 2017 06:01:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.40.194 with HTTP; Wed, 16 Aug 2017 06:01:38 -0700 (PDT) In-Reply-To: References: <150285392127.12601.16486468628540142046.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Wed, 16 Aug 2017 08:01:38 -0500 Message-ID: To: Martin Thomson Cc: Ben Campbell , "webpush@ietf.org" , draft-ietf-webpush-encryption@ietf.org, webpush-chairs@ietf.org, The IESG , Phil Sorber Content-Type: multipart/alternative; boundary="001a114fa26624f0880556de7f07" Archived-At: Subject: Re: [Webpush] Ben Campbell's Yes on draft-ietf-webpush-encryption-08: (with COMMENT) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 13:01:45 -0000 --001a114fa26624f0880556de7f07 Content-Type: text/plain; charset="UTF-8" Hi, Martin, On Wed, Aug 16, 2017 at 12:19 AM, Martin Thomson wrote: > On 16 August 2017 at 13:25, Ben Campbell wrote: > > - 1: "For efficiency reasons, multiple users of Web Push often share a > > central agent that aggregates push functionality." > > > > Is the "central agent" a push server, application server, or something > else? > > With Spencer's comment addressed, this is now: > > Multiple users of Web Push at the same user agent often share a > central agent that aggregates push functionality. > > Does that make sense now? PR here: > https://github.com/webpush-wg/webpush-encryption/pull/21 > > Ben's thread, but Spencer appreciates the clarification. > > -1: "Web Push messages are the payload of an HTTP message " - Plural > disagreement. > > Fixed previously in response to directorate review or by a PR. > > > -4, first paragraph: s/ "... some of the length..." / "... sum of the > length ..." > > As above. > > --001a114fa26624f0880556de7f07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Martin,

On Wed, Aug 16, 2017 at 12:19 AM, Martin Thomson <martin= .thomson@gmail.com> wrote:
= On 16 August 2017 at 13:25, Ben Campbell <ben@nostrum.com> wrote:
> - 1: "For efficiency reasons, multiple users of Web Push often sh= are a
>=C2=A0 =C2=A0 central agent that aggregates push functionality." >
> Is the "central agent" a push server, application server, or= something else?

With Spencer's comment addressed, this is now:

=C2=A0 Multiple users of Web Push at the same user agent often share a
central agent that aggregates push functionality.

Does that make sense now?=C2=A0 PR here:
https://github.com/webpush-wg/webpush-e= ncryption/pull/21


Ben's thre= ad, but Spencer appreciates the clarification.
=C2=A0
> -1: "Web Push messages are the payload of an HTTP message " = - Plural disagreement.

Fixed previously in response to directorate review or by a PR.

> -4, first paragraph: s/ "... some of the length..." / "= ... sum of the length ..."

As above.


--001a114fa26624f0880556de7f07-- From nobody Wed Aug 16 07:42:05 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC811321C7; Wed, 16 Aug 2017 07:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAgRyjx-usPB; Wed, 16 Aug 2017 07:41:48 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ADB91321A7; Wed, 16 Aug 2017 07:41:48 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7GEfhOn061844 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 16 Aug 2017 09:41:44 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Wed, 16 Aug 2017 09:41:44 -0500 Cc: The IESG , draft-ietf-webpush-encryption@ietf.org, Phil Sorber , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <150285392127.12601.16486468628540142046.idtracker@ietfa.amsl.com> To: Martin Thomson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Webpush] Ben Campbell's Yes on draft-ietf-webpush-encryption-08: (with COMMENT) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 14:41:52 -0000 > On Aug 16, 2017, at 12:19 AM, Martin Thomson = wrote: >=20 >> - 1: "For efficiency reasons, multiple users of Web Push often share = a >> central agent that aggregates push functionality." >>=20 >> Is the "central agent" a push server, application server, or = something else? >=20 > With Spencer's comment addressed, this is now: >=20 > Multiple users of Web Push at the same user agent often share a > central agent that aggregates push functionality. >=20 > Does that make sense now? PR here: > https://github.com/webpush-wg/webpush-encryption/pull/21 Maybe?=20 Is the shared =E2=80=9Ccentral agent=E2=80=9D the same as or part of = the =E2=80=9Csame user agent=E2=80=9D? Is it a push server? A shared = session with the push server (i.e. a shared push client as part of the = UA)? To broaden the question: Is this =E2=80=9Ccentral agent=E2=80=9D on the = usual architecture picture for webpush, or is it something different? From nobody Wed Aug 16 07:48:09 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88EE1321C9; Wed, 16 Aug 2017 07:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtwZ3RHQkdSS; Wed, 16 Aug 2017 07:48:00 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 140061321C4; Wed, 16 Aug 2017 07:48:00 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7GEltlp062865 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 16 Aug 2017 09:47:56 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Wed, 16 Aug 2017 09:47:57 -0500 Cc: Adam Roach , Eric Rescorla , draft-ietf-webpush-vapid , Phil Sorber , The IESG , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3302369B-B713-476E-9A17-F1299E749A4D@nostrum.com> References: <150284054989.12518.11340069078773708886.idtracker@ietfa.amsl.com> <4125C183-E369-47EA-999A-0080BDF01B4A@nostrum.com> <716e5820-e57f-b7c9-b3b4-3cf387409575@nostrum.com> <972ccc4e-da47-cb56-addc-ba7b02b94e67@nostrum.com> To: Martin Thomson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Webpush] Breaking Changes (was Re: Eric Rescorla's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT)) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 14:48:02 -0000 > On Aug 16, 2017, at 1:22 AM, Martin Thomson = wrote: >=20 > On 16 August 2017 at 15:41, Adam Roach wrote: >> On 8/16/17 12:09 AM, Martin Thomson wrote: >>>=20 >>> p.s., It's been a while since I've been on the receiving end of the >>> old "your code doesn't matter, you took a risk implementing an I-D" >>> argument. As an argument it kinda stinks. I'm embarrassed to = confess >>> that I've used it in the past, despite reminding myself not to. I'd >>> be interested in learning whether the IESG has an opinion on the >>> subject. A statement of policy might be valuable. >>=20 >> Given that the alternative is effectively forbidding breaking changes = after >> WG adoption -- which is clearly untenable -- I'm not sure what kind = of >> policy you're looking for here. Can you clarify? >=20 > (Hmm, I got this message twice...) >=20 > The usual exchange goes a: "I have code", b: "you implemented an I-D, > that's your problem". >=20 > Some guidance about how to manage this situation would be appreciated. >=20 > I'm not looking for a prohibition on changes at any point in the > process. That's ludicrous, after all, people do understand what it > means to implement an I-D. But statements like "there is code" or > "there is deployed code" are valid and useful input to a discussion > and not just as proof that a given thing is possible. That means > potentially affecting the outcome of a decision. >=20 > In this particular case, the arguments presented weren't problematic, > because the real arguments was actually "well, this change doesn't > seem that bad to me". But it's not the first time someone has opened > with that argument and it annoyed me enough to comment. From nobody Wed Aug 16 08:04:07 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9870A1323F7; Wed, 16 Aug 2017 08:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WE2dl2dU5pUK; Wed, 16 Aug 2017 08:03:58 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52F20132430; Wed, 16 Aug 2017 08:03:43 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7GF3buu065510 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 16 Aug 2017 10:03:38 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Wed, 16 Aug 2017 10:03:37 -0500 Cc: Adam Roach , Eric Rescorla , draft-ietf-webpush-vapid , Phil Sorber , The IESG , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <150284054989.12518.11340069078773708886.idtracker@ietfa.amsl.com> <4125C183-E369-47EA-999A-0080BDF01B4A@nostrum.com> <716e5820-e57f-b7c9-b3b4-3cf387409575@nostrum.com> <972ccc4e-da47-cb56-addc-ba7b02b94e67@nostrum.com> To: Martin Thomson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Webpush] Breaking Changes (was Re: Eric Rescorla's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT)) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 15:04:00 -0000 (Oops ignore the empty message=E2=80=94itchy mousepad finger. Or maybe I = want to make sure Martin gets everything twice.) > On Aug 16, 2017, at 1:22 AM, Martin Thomson = wrote: >=20 > On 16 August 2017 at 15:41, Adam Roach wrote: >> On 8/16/17 12:09 AM, Martin Thomson wrote: >>>=20 >>> p.s., It's been a while since I've been on the receiving end of the >>> old "your code doesn't matter, you took a risk implementing an I-D" >>> argument. As an argument it kinda stinks. I'm embarrassed to = confess >>> that I've used it in the past, despite reminding myself not to. I'd >>> be interested in learning whether the IESG has an opinion on the >>> subject. A statement of policy might be valuable. >>=20 >> Given that the alternative is effectively forbidding breaking changes = after >> WG adoption -- which is clearly untenable -- I'm not sure what kind = of >> policy you're looking for here. Can you clarify? >=20 > (Hmm, I got this message twice...) >=20 > The usual exchange goes a: "I have code", b: "you implemented an I-D, > that's your problem". >=20 > Some guidance about how to manage this situation would be appreciated. >=20 > I'm not looking for a prohibition on changes at any point in the > process. That's ludicrous, after all, people do understand what it > means to implement an I-D. But statements like "there is code" or > "there is deployed code" are valid and useful input to a discussion > and not just as proof that a given thing is possible. That means > potentially affecting the outcome of a decision. >=20 > In this particular case, the arguments presented weren't problematic, > because the real arguments was actually "well, this change doesn't > seem that bad to me". But it's not the first time someone has opened > with that argument and it annoyed me enough to comment. =46rom a general policy perspective, I think there are two principles: 1. The IETF maintains change control on IETF stream documents. That = suggests we can change things at any time. 2. Working code matters. How you balance the two depends on the context. We encourage early code. = But that=E2=80=99s not necessarily the same as encouraging going = production with early code. It=E2=80=99s reasonable to push back on = gratuitous changes if code demonstrates things already work well. But I = think the usual basis of such an argument is that the existing protocol = has been proven to work as is, not that the weight of that code makes it = too hard to change. It=E2=80=99s reasonable to argue that, while a new feature may be of = value, implementors will not deploy it because . That seems = to happen more often with security features than other things, maybe = because the IETF as a whole cares more about security than many = deployment communities. But that=E2=80=99s not really an =E2=80=9Cexisting= code=E2=80=9D argument per se (although existing code can contribute to = it.) There=E2=80=99s a difference between when we choose to standardize = something already in wide deployment, vs when we invent something new = and people deploy code based on drafts. But even that doesn=E2=80=99t = mean we can=E2=80=99t change anything (see principle 1) But in any case, I agree that existing implementations/deployments and = their scope are proper inputs to the discussion. But they are not trump = cards. From nobody Wed Aug 16 08:35:16 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFDA132394; Wed, 16 Aug 2017 08:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s93scSBLvbxx; Wed, 16 Aug 2017 08:35:07 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7C871321C9; Wed, 16 Aug 2017 08:35:07 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id u5so24495091pgn.0; Wed, 16 Aug 2017 08:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jXB/Cvq9NGErFMovmnnxBaVPvdGjksA/2cis7ACF5kI=; b=Ay2hhJSq+bafEYI2W7XhubastqHlBhHlhE7sphSGPHg3TblH0BNbOCYmmRyJAXXGSi jWwrCTaUFbPRSjVpntpkZFDl12rj/Fvb0V1wl1NKz85JNEgUZi7ADn7LvNkIoVcx6kxh Ed56Xr07Gr0pGTR+6Mul43JSA+RMfdj6zVInZ8zxy4TKMZTzKyullHcKrbOw3o1bV2C5 EZer+QQJ9jbez3dS4xvi/DJPD767tBJXDq47QSH/yy5Xe19ZHeYxx+0doKB8Xeh4Qi4J vS1G1Wa9oSUVg28GjI1jBhz0owW2reV/Iop97sMxC8MQOsyA0H0z0IZY/a994Cf/g+An GDIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jXB/Cvq9NGErFMovmnnxBaVPvdGjksA/2cis7ACF5kI=; b=ARZorOI1NKDuQ2N5TzrQRQeEyQd4Sz+2ayxOwiLbOZgwscJfOoBfXuuCkEAxB2s6RA m+kEjg9IVv/TMo8Ru9j4VhG0bY28p6TN/+onoUoeplKmd6srcNlMshWBBpRSrpa0GBo4 KeOW/xPEiji6eCoEdV0dZ+HNoiNEqEA57y787j2fz4yxD6c/EJaPbcO1io392jqq8etd xcuVfEXyn4kcye07TaQII00WEqTfLXQmmWR1jJ2mHJpuapDhAhv5VvarpB8Y6bRJxup/ dMSDzKg62/n9UScjEYZOf8eIGV/e2Ob+fs2jw1brZ8utsPV77jTpWtKtDtk9HVLruuYQ ylTg== X-Gm-Message-State: AHYfb5ibuHL07VcfV/qzrf//LrMXJRl244FBKOEz+aT+CEhlAMy1nC/o qJXduuzaBvzouWK7Gj5HL5OBdU71Dg== X-Received: by 10.98.200.152 with SMTP id i24mr2119399pfk.33.1502897707354; Wed, 16 Aug 2017 08:35:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.144.1 with HTTP; Wed, 16 Aug 2017 08:34:26 -0700 (PDT) In-Reply-To: References: <150282302424.20984.16954614287039839165.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Wed, 16 Aug 2017 11:34:26 -0400 Message-ID: To: Martin Thomson Cc: The IESG , draft-ietf-webpush-vapid , Phil Sorber , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Webpush] Kathleen Moriarty's No Objection on draft-ietf-webpush-vapid-03: (with COMMENT) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 15:35:10 -0000 Hi Martin, On Tue, Aug 15, 2017 at 9:11 PM, Martin Thomson wrote: > On 16 August 2017 at 04:50, Kathleen Moriarty > wrote: >> In section 3, it seems that you are just signing the JWK and that seems fine >> from the text and the purpose listed - origin server authentication. >> >> Then in section 3.2, there's a reference to I-D.ietf-webpush-encryption saying, >> "An application server MUST select a different >> private key for the key exchange". This makes me think that encryption is >> used as well, but I think it would be helpful to see the point made more >> clear here or in the security considerations section. Is confidentiality >> provided/required or just integrity for this draft? > > There are two separate mechanisms. -encryption sends a message to the > user agent. That message has confidentiality and integrity protection > - the push service can't see or modify that message. In the envelope > of that message, we have this JWT. The confidentiality/integrity > protection for that is HTTPS. Confidentiality is required to prevent > theft of the token, as stated in the security considerations. What I > now realize is that I didn't actually reiterate the requirement for > HTTPS from 8030. > > https://github.com/webpush-wg/webpush-vapid/pull/41 Thanks for adding text, there wasn't mention of confidentiality being required or HTTPS in the version I read, so that is a helpful addition. > > The text you cite is included specifically to maybe prevent someone > from incorrectly using the same key for signing (in -vapid) and > encryption (in -encryption). Unfortunately, this specific type of > misuse is possible in a lot of codebases and does happen. OK, if it's possible to edit the cited text to make it more clear, I think that would be helpful to any implementer that comes along later. -- Best regards, Kathleen From nobody Wed Aug 16 08:38:19 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0B81325DD for ; Wed, 16 Aug 2017 08:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuiXNkHe96lb for ; Wed, 16 Aug 2017 08:38:12 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B811C13248F for ; Wed, 16 Aug 2017 08:38:12 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id h68so7625957pfk.0 for ; Wed, 16 Aug 2017 08:38:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=hE2PNgB8htXGYrcSmMD1em6IveW3/R/YOCU6HUoA3O4=; b=NoivklE7/YiWIFVoNjEPXkC4F1GNrs5j0N/Z5cjIFrx2EESiT2uvQtno2jJuvfqUQI R/vWrvA/qbVLtn9+CfBoKW2Tw1Yd6j/4nFZ3hkEKdCt4/bNhrBSH3yd70958t/GvavqJ s4JJdzKkZKZdgjMZU1PVhgBmCZyIBYPxOPFlE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=hE2PNgB8htXGYrcSmMD1em6IveW3/R/YOCU6HUoA3O4=; b=Docey/nSCKLptkoXMkD7D6/6xjmCLweHF2e31c780wUpl3ReSDNp0NHOVJnLGAOytG HLchwtJMaxN79SMWQH61tVaRKFplcH1CNYXiXxFB2b0b63LCsxLWDSRtgWNWC6TgaZ6b HldZBW/5xlKWl5zd0H6MlRrnYelLwgfYy8oVXjEk6+KY1JyV3qh6dmPR7W3uiQdhXMK/ KegEJwY2UFTMW+hvjSQ292Ja2xBpGX/FJeBeVy8NW+8LSlaARH6YatSmqYOW0fTC2dDl hYAmEIdiKzSApswKMxGRE54bd62z1rwb5l33JkvirCzMlLiweRKMYAqg0BiSS/2Adev5 NjAQ== X-Gm-Message-State: AHYfb5i58QxKFM9S+ZiN1S+yXFQnV0TU29rtKDVNHvYpM/7VHYNwakal rE4IEc2HiQSz2xhmFZaVag== X-Received: by 10.84.238.2 with SMTP id u2mr2295035plk.169.1502897891047; Wed, 16 Aug 2017 08:38:11 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:f591:311:94cf:3f06? ([2620:101:80fc:224:f591:311:94cf:3f06]) by smtp.gmail.com with ESMTPSA id x1sm2606124pgt.82.2017.08.16.08.38.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 08:38:09 -0700 (PDT) To: webpush@ietf.org References: <150284054989.12518.11340069078773708886.idtracker@ietfa.amsl.com> <4125C183-E369-47EA-999A-0080BDF01B4A@nostrum.com> <716e5820-e57f-b7c9-b3b4-3cf387409575@nostrum.com> From: jr conlin Message-ID: <2bb56ca6-a1e9-b6e7-c7fe-8253ba89800e@mozilla.com> Date: Wed, 16 Aug 2017 08:38:06 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:54.0) Gecko/20100101 Thunderbird/54.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4A20FDF05678A99DDDDA0199" Content-Language: en-US Archived-At: Subject: Re: [Webpush] Eric Rescorla's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 15:38:18 -0000 This is a multi-part message in MIME format. --------------4A20FDF05678A99DDDDA0199 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit If I may lend a bit of prospective from the point of view of the Push Service provider. We enjoy VAPID because it provides us a way to associate contact information with the data we receive. It's (in theory) voluntary, and we can prefer feeds that provide the data. VAPID provides us a reasonably low cost means to "validate" the information we get *if* the requested URI was secured using the same key, as well as prove that there has been no casual MITM alterations of data. As Martin notes, the bar is set fairly high for an attacker sending malicious data to the remote customer. >From our point of view, VAPID isn't really a security device, it's a contact device. It's equivalent to someone stapling their business card to their letter, and is most useful for our ops folk when things go awry. That's why we accept feeds that use VAPID even if the requested URI was not secured. In addition, our most pressing concern is with sites that perform non-hostile abuse. (e.g. we currently get near 2:1 traffic from sites sending to URIs that are no longer active, and do not provide good ways to contact their operations.) That said, we still encourage frankly horrible security practices around VAPID just so that the barrier to use is as low as possible. We find the data to still be that useful. For example, we encourage application servers to cache the VAPID header for as long as possible to reduce the publication load. Naturally, we look forward to the guidance provided by the working group and will adopt their suggestions, but I did want to offer what the more hands-on usage of the spec has been so far. On 8/16/17 5:55 AM, Eric Rescorla wrote: > > > On Tue, Aug 15, 2017 at 10:09 PM, Martin Thomson > > wrote: > > On 16 August 2017 at 12:35, Adam Roach > wrote: > > On 8/15/17 9:31 PM, Ben Campbell wrote: > >> > >> My knee jerk response is to agree with Ekr. But it’s worth > discussing how > >> big of an incompatibility with existing code people are talking > about. Are > >> there a lot of deployed services that support vapid? Do people > think that > >> existing implementors will choose not to implement/deploy the > additional > >> protection? > > > > > > > > My inclination is to ask the WG to weigh in on this issue in > particular. > > I've received some pretty confident responses indicating that > VAPID has no > > issues with crypto-agility. Given that such is the case, it > seems like the > > question of how many deployed implementations we have is pretty > irrelevant: > > if we can't change crypto schemes at scale, then we shouldn't > publish this > > document anyway. > > No change is free. We'd first have to establish whether the change is > a net gain. > > The presumption here seems to be that the presented design is > unconditionally superior. That's not true. This is a trade-off, and > - in my opinion - not one that favours any change. > > For me the important point here is that the proposed change (in any > form) is of fairly marginal value. Yes, the IETF is investing in > anti-bearer-token-theft technology, but in this case what you get is > the ability to send a message to user agent and wake it up. > > You get that after stealing two pieces of information: the push > subscription URI and this token. (That's assuming that the first was > not already sufficient, which it is in some cases.) You can't send > arbitrary data, for that you need two more pieces of information: a > public key and authorization code, and neither of these appear on the > HTTPS connection from which the other items were stolen. > > > This is a rather odd argument, as it also applies to the mechanism in > this document as a whole. > > > So that's benefits. Let's talk about costs. > > If we take the suggested design the biggest challenge is key > management for K_p (the key that the push service would have to > maintain). Maintaining a set of keys across a globally-distributed > service isn't free. Given that key compromise would undermine the > effort we'd be putting in here, you also need a strategy for updating > those keys and revocation of old or compromised keys. For that you > want multiple keys, which means key identifiers in messages. You also > need some way of having application servers update their view of what > keys are current, maybe using expiration times. > > > You raise several issues here: > > 1. The cost of coordinating the key. I agree that this is a real cost > to the mechanism I proposed here, though it's possible to mitigate it > in a number of ways (e.g., by having a centralized oracle for doing > the verification, given that you don't need to do a lot of EC > computation here). > > 2. The need for revocation. You don't actually need that here, just a > key update mechanism and a way to tell the app server "use this new > key". But this latter mechanism is the same one you use for key > updates and for updates to the mechanism, which this document implies > the WG thinks is easy. > > 3. Key identifiers in messages are just specification work, so I don't > think that that's a strong argument (see below). > > 4. Yes, it's a concern if these keys are compromised, but note that > even if that's so, the security of the system reduces back to a bearer > token (because you need the DH public key and the signed JWT), so that > doesn't seem like much of a cost. > > > Technically, we also have to work out what to cover with the MAC. My > experience with HTTP and signing suggests that this isn't as trivial > as it might seem. I think that we could canonicalize the push > subscription URI, Content-Encoding header field and payload and be > reasonably sure that the MAC couldn't be transplanted. Probably also > the RFC 8030 TTL, Urgency and Topic header fields, which suggests that > there needs to be a way to sign any new and relevant header fields > that might be added later. This would need some more analysis than > I've given it here. > > > I agree that there are complexities here, but they're complexities > that are motivated by actually trying to design something with > stronger security properties. More generally, they are costs to the > WG, but not really costs to the world at large. > > > Finally, I think this discussion has ratholed a bit on this particular > counter-proposal. My point isn't that you should do this particular > thing but rather that it seems like the WG decided on a bearer-token > model without giving sufficient consideration to alternatives that > have better security (of which this is merely one). The fact that I > was able to produce two such alternatives in a few hours (which I'll > concede are not in every way superior) and your response was not "yes, > we considered those and here is a pointer to the WG archives" seems to > lend that point some plausibility. > > As I said initially, this is ultimately a WG decision and I'm fine > with being told by the ADs and the Chairs that they believe sufficient > consideration has been given, in which case I'll withdraw my discuss. > So far I haven't heard that. > > -Ekr > > p.s., It's been a while since I've been on the receiving end of the > old "your code doesn't matter, you took a risk implementing an I-D" > argument. As an argument it kinda stinks. I'm embarrassed to confess > that I've used it in the past, despite reminding myself not to. > > > I think I explicitly labelled this argument as flippant, but I also > don't think it's valueless, especially when put up against "Three > large companies implemented and are too lazy to change". > > > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush --------------4A20FDF05678A99DDDDA0199 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
If I may lend a bit of prospective from the point of view of the Push Service provider.

We enjoy VAPID because it provides us a way to associate contact information with the data we receive. It's (in theory) voluntary, and we can prefer feeds that provide the data. VAPID provides us a reasonably low cost means to "validate" the information we get *if* the requested URI was secured using the same key, as well as prove that there has been no casual MITM alterations of data. As Martin notes, the bar is set fairly high for an attacker sending malicious data to the remote customer.

From our point of view, VAPID isn't really a security device, it's a contact device. It's equivalent to someone stapling their business card to their letter, and is most useful for our ops folk when things go awry. That's why we accept feeds that use VAPID even if the requested URI was not secured. In addition, our most pressing concern is with sites that perform non-hostile abuse. (e.g. we currently get near 2:1 traffic from sites sending to URIs that are no longer active, and do not provide good ways to contact their operations.)

That said, we still encourage frankly horrible security practices around VAPID just so that the barrier to use is as low as possible. We find the data to still be that useful. For example, we encourage application servers to cache the VAPID header for as long as possible to reduce the publication load.

Naturally, we look forward to the guidance provided by the working group and will adopt their suggestions, but I did want to offer what the more hands-on usage of the spec has been so far.

On 8/16/17 5:55 AM, Eric Rescorla wrote:


On Tue, Aug 15, 2017 at 10:09 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 16 August 2017 at 12:35, Adam Roach <adam@nostrum.com> wrote:
> On 8/15/17 9:31 PM, Ben Campbell wrote:
>>
>> My knee jerk response is to agree with Ekr. But it’s worth discussing how
>> big of an incompatibility with existing code people are talking about. Are
>> there a lot of deployed services that support vapid? Do people think that
>> existing implementors will choose not to implement/deploy the additional
>> protection?
>
>
>
> My inclination is to ask the WG to weigh in on this issue in particular.
> I've received some pretty confident responses indicating that VAPID has no
> issues with crypto-agility. Given that such is the case, it seems like the
> question of how many deployed implementations we have is pretty irrelevant:
> if we can't change crypto schemes at scale, then we shouldn't publish this
> document anyway.

No change is free.  We'd first have to establish whether the change is
a net gain.

The presumption here seems to be that the presented design is
unconditionally superior.  That's not true.  This is a trade-off, and
- in my opinion - not one that favours any change.

For me the important point here is that the proposed change (in any
form) is of fairly marginal value.  Yes, the IETF is investing in
anti-bearer-token-theft technology, but in this case what you get is
the ability to send a message to user agent and wake it up.

You get that after stealing two pieces of information: the push
subscription URI and this token.  (That's assuming that the first was
not already sufficient, which it is in some cases.)  You can't send
arbitrary data, for that you need two more pieces of information: a
public key and authorization code, and neither of these appear on the
HTTPS connection from which the other items were stolen.

This is a rather odd argument, as it also applies to the mechanism in this document as a whole.


So that's benefits.  Let's talk about costs.

If we take the suggested design the biggest challenge is key
management for K_p (the key that the push service would have to
maintain).  Maintaining a set of keys across a globally-distributed
service isn't free.  Given that key compromise would undermine the
effort we'd be putting in here, you also need a strategy for updating
those keys and revocation of old or compromised keys.  For that you
want multiple keys, which means key identifiers in messages.  You also
need some way of having application servers update their view of what
keys are current, maybe using expiration times.

You raise several issues here:

1. The cost of coordinating the key. I agree that this is a real cost to the mechanism I proposed here, though it's possible to mitigate it in a number of ways (e.g., by having a centralized oracle for doing the verification, given that you don't need to do a lot of EC computation here).  

2. The need for revocation. You don't actually need that here, just a key update mechanism and a way to tell the app server "use this new key". But this latter mechanism is the same one you use for key updates and for updates to the mechanism, which this document implies the WG thinks is easy.

3. Key identifiers in messages are just specification work, so I don't think that that's a strong argument (see below).

4. Yes, it's a concern if these keys are compromised, but note that even if that's so, the security of the system reduces back to a bearer token (because you need the DH public key and the signed JWT), so that doesn't seem like much of a cost.


Technically, we also have to work out what to cover with the MAC.  My
experience with HTTP and signing suggests that this isn't as trivial
as it might seem.  I think that we could canonicalize the push
subscription URI, Content-Encoding header field and payload and be
reasonably sure that the MAC couldn't be transplanted.  Probably also
the RFC 8030 TTL, Urgency and Topic header fields, which suggests that
there needs to be a way to sign any new and relevant header fields
that might be added later.  This would need some more analysis than
I've given it here.

I agree that there are complexities here, but they're complexities that are motivated by actually trying to design something with stronger security properties. More generally, they are costs to the WG, but not really costs to the world at large.


Finally, I think this discussion has ratholed a bit on this particular counter-proposal. My point isn't that you should do this particular thing but rather that it seems like the WG decided on a bearer-token model without giving sufficient consideration to alternatives that have better security (of which this is merely one). The fact that I was able to produce two such alternatives in a few hours (which I'll concede are not in every way superior) and your response was not "yes, we considered those and here is a pointer to the WG archives" seems to lend that point some plausibility.

As I said initially, this is ultimately a WG decision and I'm fine with being told by the ADs and the Chairs that they believe sufficient consideration has been given, in which case I'll withdraw my discuss. So far I haven't heard that.

-Ekr

p.s., It's been a while since I've been on the receiving end of the
old "your code doesn't matter, you took a risk implementing an I-D"
argument.  As an argument it kinda stinks.  I'm embarrassed to confess
that I've used it in the past, despite reminding myself not to. 

I think I explicitly labelled this argument as flippant, but I also don't think it's valueless, especially when put up against "Three large companies implemented and are too lazy to change".




_______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush


--------------4A20FDF05678A99DDDDA0199-- From nobody Wed Aug 16 08:52:52 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF398132626; Wed, 16 Aug 2017 08:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14xWINgYJRzA; Wed, 16 Aug 2017 08:52:48 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE6AF132195; Wed, 16 Aug 2017 08:52:48 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7GFqhQq074042 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 16 Aug 2017 10:52:44 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Wed, 16 Aug 2017 10:52:42 -0500 Cc: The IESG , draft-ietf-webpush-vapid , Phil Sorber , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <150285009047.12577.1184580798882485308.idtracker@ietfa.amsl.com> To: Martin Thomson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Webpush] Ben Campbell's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 15:52:51 -0000 > On Aug 16, 2017, at 1:09 AM, Martin Thomson = wrote: >=20 > Hi Ben, >=20 > I've collected the changes mentioned below into a PR here: > https://github.com/webpush-wg/webpush-vapid/pull/44 That mostly looks good, modulo discussion below. I think you dropped the = word =E2=80=9Cmeaning=E2=80=9D from the 8174 (was 2119) reference. Also, = that RFC recommends specific boilerplate. (I=E2=80=99m not going to get = wrapped around whether you use that specific boilerplate, as long as the = meaning is clear.) >=20 > On 16 August 2017 at 12:21, Ben Campbell wrote: >> In section 2: "A push service MAY reject a request with a 403 = (Forbidden) status >> code [RFC7235] if the JWT signature or its claims are invalid." >>=20 >> This seems to leave the possibility of simply ignoring an invalid = VAPID token >> or signature. Assuming we are talking about push servers that support >> VAPID in the first place, that seems dangerous. Wouldn't it be safer = in >> the general case to treat a request with an invalid VAPID token as at >> least a bit fishy? >>=20 >> I don't mean to say that ignoring the token is never the right thing = to >> do. But the MAY seems week without some guidance on what other = actions >> might be reasonable under what circumstances. >=20 > I think that "MAY" is entirely appropriate given the non-blocking > nature of the mechanism. A push service might look at the header > field, but not require the token. Maybe they just wanted to attach an > email address to a stream of messages (that's what we do). I think there=E2=80=99s a fundamental difference between not validating = in the first place, and ignoring a failed validation. My point is not to = say that ignoring it is the wrong thing to do, just that I think some = more elaboration here is needed. Would it make sense to say something of = the effect of =E2=80=9CSHOULD NOT use the information from a token that = has failed validation=E2=80=9D? [=E2=80=A6] >> "Some implementations permit the same P-256 key to be used for = signing >> and key exchange. An application server MUST select a different = private >> key for the key exchange [I-D.ietf-webpush-encryption] and signing = the >> authentication token." >>=20 >> I don't understand the intent here. It seems to say some = implementations >> do this, but MUST not. Does "implementations" refer to VAPID or >> something else? >=20 > In NSS and many elliptic curve libraries, you can create an EC key for > P-256. You can then use that key for signing AND key exchange. You > shouldn't though. Would it make sense to say =E2=80=9CSome library implementations=E2=80=A6=E2= =80=9D? [=E2=80=A6] >=20 >> - 4.2: "A push service MUST reject a message that omits mandatory >> credentials with a 401 (Unauthorized) status code. " >>=20 >> This was already stated in section 2. Please avoid repeating = normative >> text, as it creates ambiguity about which text is authoritative, and = can >> complicate future updates. This section seems the more detailed, so = perhaps >> section 2 could avoid the 2119 text. (But see my DISCUSS point on = section 2.) >=20 > This isn't included in Section 2. Section 2 defines what a valid > token is. Oops, that was a cut and paste error. I meant to quote the following = sentence:=20 " A push service MAY reject a message that includes invalid credentials with a 403 (Forbidden) status code. " > This section defines behaviour in the case that a > subscription is limited to a particular application server key. I > realize now that this might have been unclear, so I have reworded to: >=20 > "A push service MUST reject a message sent to a restricted push = subscription if > that message includes no "vapid" authentication or invalid "vapid" > authentication. A 401 (Unauthorized) status code might be used if the > authentication is absent; a 403 (Forbidden) status code might be used = if > authentication is invalid." >=20 > This also allows me to clear up a minor gripe about the prescriptive > nature of the text regarding status codes. I like that paragraph better, but does it conflict with the text in = section 2, as discussed in my DISCUSS? [=E2=80=A6] >=20 >> - 6.3: Don't we usually list the IESG as the change controller? >=20 > I'm mostly cargo-culting here. This choice didn't elicit comment when > I asked for media-type review. >=20 > For reference, the last one of these that went through the IESG came > back with very specific instructions, and a citation. I can't find > that email, or the citation, but I think that it was RFC 6838, Section > 3.1, which doesn't seem particularly crisp: >=20 > The "owner" of a media type registered in the standards tree is > assumed to be the standards-related organization itself. >=20 > I did find the documents that I remember: RFCs 8142 and 7946 use > "Internet Engineering Task Force" and "IETF" respectively. It seems > like this isn't entirely consistent though. I will accept the wisdom > of the IESG on this matter. I=E2=80=99ll go with Alexey=E2=80=99s separate response. That is, never = mind. From nobody Wed Aug 16 09:10:36 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13951132630; Wed, 16 Aug 2017 09:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKIN2c3YgmTi; Wed, 16 Aug 2017 09:10:33 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C97A11321A0; Wed, 16 Aug 2017 09:10:32 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id d207so713205qkg.2; Wed, 16 Aug 2017 09:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eQSnHSQrKxI/TpHCmKtV6Wh8zO3vAJquCLm4pOTRtfQ=; b=Ai1jFz1yLqdC6tPK9xA3hHh5/mX0kotZXwGx5TbgV80iEW5+MNXOrap5e4M4GyeZdh 0fLYw8GcicdRP6Y7+IE0hxN2LzBPMeOcc/Z0qLbqmYnzdAQFlMlyTrANktR158LZI+AL WBCxYb35KePgZEl+i4Oaka6hPWHiJkClPiK3L3s9kV0ikK1FUM0doW/BeshSZIascTWN U4KLn33wC3EgpApJBEcX9E6Dp7L15HbAZxczhjobVPgpexJAD9YCHpfY+G1IIQ7kNOuQ O32aTzuriQojrOQ6MSGCWL8oQhi45gvyvAB+JPeXtNFKBv6hSB84ImQBpUrjWgdAFf47 cSFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eQSnHSQrKxI/TpHCmKtV6Wh8zO3vAJquCLm4pOTRtfQ=; b=YvmikGJaOdmXz4JLqiwKeoQhy7ddAWYJP+UTsvoM8v28CVfsWojjsHl0bMTjN9fYVy qWeGJB5GnDqvsdWmh66W+Y9YqaS5pMvNvwWJkALjTkl4ro7xL+vyyHmu4v/zyF7Bp29F 2xNkb2iKujzS44BLrXEeXZLxR2t1tR+DG898cQF6DcOLe4qyMXZy79Pkk53b4tpa+1Xw MNNVpn10HhEyPcG4SQVTW0PGTBMbJORj3wu+tcDV1og0bFgqSLkjXxwL60qR9tyYB7t/ LeeEz5A1RZs/O1vKNs6wtY6CCvR1kkaR0Jg+P3P9jhaumBhnPGEsXtVyCKAiQLf0rnV5 R2Zw== X-Gm-Message-State: AHYfb5idegCrpCcleZkSCI8v082HfqMX7iXjaoKhHrfjI8LN1APHwk7v bNAAeNVPCK9YpaA3/GQHoz0D9ImzSA== X-Received: by 10.55.20.220 with SMTP id 89mr2792938qku.94.1502899831760; Wed, 16 Aug 2017 09:10:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.59.248 with HTTP; Wed, 16 Aug 2017 09:10:01 -0700 (PDT) In-Reply-To: References: <150284054989.12518.11340069078773708886.idtracker@ietfa.amsl.com> <4125C183-E369-47EA-999A-0080BDF01B4A@nostrum.com> <716e5820-e57f-b7c9-b3b4-3cf387409575@nostrum.com> <972ccc4e-da47-cb56-addc-ba7b02b94e67@nostrum.com> From: Ted Hardie Date: Wed, 16 Aug 2017 09:10:01 -0700 Message-ID: To: Ben Campbell Cc: Martin Thomson , Eric Rescorla , Adam Roach , draft-ietf-webpush-vapid , Phil Sorber , The IESG , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Type: multipart/alternative; boundary="001a1144c1949aedb00556e12299" Archived-At: Subject: Re: [Webpush] Breaking Changes (was Re: Eric Rescorla's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT)) X-BeenThere: webpush@ietf.org 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, 16 Aug 2017 16:10:35 -0000 --001a1144c1949aedb00556e12299 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 16, 2017 at 8:03 AM, Ben Campbell wrote: > From a general policy perspective, I think there are two principles: > > 1. The IETF maintains change control on IETF stream documents. That > suggests we can change things at any time. > > 2. Working code matters. > > How you balance the two depends on the context. We encourage early code. > But that=E2=80=99s not necessarily the same as encouraging going producti= on with > early code. It=E2=80=99s reasonable to push back on gratuitous changes if= code > demonstrates things already work well. But I think the usual basis of suc= h > an argument is that the existing protocol has been proven to work as is, > not that the weight of that code makes it too hard to change. > > I think one way of looking at the context is to look at the reason for the code. Code built explicitly to test a particular approach can change at any time that the approach needs to change; we get to presume that sort of code doesn't underpin any running systems and that the friction to change is thus very low. Code that is currently deployed in production systems can be very difficult to change and deciding to change it may break interoperability. In some cases it may permanently change the community of use for a protocol (some changes to JSEP, for example, would break its ability to interoperate with deployed non-browser systems, thus changing the community of use). The reality is that there almost no code purely in category one and a lot of IETF draft code hasn't been deployed at scale enough to be in category two. Lars' and Christian's implementation of QUIC demonstrate that one isn't gone completely, but almost all code written for IETF standards is intended for production systems eventually. It lives in a gray area between the two poles above; changing it requires resources and time but does not change deployed systems. Changes are costs, in other words, that are incurred by the developer prior to getting to deploy. Pushing back on changes to "gray code" is entirely normal, and you can see that play out inside working groups as different parties determine whose code has to change to meet a requirement or solve a problem. Inside a working group, the weight of the code does matter. A two-line changes to a server may result in the same behavior as a new module for the client, and the working group should take that into account. Where the IESG analysis is a bit different is that it has to take into account the value of the change not just to the current writers of code, but for anyone implementing the spec later and to the users of the protocol. That change in context of interpretation tends to make the IESG a bit more willing to require changes to gray code than a working group would be; its collective thumb is lightly on the scale of the future implementers and users. I personally think that's a reasonable result and part of the division of labor, but I also think the IESG has to do so knowingly and make that transparent to the community. That means that we probably should drop "you paid your money and knew the risks" as messaging for late code change. Perhaps "we recognize the costs here but believe they are balanced, especially when considering new implementations which may arise" would be better PR. Take that advice with a large grain of salt, though, as no one has ever suggested I was good at PR. regards, Ted --001a1144c1949aedb00556e12299 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Aug 16, 2017 at 8:0= 3 AM, Ben Campbell <ben@nostrum.com> wrote:
From a general policy perspectiv= e, I think there are two principles:

1. The IETF maintains change control on IETF stream documents. That suggest= s we can change things at any time.

2. Working code matters.

How you balance the two depends on the context. We encourage early code. Bu= t that=E2=80=99s not necessarily the same as encouraging going production w= ith early code. It=E2=80=99s reasonable to push back on gratuitous changes = if code demonstrates things already work well. But I think the usual basis = of such an argument is that the existing protocol has been proven to work a= s is, not that the weight of that code makes it too hard to change.


I think one way of looking at the cont= ext is to look at the reason for the code.=C2=A0

Code built explici= tly to test a particular approach can change at any time that the approach = needs to change; we get to presume that sort of code doesn't underpin a= ny running systems and that the friction to change is thus very low.
Code that is currently deployed in production systems can be ve= ry difficult to change and deciding to change it may break interoperability= . In some cases it may permanently change the community of use for a protoc= ol (some changes to JSEP, for example, would break its ability to interoper= ate with deployed non-browser systems, thus changing the community of use).=

The reality is that there almost no code pure= ly in category one and a lot of IETF draft code hasn't been deployed at= scale enough to be in category two.=C2=A0=C2=A0 Lars' and Christian= 9;s implementation of QUIC demonstrate that one isn't gone completely, = but almost all code written for IETF standards is intended for production s= ystems eventually.=C2=A0 It lives in a gray area between the two poles abov= e; changing it requires resources and time but does not change deployed sys= tems.=C2=A0 Changes are costs, in other words, that are incurred by the dev= eloper prior to getting to deploy.

=C2=A0Pushi= ng back on changes to "gray code" is entirely normal, and you can= see that play out inside working groups as different parties determine who= se code has to change to meet a requirement or solve a problem.=C2=A0 Insid= e a working group, the weight of the code does matter.=C2=A0 A two-line cha= nges to a server may result in the same behavior as a new module for the cl= ient, and the working group should take that into account.=C2=A0

Where the IESG analysis is a bit different is that it has to take = into account the value of the change not just to the current writers of cod= e, but for anyone implementing the spec later and to the users of the proto= col.=C2=A0 That change in context of interpretation tends to make the IESG = a bit more willing to require changes to gray code than a working group wou= ld be; its collective thumb is lightly on the scale of the future implement= ers and users.

I personally think that's a reasonable= result and part of the division of labor, but I also think the IESG has to= do so knowingly and make that transparent to the community.=C2=A0 That mea= ns that we probably should drop "you paid your money and knew the risk= s" as messaging for late code change.=C2=A0 Perhaps "we recognize= the costs here but believe they are balanced, especially when considering = new implementations which may arise" would be better PR.

=
Take that advice with a large grain of salt, though, as no one has eve= r suggested I was good at PR.

regards,

= Ted

--001a1144c1949aedb00556e12299-- From nobody Wed Aug 16 17:44:09 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60548132386; Wed, 16 Aug 2017 17:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kpzPQgQDPEp; Wed, 16 Aug 2017 17:44:05 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 544E8126DD9; Wed, 16 Aug 2017 17:44:05 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id 76so24869093ith.0; Wed, 16 Aug 2017 17:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=GH7ZIE8tjuB9soCHbM3YMWIkp2svo/mlOQX45OtUPZo=; b=ACUkRA6hAT/x3LMZe2Hs6Ty1mB25X3OfchFdchqOWOYkIvYh62C+AG1F3fAeXRuVLd VCwS4iJGWP90WNsPcE4X5HHpyx/rluTf8p/ezrCwU1wg84k51T3hjmh6rRq/GP8I+P4F wkPlAZGdBi4x0arVrZL2ld4su1OZuoTp/vQujz9Ek11NYtAS+iPpRqqYcVOt5ezTiNpX wkDpUCq5F2JsJJ3CmIteULCqcgvWrMKFt7R1bTcR4T9YJOhoTfmve0AcGylMo6laTI7C RuLhi/mFaZzlgMAq6sqeK4n1HscDvdonaolC1zPDd4ROP6ewQADyDdbm9uXfCvyCBTfb rE/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=GH7ZIE8tjuB9soCHbM3YMWIkp2svo/mlOQX45OtUPZo=; b=Z/4L9WSq2XyYdyZshernk9C39Wg2ED3fwcE7zCbUSuRJ1RRnCI87k5hROoXhFrUVog pVRc1zGHSxUl3ATYb18LQgcisGfFtjQZaaiDaOHADzKXgd0wpPQgoqS2SpmiqLho5z6h R12YydLFVBKm1nlBiFs1FCLm4aHJ/pA2PRbgPWucfChDY8fgswkhn/DpU7+wq+JbVXng xF9Qbw7Tpd7U7sF0cxqQrfIJt/2/CVnRxUItwm6NNkUSNuJ9gb1+885H9ENVmMt+Xg76 mqCkkYRvijonBVW1WOUIJlcWPTAYWUnNcObQcKU10t41F2SAmpCstjWVehx8NhEHkCCj P0Fg== X-Gm-Message-State: AHYfb5izEiZa9CEijkOhXmIgHAbfQhYGHbIPSyNObD238xqdw1YDArFB GZBTZH2SMupHbkmBBbL5+UV7RLxYyg== X-Received: by 10.36.193.199 with SMTP id e190mr282730itg.122.1502930644693; Wed, 16 Aug 2017 17:44:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Wed, 16 Aug 2017 17:44:03 -0700 (PDT) In-Reply-To: References: <150285392127.12601.16486468628540142046.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Thu, 17 Aug 2017 10:44:03 +1000 Message-ID: To: Ben Campbell Cc: The IESG , draft-ietf-webpush-encryption@ietf.org, Phil Sorber , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Webpush] Ben Campbell's Yes on draft-ietf-webpush-encryption-08: (with COMMENT) X-BeenThere: webpush@ietf.org 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: Thu, 17 Aug 2017 00:44:07 -0000 On 17 August 2017 at 00:41, Ben Campbell wrote: > Is the shared =E2=80=9Ccentral agent=E2=80=9D the same as or part of the= =E2=80=9Csame user agent=E2=80=9D? Is it a push server? A shared session w= ith the push server (i.e. a shared push client as part of the UA)? Think common library, daemon process, or system service. > To broaden the question: Is this =E2=80=9Ccentral agent=E2=80=9D on the u= sual architecture picture for webpush, or is it something different? It's an implementation detail on the user agent. From nobody Wed Aug 16 17:45:40 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABE81323C0; Wed, 16 Aug 2017 17:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUsxhjgRBkqW; Wed, 16 Aug 2017 17:45:30 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47663132386; Wed, 16 Aug 2017 17:45:30 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id 76so24468257ith.0; Wed, 16 Aug 2017 17:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CxhErxl3ontWNWY4L/5h9fo113OKEP2KFANYh3Rp/b8=; b=KKnCuYTpP1v/2GJzAOFbSdATiO/4Mh/pzEc9xGAUK+EHOpugdlSSYaGnQEG2httL96 2C42ovbHDuAtmBwfk7dGSq9RD9iyOl372+QYqXlswnfXe2c960bxQCVDeqfMoQZ+PvpI 5xZvkj8lwhYy5dfsWk9XzIyDuudpTIr2lFiL7RYMyDW/bAS9VzmLM5I2+d0IWNezYp97 OpmQxbWfKHKqjssgNgM1k34wBdhCA1UbDB9aWMC8unEh1atf7qZh+GZy/ThQDDnA1Ly8 8Am5TD38yoj7H1yJ8aVSp/e7GOFz/4kDO3YAoXWsSuU3NyZE5YmgvIY1RV6ZyOVlp9EK k1Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CxhErxl3ontWNWY4L/5h9fo113OKEP2KFANYh3Rp/b8=; b=DfLT3x+yMulAbQJ/1zyKJru/OmmQH+u5LTKqkWNhcPNotLAdRCli1Z7fV2oIqdOmct f+/DXMTsBkU7c670jpq1MSptYmxK/AaGQCoEW7Yy+XhpkJBOMNga+T5kBIdrptsfpjlX ++7t3I5netDjvL8Im/XUsbc2Gh32p2XW8M84KzoS6BjKbIta+lYfCRe/1EuMyeHs225W vBheOVq4L7ePQ+9nPWwUj76Hu81cDFm20N9N+S/Ft2kjuE39w5uZlxkRiVErDT+dblS3 J4UZ8FPnbpdU+t2ii58fLngku4/1goPxxH8+mebI28TkPJM+yZhVZ45aU8M/BULwHzk/ paRw== X-Gm-Message-State: AHYfb5gMkg5SDPSb5Rr+t4HUUFBFn+Vayt7lA1cGMsrDDmEezxRgeSFy tDmfpbKh8+PhvRR0eIrjje+8g/ywTbYBD70= X-Received: by 10.36.13.10 with SMTP id 10mr284505itx.51.1502930729682; Wed, 16 Aug 2017 17:45:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Wed, 16 Aug 2017 17:45:29 -0700 (PDT) In-Reply-To: References: <150282302424.20984.16954614287039839165.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Thu, 17 Aug 2017 10:45:29 +1000 Message-ID: To: Kathleen Moriarty Cc: The IESG , draft-ietf-webpush-vapid , Phil Sorber , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Webpush] Kathleen Moriarty's No Objection on draft-ietf-webpush-vapid-03: (with COMMENT) X-BeenThere: webpush@ietf.org 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: Thu, 17 Aug 2017 00:45:33 -0000 On 17 August 2017 at 01:34, Kathleen Moriarty wrote: >> The text you cite is included specifically to maybe prevent someone >> from incorrectly using the same key for signing (in -vapid) and >> encryption (in -encryption). Unfortunately, this specific type of >> misuse is possible in a lot of codebases and does happen. > > OK, if it's possible to edit the cited text to make it more clear, I > think that would be helpful to any implementer that comes along later. I made a change in response to Ben's review that might help: https://github.com/webpush-wg/webpush-vapid/pull/44/commits/3269c22c083793b52da9dff51273843e3dc0d3f7 From nobody Wed Aug 16 17:53:42 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6631323C0; Wed, 16 Aug 2017 17:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m263RlRnZ1by; Wed, 16 Aug 2017 17:53:38 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D42AE1323B6; Wed, 16 Aug 2017 17:53:37 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id m88so18478940iod.2; Wed, 16 Aug 2017 17:53:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9fnjha1otMAk3MCJZYVsy4ImZ2jdBlDkz3ZZLlyogeM=; b=k8VpfzTVg9W8oEIYbOeCwcDLKqdQHAuWGkaNrTTeU+8tGk9bcndG3K+4mWQu3Iy6kZ NhJgo/QAnXXDyX74N7yCZseHsWz/R1BQ0JGy7MhvfzR3Z+jFctWezKNpBxErtWYJ1dHA Agfvpc5voHmW6xMnuKwBM4ODRhkN34pV1wawVz+HiCxY3xJSxZvIF17Jw6iUJGt/PGJA Y3A6jhBKfgT0PBPCbd32zQRCZsJrmW5+cOgffmEab+pH5btcg2k5HOTtzsGNll7Fb1AO HBk8a1cjAyJvRCpjBmYFmtz4o3L5WkPKhHJboNQOPEAK2hLgcd2qQFGP1JH36T3qJfXQ TVuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9fnjha1otMAk3MCJZYVsy4ImZ2jdBlDkz3ZZLlyogeM=; b=R0ph3kND2d/iU0/PwsJqUsNy9byMmf5v8r83LZJ1t2P/j4QAMGxnlyFL703ezt+B5E 9R7C985jQW0a28wK8akPkAgkuy4rPEN/BT3TgQSmNcJGwvkc/xSGtKKqVCV3OYQKpWxY IbRDWHHPDvWcTiacO++3u4h06ijIl1uEV0cSLryBB534ib/COKnPKcoPv4wTLHt+NhBm XfV7QOiECD/8GSAOFKXFt/bRrVBgo39R599iY+zUuq+VOjl3IJKi8DaTHkzvubHVbHt4 KAJyUO84tzW04LZdLj5vUnmD7DNh8dQwWKHVTx5UWYyr25RERz7hvIZafh1k9tR4vhPk 4UIw== X-Gm-Message-State: AHYfb5hDjUVD7P7P7sJSewJOCeJhHmSlzb6GlKw8tAp4aozEYKBse42S QmZfq0FFnFVSoNuNIgo+U2TINkHw1w== X-Received: by 10.107.137.30 with SMTP id l30mr3519818iod.279.1502931217228; Wed, 16 Aug 2017 17:53:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Wed, 16 Aug 2017 17:53:36 -0700 (PDT) In-Reply-To: References: <150284054989.12518.11340069078773708886.idtracker@ietfa.amsl.com> <4125C183-E369-47EA-999A-0080BDF01B4A@nostrum.com> <716e5820-e57f-b7c9-b3b4-3cf387409575@nostrum.com> From: Martin Thomson Date: Thu, 17 Aug 2017 10:53:36 +1000 Message-ID: To: Eric Rescorla Cc: Adam Roach , Ben Campbell , draft-ietf-webpush-vapid , Phil Sorber , The IESG , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Webpush] Eric Rescorla's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT) X-BeenThere: webpush@ietf.org 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: Thu, 17 Aug 2017 00:53:40 -0000 On 16 August 2017 at 22:55, Eric Rescorla wrote: > Finally, I think this discussion has ratholed a bit on this particular > counter-proposal. My point isn't that you should do this particular thing > but rather that it seems like the WG decided on a bearer-token model without > giving sufficient consideration to alternatives that have better security > (of which this is merely one). The fact that I was able to produce two such > alternatives in a few hours (which I'll concede are not in every way > superior) and your response was not "yes, we considered those and here is a > pointer to the WG archives" seems to lend that point some plausibility. Maybe the specific suggestion was the problem. We did discuss a number of alternatives. The history of this draft actually includes those options. Some of them did not have the unfortunate property you don't like. We considered client certificates, but rejected them on operational grounds (you might think that unfortunate, because that would be superior in many ways to all options discussed on this thread). Here are the options as originally presented: https://tools.ietf.org/html/draft-thomson-webpush-vapid-00 2.1.1. Application Tokens . . . . . . . . . . . . . . . . . 4 2.1.2. Contact Information Header Field . . . . . . . . . . 4 2.1.3. Request Signing . . . . . . . . . . . . . . . . . . . 5 2.1.4. Token Binding . . . . . . . . . . . . . . . . . . . . 5 I apologize for my reaction. > I think I explicitly labelled this argument as flippant, but I also don't > think it's valueless, especially when put up against "Three large companies > implemented and are too lazy to change". That's a strawman. The implementations I worry about are those in the very many application servers. The limited number of push service operators have demonstrated an ability to ship changes fairly rapidly. From nobody Wed Aug 16 18:01:11 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438F613239D; Wed, 16 Aug 2017 18:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLulc9w7rN6L; Wed, 16 Aug 2017 18:01:03 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3323612EC06; Wed, 16 Aug 2017 18:01:03 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id m34so24584101iti.1; Wed, 16 Aug 2017 18:01:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=HfuCURT0Fb+lR5ZMYekIKg6nzeT6r13KYJXXO8YtKjg=; b=oP55sJaVKMV7bDfnpQOFI43rNKsaODwn8yskURjjWOGTxcgMkBRnquQ+7OasQYLR1n E+uyJblILfIWyEJmcxhinn8LrAg3s80/RFXyrYC1hll8Gw+gGut3EC7EWkrTOlDoogBH Hs+wjUH6Z2hiPPOmX7v8z1U+dqP7AP0y34eyd8vNtPPPmIXc2y5DEOnhahGGfePjlyeE 8/9ki0PEsltcDZ6Z0BoSlhoS0Q7ninmX0EVXI55ZJRbsPGvRHCcpOnJ7ZZ563fGZgBoU rPLF054JDdWnIBdNLROpLfZkvLl4bm2aFL9Ygr86hlH3SdcssMfoqppv1S9dYpJu7guY XaSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=HfuCURT0Fb+lR5ZMYekIKg6nzeT6r13KYJXXO8YtKjg=; b=MqBI7VrIyO1zLoWGnv9ref4xQIjTmIZO7LaNZ2BYv3Pflc2YYLdmEueNRZ6BpYrNFO IYBFi9gQ4FZlSx+tkQQFIt8pYlN5DrIaUlaIF5Ymp940Eh1qfjx51vTEq+dQEcJxtc/G 8VZYNrDCOaq4JlVRf3WnGoTXGklDyyQjodwLLY8bOa0Cmc30ir4Ne+WqSjlx8q19686N 8Qkxm6Rr+FIvXJ7yGchAVzCKRaUvvKPg+QtHQZJz7L67Ag/1QIebh0OSoqygGGexIKcs 4sYmlI9l1Wwe4VHscnNJTx48JyqgBsbmq5WtGsmtzq0GV33AP3MY15GvUqhEsfJUrjTC 14Dw== X-Gm-Message-State: AHYfb5j9tFxhQcajDJHDz4w5U59nFCeQebSUc3J6TByNNayg9IIgCUXo /I666nB4tA0VupmFtTFBLISL78zDkg== X-Received: by 10.36.193.199 with SMTP id e190mr312646itg.122.1502931662535; Wed, 16 Aug 2017 18:01:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Wed, 16 Aug 2017 18:01:02 -0700 (PDT) In-Reply-To: References: <150285009047.12577.1184580798882485308.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Thu, 17 Aug 2017 11:01:02 +1000 Message-ID: To: Ben Campbell Cc: The IESG , draft-ietf-webpush-vapid , Phil Sorber , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Webpush] Ben Campbell's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT) X-BeenThere: webpush@ietf.org 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: Thu, 17 Aug 2017 01:01:05 -0000 On 17 August 2017 at 01:52, Ben Campbell wrote: > That mostly looks good, modulo discussion below. I think you dropped the = word =E2=80=9Cmeaning=E2=80=9D from the 8174 (was 2119) reference. Also, th= at RFC recommends specific boilerplate. (I=E2=80=99m not going to get wrapp= ed around whether you use that specific boilerplate, as long as the meaning= is clear.) The master branch has the boilerplate. I have updated the PR, which no longer includes a change. >> I think that "MAY" is entirely appropriate given the non-blocking >> nature of the mechanism. A push service might look at the header >> field, but not require the token. Maybe they just wanted to attach an >> email address to a stream of messages (that's what we do). > > I think there=E2=80=99s a fundamental difference between not validating i= n the first place, and ignoring a failed validation. My point is not to say= that ignoring it is the wrong thing to do, just that I think some more ela= boration here is needed. Would it make sense to say something of the effect= of =E2=80=9CSHOULD NOT use the information from a token that has failed va= lidation=E2=80=9D? That's easy. MUST NOT even. I added: "A push service MUST NOT use information from an invalid token." >> In NSS and many elliptic curve libraries, you can create an EC key for >> P-256. You can then use that key for signing AND key exchange. You >> shouldn't though. > > Would it make sense to say =E2=80=9CSome library implementations=E2=80=A6= =E2=80=9D? The PR says "Some elliptic curve implementations ". I think that's better. > Oops, that was a cut and paste error. I meant to quote the following sent= ence: > > " A push service MAY reject a > message that includes invalid credentials with a 403 (Forbidden) > status code. " I'll respond below. >> This section defines behaviour in the case that a >> subscription is limited to a particular application server key. I >> realize now that this might have been unclear, so I have reworded to: >> >> "A push service MUST reject a message sent to a restricted push subscrip= tion if >> that message includes no "vapid" authentication or invalid "vapid" >> authentication. A 401 (Unauthorized) status code might be used if the >> authentication is absent; a 403 (Forbidden) status code might be used if >> authentication is invalid." >> >> This also allows me to clear up a minor gripe about the prescriptive >> nature of the text regarding status codes. > > I like that paragraph better, but does it conflict with the text in secti= on 2, as discussed in my DISCUSS? The key point here is that the rejection mandated in Section 4.2 is specific to *restricted* subscriptions. The text in Section 2 (above) is a more general statement. I don't think that the two are in conflict. > I=E2=80=99ll go with Alexey=E2=80=99s separate response. That is, never m= ind. :) From nobody Wed Aug 16 18:04:32 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB662126DD9; Wed, 16 Aug 2017 18:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DH6t8-hOoLX1; Wed, 16 Aug 2017 18:04:28 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B528A1323B6; Wed, 16 Aug 2017 18:04:27 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7H14MKB068807 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 16 Aug 2017 20:04:23 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Wed, 16 Aug 2017 20:04:22 -0500 Cc: The IESG , draft-ietf-webpush-vapid , Phil Sorber , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <832D4A7A-C387-48A3-BB66-701ED1658C44@nostrum.com> References: <150285009047.12577.1184580798882485308.idtracker@ietfa.amsl.com> To: Martin Thomson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Webpush] Ben Campbell's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT) X-BeenThere: webpush@ietf.org 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: Thu, 17 Aug 2017 01:04:30 -0000 > On Aug 16, 2017, at 8:01 PM, Martin Thomson = wrote: >=20 > On 17 August 2017 at 01:52, Ben Campbell wrote: >=20 >>> I think that "MAY" is entirely appropriate given the non-blocking >>> nature of the mechanism. A push service might look at the header >>> field, but not require the token. Maybe they just wanted to attach = an >>> email address to a stream of messages (that's what we do). >>=20 >> I think there=E2=80=99s a fundamental difference between not = validating in the first place, and ignoring a failed validation. My = point is not to say that ignoring it is the wrong thing to do, just that = I think some more elaboration here is needed. Would it make sense to say = something of the effect of =E2=80=9CSHOULD NOT use the information from = a token that has failed validation=E2=80=9D? >=20 > That's easy. MUST NOT even. I added: "A push service MUST NOT use > information from an invalid token.=E2=80=9D >=20 WFM. I will clear. >>> In NSS and many elliptic curve libraries, you can create an EC key = for >>> P-256. You can then use that key for signing AND key exchange. You >>> shouldn't though. >>=20 >> Would it make sense to say =E2=80=9CSome library = implementations=E2=80=A6=E2=80=9D? >=20 > The PR says "Some elliptic curve implementations ". I think that's = better. Also WFM. >=20 >> Oops, that was a cut and paste error. I meant to quote the following = sentence: >>=20 >> " A push service MAY reject a >> message that includes invalid credentials with a 403 (Forbidden) >> status code. " >=20 > I'll respond below. >=20 >>> This section defines behaviour in the case that a >>> subscription is limited to a particular application server key. I >>> realize now that this might have been unclear, so I have reworded = to: >>>=20 >>> "A push service MUST reject a message sent to a restricted push = subscription if >>> that message includes no "vapid" authentication or invalid "vapid" >>> authentication. A 401 (Unauthorized) status code might be used if = the >>> authentication is absent; a 403 (Forbidden) status code might be = used if >>> authentication is invalid." >>>=20 >>> This also allows me to clear up a minor gripe about the prescriptive >>> nature of the text regarding status codes. >>=20 >> I like that paragraph better, but does it conflict with the text in = section 2, as discussed in my DISCUSS? >=20 > The key point here is that the rejection mandated in Section 4.2 is > specific to *restricted* subscriptions. The text in Section 2 (above) > is a more general statement. I don't think that the two are in > conflict. Okay. [=E2=80=A6]= From nobody Wed Aug 16 18:06:10 2017 Return-Path: X-Original-To: webpush@ietf.org Delivered-To: webpush@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A4912EC06; Wed, 16 Aug 2017 18:06:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-webpush-vapid@ietf.org, Phil Sorber , webpush-chairs@ietf.org, sorber@apache.org, webpush@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150293196340.12444.17567981067367019397.idtracker@ietfa.amsl.com> Date: Wed, 16 Aug 2017 18:06:03 -0700 Archived-At: Subject: [Webpush] Ben Campbell's Yes on draft-ietf-webpush-vapid-03: (with COMMENT) X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 17 Aug 2017 01:06:03 -0000 Ben Campbell has entered the following ballot position for draft-ietf-webpush-vapid-03: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-webpush-vapid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS and COMMENT points. From nobody Wed Aug 16 18:12:26 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F4D13239D; Wed, 16 Aug 2017 18:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-FyGexE2XxQ; Wed, 16 Aug 2017 18:12:19 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B61C12EC06; Wed, 16 Aug 2017 18:12:19 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7H1CFdZ070387 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 16 Aug 2017 20:12:16 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Wed, 16 Aug 2017 20:12:15 -0500 Cc: The IESG , draft-ietf-webpush-encryption@ietf.org, Phil Sorber , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <57117A3C-41D8-4E89-8F84-C5626569A91A@nostrum.com> References: <150285392127.12601.16486468628540142046.idtracker@ietfa.amsl.com> To: Martin Thomson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Webpush] Ben Campbell's Yes on draft-ietf-webpush-encryption-08: (with COMMENT) X-BeenThere: webpush@ietf.org 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: Thu, 17 Aug 2017 01:12:20 -0000 > On Aug 16, 2017, at 7:44 PM, Martin Thomson = wrote: >=20 > On 17 August 2017 at 00:41, Ben Campbell wrote: >> Is the shared =E2=80=9Ccentral agent=E2=80=9D the same as or part of = the =E2=80=9Csame user agent=E2=80=9D? Is it a push server? A shared = session with the push server (i.e. a shared push client as part of the = UA)? >=20 > Think common library, daemon process, or system service. >=20 >> To broaden the question: Is this =E2=80=9Ccentral agent=E2=80=9D on = the usual architecture picture for webpush, or is it something = different? >=20 > It's an implementation detail on the user agent. Okay, I get it. Am I correct to infer that the only practical impact is = this shared agent can wedge in encryption?= From nobody Wed Aug 16 18:13:34 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43DE12EC06 for ; Wed, 16 Aug 2017 18:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGxU8vdV0g3l for ; Wed, 16 Aug 2017 18:13:29 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7F27126DD9 for ; Wed, 16 Aug 2017 18:13:29 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id j32so18684234iod.0 for ; Wed, 16 Aug 2017 18:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Fgs+LzsrsR/J5lJkyc4ckSaFWB+Vsgu6tytnuuPmFTo=; b=gNKQ71rkYOkNAeR907AbJRWNVkHduaFskZPUyz5mMUnrSm7mDMXvFCuhz1AfwfdDLg ieZRb+kt3sHNaWrN/oOb4IWETwhu+/DjAFfObeKBI9c4qO+3N+ZdkA2luEMGcEaxGIhc 4WOx9YF/M6g62Iu3moF0NBF+5aFqVYyDuHvvn16FxfeYr+Yq0+VQvaRFcRTanyFQGLWZ obZ4n/kHOoEwhvmPFh2D1VshtYWXxjiIewT6zQdaejC/AHRXi/RcLs9CIFN5Iu4jWA/1 DGiVqyo/hEmBPD3gVks6kxBxnZ9kZBDAcMD0uwwPhsVmSjyQLOTrAh5rmpI8t5i5DNtQ CPNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Fgs+LzsrsR/J5lJkyc4ckSaFWB+Vsgu6tytnuuPmFTo=; b=HSswAdr4Kr3iEBfw46xl3lWDwPTHWgDU3iCOKIa3rEWGvBUlA48Qrz6XlSmZ1732NQ nNnrFGc3hc+DKqr0mfemmgJIfLy2w8uQa4TJilqO9TfjbUMLoaQdoI0goruaJoc23eda wkApW/qJkGtKucOfqrzn7MBGbLfo5SCqJx/QsvLb6n8IftdCX4IV4YMsNzL1azW6iE1e RHgP7y1Ux2Up1xCuwDOEnqZPrsza+/xflnXktVA685jWtLPSupTbakBffT5+IRRdk61E QkrvNmD9uPUzdsa3gd8AxpFTLbtjJ5Hyy1M3su2rQAaB0fC8dSUqZ9PuK3lQp2EoNi4x JuoQ== X-Gm-Message-State: AHYfb5iigJ59BeSj8USBip2fII3QAa9CoE0kC9PSvcHYHT1YpSNYoxcl +iHGIbRVKyyyCtvX4sbgTt7SrlPP2qIIARU= X-Received: by 10.107.16.196 with SMTP id 65mr3629640ioq.297.1502932408979; Wed, 16 Aug 2017 18:13:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Wed, 16 Aug 2017 18:13:28 -0700 (PDT) From: Martin Thomson Date: Thu, 17 Aug 2017 11:13:28 +1000 Message-ID: To: "webpush@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Webpush] Adding a vapid challenge X-BeenThere: webpush@ietf.org 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: Thu, 17 Aug 2017 01:13:32 -0000 In Alexey's review of vapid, he raised a concern about a new HTTP authentication scheme without a challenge. In light of this concern, I've proposed adding a challenge. It's a trivial thing to do. https://github.com/webpush-wg/webpush-vapid/pull/42 Just wanted to highlight this, in case the sudden increase in email caused that bit to be lost. From nobody Wed Aug 16 18:15:51 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5B1132391; Wed, 16 Aug 2017 18:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLiXVScpAqWU; Wed, 16 Aug 2017 18:15:44 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99855126DD9; Wed, 16 Aug 2017 18:15:44 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id 76so25089002ith.0; Wed, 16 Aug 2017 18:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=KTzSR/dHozgpZTrJUfiHrzTF13S15xpd5M9phG5kM6U=; b=um6r28aS3M1O+3Ky/43fQdDuxcPn62SfZjOBoiPwBS2Pl2SndA40j2Hd+3mlaMZqcJ rZW2Mpvn+iFZBwCKjMMRZCJK3JZ2WR7wI4BL7+dK3F/oYmXz2Uu98XuQ7+raFqyw/9y1 Kqihy49SSy2ZlH7Gn3htGXYjbAyLraOMChunVQOIDu4lLU4OXyePf3c0m1yYX2cLz3eE F6tYFdxAtr6dPL8cVZRuQvd5YH7bu6ITKJgYh5VqFnkl5Faqvm0ATtJxHQpltcVJpneJ 0PfiRm2cVzrO6VkuYe6Cf5iyTILoyW2vUBUZMQmPvEe76ToXn5e6UtYnTBnBBru+qjS8 5www== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=KTzSR/dHozgpZTrJUfiHrzTF13S15xpd5M9phG5kM6U=; b=XHzPC1fPLHSapKC9ccjKhuXgUXs/osuaTp7+EpIy2pMwZgyr/QFWTOSVZn2czVKLs5 +v1v1ONITPar+7KL01H25dOh2uH2sXNoKGe59savtfzLP1Cr2/5ih6CKTIQxT0fPI+l2 MVwATpeWNoCGoMvzWQBn8nflg2hZvBqpABTo3Sfj57rdsMfCBo84SL79f0/nSZugaZil lsx8l6N/WOoEJfNoKZn0DTZ/P1liTFtMEExRIZEgagPtwQIeeROiU2EhHtpt+k1IQxd2 UUehI2pOjHIDlx9uJNqooHWpHy8p7Zyv8XRww5xukgjdt+Xx1JMXolSKHlMbLby282t9 aVaw== X-Gm-Message-State: AHYfb5gRVn363cJTzpCFoJbfqT84ORU8eFD/rxFZKFJXQqhwwcvTBC0V ULMh/AnGtxCFpVlabAYi321ZUVHYMQ== X-Received: by 10.36.107.68 with SMTP id v65mr355188itc.129.1502932543825; Wed, 16 Aug 2017 18:15:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Wed, 16 Aug 2017 18:15:43 -0700 (PDT) In-Reply-To: <57117A3C-41D8-4E89-8F84-C5626569A91A@nostrum.com> References: <150285392127.12601.16486468628540142046.idtracker@ietfa.amsl.com> <57117A3C-41D8-4E89-8F84-C5626569A91A@nostrum.com> From: Martin Thomson Date: Thu, 17 Aug 2017 11:15:43 +1000 Message-ID: To: Ben Campbell Cc: The IESG , draft-ietf-webpush-encryption@ietf.org, Phil Sorber , webpush-chairs@ietf.org, "webpush@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Webpush] Ben Campbell's Yes on draft-ietf-webpush-encryption-08: (with COMMENT) X-BeenThere: webpush@ietf.org 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: Thu, 17 Aug 2017 01:15:46 -0000 On 17 August 2017 at 11:12, Ben Campbell wrote: > >> On Aug 16, 2017, at 7:44 PM, Martin Thomson w= rote: >> >> On 17 August 2017 at 00:41, Ben Campbell wrote: >>> Is the shared =E2=80=9Ccentral agent=E2=80=9D the same as or part of t= he =E2=80=9Csame user agent=E2=80=9D? Is it a push server? A shared session= with the push server (i.e. a shared push client as part of the UA)? >> >> Think common library, daemon process, or system service. >> >>> To broaden the question: Is this =E2=80=9Ccentral agent=E2=80=9D on the= usual architecture picture for webpush, or is it something different? >> >> It's an implementation detail on the user agent. > > Okay, I get it. Am I correct to infer that the only practical impact is t= his shared agent can wedge in encryption? Yeah. Though it turns out to be handy (or annoying, depending on your perspective). In webpush, the browser is this agent, and it has some rather different incentives to the applications themselves. We're effectively forcing applications to encrypt. From nobody Thu Aug 17 04:26:50 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B778613209D for ; Thu, 17 Aug 2017 04:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrsH6CPBZAVg for ; Thu, 17 Aug 2017 04:26:48 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6969132025 for ; Thu, 17 Aug 2017 04:26:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=Sc0fHrj+4r55rFavHDYy6ypzOsTDhrM7wbWZwfCGRzIf2TyAwZm+zV1V6LbsZtLeUdSIW+lgd2bI7Tvc5O8rYgtfqbL4bFzRoxKaq7PEe7zCXceZvT2sta4No0zeAcGYAZPpDtTV9UiMHs7Dmv/843bYU0+KlAwVC0/ME2z3Ebg=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 3665 invoked from network); 17 Aug 2017 13:26:46 +0200 Received: from pd9e11b0f.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (217.225.27.15) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 17 Aug 2017 13:26:46 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Thu, 17 Aug 2017 13:26:45 +0200 Cc: "webpush@ietf.org" , draft-ietf-webpush-vapid , webpush-chairs@ietf.org, The IESG , Phil Sorber Content-Transfer-Encoding: quoted-printable Message-Id: <4CC4719D-E067-43D4-B121-E5348E910AC4@kuehlewind.net> References: <150279716374.21102.11813544027973282978.idtracker@ietfa.amsl.com> To: Martin Thomson X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170817112646.3656.81496@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [Webpush] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-webpush-vapid-03=3A_=28with_COMMENT=29?= X-BeenThere: webpush@ietf.org 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: Thu, 17 Aug 2017 11:26:49 -0000 I don=E2=80=99t know because Ekr proposes basically a different initial = design which still doesn=E2=80=99t give my any hints if extensibility is = needed in future; also you can always update this draft and add a = registry later if a need comes up. But anyway not an issue. Do whatever = you think is the right thing to do! > Am 16.08.2017 um 02:05 schrieb Martin Thomson = : >=20 > On 15 August 2017 at 21:39, Mirja K=C3=BChlewind = wrote: >> Wondering if the new registry in section 6.2 is really needed. Is it = expected >> that new parameters show up any time soon? For me this doc reads like = that's >> the only two parameter you actually need. >=20 > I think that ekr's DISCUSS might make it clear that it isn't a > complete waste of effort :) >=20 From nobody Thu Aug 17 19:59:11 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D5113226B for ; Thu, 17 Aug 2017 19:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.41 X-Spam-Level: X-Spam-Status: No, score=-6.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiUd2BldZn_D for ; Thu, 17 Aug 2017 19:59:09 -0700 (PDT) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id E55D61326E1 for ; Thu, 17 Aug 2017 19:59:08 -0700 (PDT) Received: (qmail 63612 invoked by uid 99); 18 Aug 2017 02:59:08 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Aug 2017 02:59:08 +0000 Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com [209.85.220.182]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id C9ACD1A04D8 for ; Fri, 18 Aug 2017 02:59:07 +0000 (UTC) Received: by mail-qk0-f182.google.com with SMTP id a77so46839671qkb.0 for ; Thu, 17 Aug 2017 19:59:07 -0700 (PDT) X-Gm-Message-State: AHYfb5hHemWBzufUcUtTGOXSyYg8qEslqWEVJExggQfdiSxXeE0JK36e SRti1ONMDkgyg97EVRIyLuaqTgrk5Q== X-Received: by 10.55.161.133 with SMTP id k127mr9695382qke.164.1503025146167; Thu, 17 Aug 2017 19:59:06 -0700 (PDT) MIME-Version: 1.0 From: Phil Sorber Date: Fri, 18 Aug 2017 02:58:55 +0000 X-Gmail-Original-Message-ID: Message-ID: To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0772aeed0ea50556fe4fa6" Archived-At: Subject: [Webpush] CALL FOR CONSENSUS: VAPID cut-and-paste protection X-BeenThere: webpush@ietf.org 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: Fri, 18 Aug 2017 02:59:11 -0000 --94eb2c0772aeed0ea50556fe4fa6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This is a call for consensus for an issue relating to draft-ietf-webpush-vapid, which is currently in IESG evaluation. Interested participants should respond no later than Friday, September 1st 2017. During its initial review, one of the Security Area Directors expressed concerns regarding the cryptographic properties of the JWT: https://mailarchive.ietf.org/arch/msg/webpush/HYW9NcUioQo5X2Np-d2hjCzB1Fo Specifically: as implemented, the JWT is merely a bearer token. While the DISCUSS provides a thumbnail sketch of how this could be mitigated, the crux of the issue isn=E2=80=99t the specifics of the implementation, but wh= ether the WG had considered other, more cryptographically secure approaches. Although participants are free to respond in any way they choose, the most useful input would be of one of the following three forms: 1. I believe the working group has already discussed adding such a mechanism and rejected it (with citation to an email discussion or minut= es reflecting such discussion). 2. I do not think the working group has discussed the issue before, however I am opposed to changing the mechanism prior to publication because... 3. I do not think the working group has discussed the issue before, and would support bringing the document back to the working group for the purpose of mitigating copy-and-paste attacks. Thank you. --94eb2c0772aeed0ea50556fe4fa6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

This is a call= for consensus for an issue relating to draft-ietf-webpush-vapid, which is = currently in IESG evaluation. Interested participants should respond no lat= er than Friday, September 1st 2017.


During its initial review, one of the Security Area Dire= ctors expressed concerns regarding the cryptographic properties of the JWT:=


https= ://mailarchive.ietf.org/arch/msg/webpush/HYW9NcUioQo5X2Np-d2hjCzB1Fo


Specifically: as im= plemented, the JWT is merely a bearer token. While the DISCUSS provides a t= humbnail sketch of how this could be mitigated, the crux of the issue isn= =E2=80=99t the specifics of the implementation, but whether the WG had cons= idered other, more cryptographically secure approaches.


Although participants are free to re= spond in any way they choose, the most useful input would be of one of the = following three forms:


  1. I believe the worki= ng group has already discussed adding such a mechanism and rejected it (wit= h citation to an email discussion or minutes reflecting such discussion).

    2. =

    = I do not think the working grou= p has discussed the issue before, however I am opposed to changing the mech= anism prior to publication because...

  2. I do not think the working group has discussed the issue before, an= d would support bringing the document back to the working group for the pur= pose of mitigating copy-and-paste attacks.


Thank you.

--94eb2c0772aeed0ea50556fe4fa6-- From nobody Thu Aug 17 20:36:40 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5D5132409 for ; Thu, 17 Aug 2017 20:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRYIX8UTbtSD for ; Thu, 17 Aug 2017 20:36:35 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC92A132717 for ; Thu, 17 Aug 2017 20:36:34 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id t128so37629382lff.2 for ; Thu, 17 Aug 2017 20:36:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DN7qD25LY5kQ9gYxSrz3RqpqVP/4UWd09XZsfaQUhmY=; b=MtZ8bWsuZeb0t1fn/TFRxvzogFKwyC7RvRnYqN9HQlk7TgK7KP4+uIzxWhR6YvPVuG azgIKiPFincofqa0N38rxEZMaH1yWcVHKwjsF3mirD5roVc1O17n5drNmHEEQ531c9yg K53eYHa97Hj6nVOj+1F94R34PFcIx0W40aB7M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=DN7qD25LY5kQ9gYxSrz3RqpqVP/4UWd09XZsfaQUhmY=; b=liY927KQfEs+xyPA5GCZ4Bz+fJhfHZtNK8R5uW+dxaGxuSH2eQ4izMgHB5PSSekWT3 QLrQt33YzFSX5cauQidkCiWs3XNtTID5HzHOHusPIJXO/c251QHOWkAFBn1CxdUArF/S W4S6cnq+Ejvsv2G197O/GHkMzhrzvpx+LgjW1+VAuAHgQo4zilRRuN5Xk201M69hQH1W B/EH0COmWl4u847Z7oIwW9TLmz7HHFJYoOJLMhRbMZwgIzeBimt57Zb4teVXxqqhfuj0 MQ3A4z0KcjWijAemjKvjE/EXHB52BM9Hyh+iGjRpAWv5LwiTDQ1pigXsX15fbOZRlNWO cHWQ== X-Gm-Message-State: AHYfb5h+q1F1I24N9LeBDDHHqY8077BlC8kgBrSEVvmds9xEyGZD7ru+ Pw4wu1rZynAfEg0auQ5hQw12LphPGMBT X-Received: by 10.25.16.33 with SMTP id f33mr2856824lfi.133.1503027392519; Thu, 17 Aug 2017 20:36:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.9.8 with HTTP; Thu, 17 Aug 2017 20:36:31 -0700 (PDT) Reply-To: jrconlin@mozilla.com In-Reply-To: References: From: JR Conlin Date: Thu, 17 Aug 2017 20:36:31 -0700 Message-ID: To: Phil Sorber Cc: "webpush@ietf.org" Content-Type: multipart/alternative; boundary="001a113f9146d1c5620556fed545" Archived-At: Subject: Re: [Webpush] CALL FOR CONSENSUS: VAPID cut-and-paste protection X-BeenThere: webpush@ietf.org 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: Fri, 18 Aug 2017 03:36:39 -0000 --001a113f9146d1c5620556fed545 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Per Phil's request, I am reposting my statement about how VAPID is used by our Push Service. "=3D=3D If I may lend a bit of prospective from the point of view of the Push Service provider. We enjoy VAPID because it provides us a way to associate contact information with the data we receive. It's (in theory) voluntary, and we can prefer feeds that provide the data. VAPID provides us a reasonably low cost means to "validate" the information we get *if* the requested URI was secured using the same key, as well as prove that there has been no casual MITM alterations of data. As Martin notes, the bar is set fairly high for an attacker sending malicious data to the remote customer. >From our point of view, VAPID isn't really a security device, it's a contact device. It's equivalent to someone stapling their business card to their letter, and is most useful for our ops folk when things go awry. That's why we accept feeds that use VAPID even if the requested URI was not secured. In addition, our most pressing concern is with sites that perform non-hostile abuse. (e.g. we currently get near 2:1 traffic from sites sending to URIs that are no longer active, and do not provide good ways to contact their operations.) That said, we still encourage frankly horrible security practices around VAPID just so that the barrier to use is as low as possible. We find the data to still be that useful. For example, we encourage application servers to cache the VAPID header for as long as possible to reduce the publication load. Naturally, we look forward to the guidance provided by the working group and will adopt their suggestions, but I did want to offer what the more hands-on usage of the spec has been so far. =3D=3D" =E2=80=8B On Thu, Aug 17, 2017 at 7:58 PM, Phil Sorber wrote: > This is a call for consensus for an issue relating to > draft-ietf-webpush-vapid, which is currently in IESG evaluation. Interest= ed > participants should respond no later than Friday, September 1st 2017. > > During its initial review, one of the Security Area Directors expressed > concerns regarding the cryptographic properties of the JWT: > > https://mailarchive.ietf.org/arch/msg/webpush/HYW9NcUioQo5X2Np-d2hjCzB1Fo > > Specifically: as implemented, the JWT is merely a bearer token. While the > DISCUSS provides a thumbnail sketch of how this could be mitigated, the > crux of the issue isn=E2=80=99t the specifics of the implementation, but = whether > the WG had considered other, more cryptographically secure approaches. > > Although participants are free to respond in any way they choose, the mos= t > useful input would be of one of the following three forms: > > > 1. > > I believe the working group has already discussed adding such a > mechanism and rejected it (with citation to an email discussion or min= utes > reflecting such discussion). > > 2. > > I do not think the working group has discussed the issue before, > however I am opposed to changing the mechanism prior to publication > because... > > 3. > > I do not think the working group has discussed the issue before, and > would support bringing the document back to the working group for the > purpose of mitigating copy-and-paste attacks. > > > Thank you. > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > --001a113f9146d1c5620556fed545 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Per Phil's request, I am reposting my statement about how VAPID is u= sed by our Push Service.

"=3D=3D
If I may lend a bit of prospective from the point of view of the Push Service provider.

We enjoy VAPID because it provides us a way to associate contact information with the data we receive. It's (in theory) voluntary, and we can prefer feeds that provide the data. VAPID provides us a reasonably low cost means to "validate" the information we = get *if* the requested URI was secured using the same key, as well as prove that there has been no casual MITM alterations of data. As Martin notes, the bar is set fairly high for an attacker sending malicious data to the remote customer.

From our point of view, VAPID isn't really a security device, it&= #39;s a contact device. It's equivalent to someone stapling their business card to their letter, and is most useful for our ops folk when things go awry. That's why we accept feeds that use VAPID even if the requested URI was not secured. In addition, our most pressing concern is with sites that perform non-hostile abuse. (e.g. we currently get near 2:1 traffic from sites sending to URIs that are no longer active, and do not provide good ways to contact their operations.)

That said, we still encourage frankly horrible security practices around VAPID just so that the barrier to use is as low as possible. We find the data to still be that useful. For example, we encourage application servers to cache the VAPID header for as long as possible to reduce the publication load.

Naturally, we look forward to the guidance provided by the working group and will adopt their suggestions, but I did want to offer what the more hands-on usage of the spec has been so far.

=3D=3D"
=E2=80=8B

<= /div>

On Thu, Aug = 17, 2017 at 7:58 PM, Phil Sorber <sorber@apache.org> wrote:<= br>

This is a call for consensus for a= n issue relating to draft-ietf-webpush-vapid, which is currently in IESG ev= aluation. Interested participants should respond no later than Friday, Sept= ember 1st 2017.


D= uring its initial review, one of the Security Area Directors expressed conc= erns regarding the cryptographic properties of the JWT:


https:/= /mailarchive.ietf.org/arch/msg/webpush/HYW9NcUioQo5X2Np-d2hjCzB1F= o


Specificall= y: as implemented, the JWT is merely a bearer token. While the DISCUSS prov= ides a thumbnail sketch of how this could be mitigated, the crux of the iss= ue isn=E2=80=99t the specifics of the implementation, but whether the WG ha= d considered other, more cryptographically secure approaches.

Although participants are free= to respond in any way they choose, the most useful input would be of one o= f the following three forms:


  1. I believe the= working group has already discussed adding such a mechanism and rejected i= t (with citation to an email discussion or minutes reflecting such discussi= on).

  2. I do not think the working group has discussed the issue b= efore, however I am opposed to changing the mechanism prior to publication = because...

  3. I do not think the working group has discussed the = issue before, and would support bringing the document back to the working g= roup for the purpose of mitigating copy-and-paste attacks.

    4. <= /ol>

    Thank you.


    _______________________________________________
    Webpush mailing list
    Webpush@ietf.org
    https://www.ietf.org/mailman/listinfo/webpush<= br>

--001a113f9146d1c5620556fed545-- From nobody Thu Aug 17 21:15:27 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E1513283F for ; Thu, 17 Aug 2017 21:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xY6eTur1Cdzj for ; Thu, 17 Aug 2017 21:15:23 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183A21321D2 for ; Thu, 17 Aug 2017 21:15:23 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id i12so56093134pgr.3 for ; Thu, 17 Aug 2017 21:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YmY/33+JYNoQQD6jGUX+2yLfUMPrlGc+QFZPKUQcBNA=; b=sSZsVuPm8Mmen5L3sKnfWdITPR0hslOjnJVEiBRY7dztwlew13Tn+NtLvHTLHPb+FK 5vaF85QnJWQegfTGMVRVX7at+LJFtRe9230w752wUEUD0m+d+SZtk+EjzQp0rderyG5y tBQXkegP7ozlKyer5HE3KcM70EDpnKKL1Rddp8DjfWVW2MW5NdMtgRzfGzRW364Njyhv IDftuTLYjUjG9aQ18kWP1CePCXNfM4YIASoWatrGQU2OfMdcFUgTdiKtd/lOFkj6mt+Q YTb+4mJmvrUB96Ca323XZqwMRK/TxVfNjzqNSQwGd2j+z4V6AJPYp9+GJTCk4MR2XUj2 ynZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YmY/33+JYNoQQD6jGUX+2yLfUMPrlGc+QFZPKUQcBNA=; b=Z7G3rheXcnVJhX1nYzL4IljHrof881KklVLRX3N7l0XY4kyGN1vtQDYgM4nCk2b2hm AHJOyTk3ubaNrP6j7iL0Cg7wdh9rijrlnOJUoxE9SiUEhTrnwi8w+HyDmjpkb8sDozzW TbqqiGfKMJv+AEMx9qrIAq3eEWvppwHM58dZq/4s+tzI6FbwKuGKD8Z0YNEXDXr09tAW lko7DhPHtBweq1coColDAx1Iv1/PkbYyn/ctXesV9/P9jdtT7UrucDSlXDY2wMNTD8Zy ILj8gzhCWvSAlFt7VFBvd1mq+sGJuCGjMPzsDVfnwlFA4IGCOn+IysLNwecM6i5yceHt DWkQ== X-Gm-Message-State: AHYfb5g0h1Pgbs6ivU1+eR2w0kxd+k4Y+i8GW+2p0YdcFFBjNhWKDXUf Uj0fbq2hz15kURUsW6/3KOmkDQrWX5Em X-Received: by 10.98.144.149 with SMTP id q21mr7327303pfk.137.1503029722566; Thu, 17 Aug 2017 21:15:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.138.76 with HTTP; Thu, 17 Aug 2017 21:15:21 -0700 (PDT) In-Reply-To: References: From: Costin Manolache Date: Thu, 17 Aug 2017 21:15:21 -0700 Message-ID: To: Phil Sorber Cc: "webpush@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0e37d8b3576d0556ff6091" Archived-At: Subject: Re: [Webpush] CALL FOR CONSENSUS: VAPID cut-and-paste protection X-BeenThere: webpush@ietf.org 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: Fri, 18 Aug 2017 04:15:25 -0000 --94eb2c0e37d8b3576d0556ff6091 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (1) we did discuss using mutual TLS for webpush, as one of the early proposals, which would mitigate this issue. However it was felt that support for mutual TLS would be tricky in various environments, limiting the adoption both client and server side. With the work going on SPIFFE and other projects (gRPC, k8s) - this may change and IMHO a future revision of webpush could add it. On VAPID - since it is based on JWT, we have the same limitations as most other uses of JWT. I believe Oauth1 was mentioned in some discussions, but more as a thing to avoid. Also discussed the fact that bearer JWTs tokens with audience and similar expiration are widely used for protecting more valuable user accounts, and in the case of webpush we also have the authenticator and the (secret) public key. If VAPID is used for other purposes besides webpush - I believe the format is extensible enough to support additional elements to avoid reply. Costin On Thu, Aug 17, 2017 at 7:58 PM, Phil Sorber wrote: > This is a call for consensus for an issue relating to > draft-ietf-webpush-vapid, which is currently in IESG evaluation. Interest= ed > participants should respond no later than Friday, September 1st 2017. > > During its initial review, one of the Security Area Directors expressed > concerns regarding the cryptographic properties of the JWT: > > https://mailarchive.ietf.org/arch/msg/webpush/HYW9NcUioQo5X2Np-d2hjCzB1Fo > > Specifically: as implemented, the JWT is merely a bearer token. While the > DISCUSS provides a thumbnail sketch of how this could be mitigated, the > crux of the issue isn=E2=80=99t the specifics of the implementation, but = whether > the WG had considered other, more cryptographically secure approaches. > > Although participants are free to respond in any way they choose, the mos= t > useful input would be of one of the following three forms: > > > 1. > > I believe the working group has already discussed adding such a > mechanism and rejected it (with citation to an email discussion or min= utes > reflecting such discussion). > > 2. > > I do not think the working group has discussed the issue before, > however I am opposed to changing the mechanism prior to publication > because... > > 3. > > I do not think the working group has discussed the issue before, and > would support bringing the document back to the working group for the > purpose of mitigating copy-and-paste attacks. > > > Thank you. > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > --94eb2c0e37d8b3576d0556ff6091 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(1) =C2=A0we did discuss using mutual TLS for webpush, as = one of the early proposals, which would mitigate this=C2=A0
issue.=C2= =A0 However it was felt that support for mutual TLS would be tricky in vari= ous environments, limiting the adoption=C2=A0
both client and server si= de.=C2=A0 With the work going on SPIFFE and other projects (gRPC, k8s) - = =C2=A0this may change and
=C2=A0IMHO a future revision of webpush= could add it.

On VAPID - since it is based on JWT= , we have the same limitations as most other uses of JWT.=C2=A0
I= believe Oauth1 was mentioned in some discussions, but more as a thing to a= void.=C2=A0
Also discussed the fact that bearer JWTs tokens with = audience and similar expiration are widely used
=C2=A0for protect= ing more valuable user accounts, and in the case of webpush we also have th= e authenticator
=C2=A0and the (secret) public key.=C2=A0

If VAPID is used for other purposes besides webpush - I be= lieve the format is extensible enough to=C2=A0
support additional= elements to avoid reply.

Costin



On Thu, Aug 17, 2017 at 7:58 PM, Phil Sorber <= sorber@apache.org> wrote:
<= div dir=3D"ltr">

This is a call for consensus for an issue relating to draft-ietf-web= push-vapid, which is currently in IESG evaluation. Interested participants = should respond no later than Friday, September 1st 2017.


During its initial review, one of t= he Security Area Directors expressed concerns regarding the cryptographic p= roperties of the JWT:


https://mailarchive.ietf.org/arch/ms= g/webpush/HYW9NcUioQo5X2Np-d2hjCzB1Fo


Specifically: as implemented, the JWT is mere= ly a bearer token. While the DISCUSS provides a thumbnail sketch of how thi= s could be mitigated, the crux of the issue isn=E2=80=99t the specifics of = the implementation, but whether the WG had considered other, more cryptogra= phically secure approaches.


Although participants are free to respond in any way they choose= , the most useful input would be of one of the following three forms:


  1. I believe the working group has already discuss= ed adding such a mechanism and rejected it (with citation to an email discu= ssion or minutes reflecting such discussion).

  2. I do not think = the working group has discussed the issue before, however I am opposed to c= hanging the mechanism prior to publication because...

  3. I do no= t think the working group has discussed the issue before, and would support= bringing the document back to the working group for the purpose of mitigat= ing copy-and-paste attacks.


Thank you.


_______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush<= br>

--94eb2c0e37d8b3576d0556ff6091-- From nobody Thu Aug 17 21:17:01 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBAF132836 for ; Thu, 17 Aug 2017 21:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYWjkvGfLfg2 for ; Thu, 17 Aug 2017 21:16:58 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 420E01323BD for ; Thu, 17 Aug 2017 21:16:58 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id m88so29408500iod.2 for ; Thu, 17 Aug 2017 21:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uvooI3DQUyd9DsDvsl878iYpb6LG4hkcJK9jofzVYYk=; b=rrcafx0pYXYstbpsk9nEkDI1aqyLJPZhd2xtmCc9UrOp+3kgABn5jKfJ/7ocU090vp 52by1spVy5Z/SQs8nkPq4KTyCsjPxVxWCAGYrthW5BKHPcT93Oa1QUp6tuT7eQ5526RL UqLJcv7x7s35N9taOHciQhwCJ9JIe/0gJDeJGoEwoAi6dlb5PaaILfM3r6qrRckELQ5o xyptEvj1Z0DGOJc67sWG5JLyz++jtB85C78zzOjyB/BuQgTWF5bPhX9oO6IXbTq8c50d O71P2BkVEmoK+qNnXjLN7aOtTsKpxT9e/ni4fNqbefatLLHPC9P4HV+aJRagMoutKngh XmHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uvooI3DQUyd9DsDvsl878iYpb6LG4hkcJK9jofzVYYk=; b=oq0SHoIIO3DdrjzGMcKdXMDy5bjhKCg22LBl01lu0RZIZBXpw4HbsXE5rWOJLZ3N9C UeVhSsh7ldeyrDLmt9uZ3naA2BlMc+7jasuYpWqyS1ycmcOP57SMY+xfSAjAUohR8TqV 90iP/ez3Leh3YJ0BddTwZtQLQulYvaK8L4I0TLvecYhJEpSw7OZBrSamte4Ai2QeXO/s shzvbCkE4yREMi8hSNVJfkS/o7TQME1B0ub9/hL+oVT44LpmPhTTTMuTDCWHgoQWQrc+ SwXZwEmN2sT0CVs/u3Gc7MVHUTGyK8tWl3G06Vd2xhNk9YeSmY2HwzuDNsKqXlryN/rQ C3MA== X-Gm-Message-State: AHYfb5gWl2POmBnxA4bfwFBexxyEOe24sA+DS5CwSUr+PhnA6SzkM3Fq qnc0F2KGz+JxW9RY1yfJsdd7DA1+6w== X-Received: by 10.107.201.65 with SMTP id z62mr7716282iof.74.1503029817565; Thu, 17 Aug 2017 21:16:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Thu, 17 Aug 2017 21:16:57 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 18 Aug 2017 14:16:57 +1000 Message-ID: To: Phil Sorber Cc: "webpush@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Webpush] CALL FOR CONSENSUS: VAPID cut-and-paste protection X-BeenThere: webpush@ietf.org 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: Fri, 18 Aug 2017 04:17:00 -0000 On 18 August 2017 at 12:58, Phil Sorber wrote: > I believe the working group has already discussed adding such a mechanism > and rejected it (with citation to an email discussion or minutes reflecting > such discussion). We did consider options that don't have this unfortunate property. Client certificates were a strong contender. They would have been ideal if not for operational challenges. Here's the email that I think was pivotal on this subject: https://mailarchive.ietf.org/arch/msg/webpush/_qwcGCuDekERw5o31t0MjFJGTh8 Later there is also: https://mailarchive.ietf.org/arch/msg/webpush/poGnqtBFlFe3hpzvkiS3Rp5L94g There are yet more emails that follow on from this where we discuss scope of the token and relative costs. The first of those is here: https://mailarchive.ietf.org/arch/msg/webpush/xrqo-LUb7mrPV6eF1xgyJoqMgCU I found the rest of thread instructive as a reminder of what happened, I had forgotten the details of this discussion. I didn't read meeting minutes, the above seems sufficient.