From nobody Tue Jan 5 19:35:35 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5591C1A8BB5 for ; Tue, 5 Jan 2016 19:35:33 -0800 (PST) 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 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 gWTdYPigeZED for ; Tue, 5 Jan 2016 19:35:31 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::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 BE6791A8BB2 for ; Tue, 5 Jan 2016 19:35:31 -0800 (PST) Received: by mail-ig0-x231.google.com with SMTP id to18so24928924igc.0 for ; Tue, 05 Jan 2016 19:35:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/nb7OKcfNpBhCGfyRmTqob9gzYMg54l2TexdzYb9FF4=; b=hLmuUJaPqBEbDoDD/3qav5clE5OSiE7mOlcnq+SI4rD5DvnbPdhK/eotqtwotWcntL kKulSn2SRIQTqWaKmliLeHt2JHOqJZeJ11tLuLbs3Ws6EKIQueSUS9UsCWzRmUxF1k9F 6hTHuIWMBL09CLHut/gJxAKxLyyHvwqWqsCekZroOQADyxhHOyMsytwOSV8cnrM7kThj mKiR7BRCfYZ91dT8rrXWUymFNXjtDhx+H/6Vrh1ksa+QBFpAycGssPT4PaHXxsuajuV5 omRfSS1iI78wCLj/aV7PSWs9jXl9gphi7hI5PePUrdVRvu0ysXGuRT1TzOK1e5AHdWqt X+7w== MIME-Version: 1.0 X-Received: by 10.50.66.179 with SMTP id g19mr7469047igt.94.1452051331124; Tue, 05 Jan 2016 19:35:31 -0800 (PST) Received: by 10.36.149.130 with HTTP; Tue, 5 Jan 2016 19:35:31 -0800 (PST) Date: Wed, 6 Jan 2016 14:35:31 +1100 Message-ID: From: Martin Thomson To: "webpush@ietf.org" , Ben Bangert , Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Webpush] Application server authentication new years edition X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jan 2016 03:35:33 -0000 With Peter's help, I've just submitted a new version of a draft that attempts to enumerate the options for application server authentication (issue #44). https://tools.ietf.org/html/draft-thomson-webpush-vapid-01 This assumes the following requirements: 1. A push service would like to be able to correlate requests from a particular application server over time. 2. A push service would like to be able to contact the operator/developer of an application server. This takes the position that any correlation or contact information is provided voluntarily by an application server and that we don't require strong authentication for application servers. Both Ben and Costin have suggested that we could (SHOULD?) construct a scheme to strongly authenticate servers. Ben observed that most web push consumers will have HTTPS endpoints with valid server certificates and we could use that to construct a system that strongly authenticates senders. That might be possible, but it's likely to be a complicated system that introduces a whole new set of technical, operational and privacy problems. The voluntary authentication incrementally improves the situation and allows us to build stronger authentication systems on top in future. I think that we should look at doing that, but I would be opposed to anything that made a more heavyweight authentication system mandatory to use. So I come to the question: what levels of authentication do we want to support for application servers? A. anonymous/none - push without being authenticated B. voluntary authentication - as proposed in the draft C. strong - proposal TBD From nobody Tue Jan 5 20:55:29 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E14F1A8A8E for ; Tue, 5 Jan 2016 20:55:29 -0800 (PST) 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 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 u1ZzrljOhfhT for ; Tue, 5 Jan 2016 20:55:26 -0800 (PST) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::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 0F8CB1A90EB for ; Tue, 5 Jan 2016 20:55:24 -0800 (PST) Received: by mail-ob0-x236.google.com with SMTP id ba1so291534300obb.3 for ; Tue, 05 Jan 2016 20:55:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ybFdMRmr39Qeu7X84mtAGYBY2V/uh50e+9uxEDGJWHk=; b=l0609gHkTeDifct3XM6hCKKn5FXpe6pcBy4iMWPHutgglH2fx7IiTDRPVCztTgr674 /jJWSbDEb5xIIe/OLenUecXwsNcJqXT/LAn6s0/1Jdf1j92zYC6qhlPJraBFrIJNURYF oJz3Gv3/8tDBRSvfZxf7o/pU+PR2q+iWqgkHyrlGktEh9GRcpvnDhH1RpnmKlIqLiVZP +VCXN047hyYwUtkPclQ5tAAUeHh7BKaxFD04syubAgUu4qz5wdQm0+dGPopNE6rDS3cB ZSSG3dVEfqVbhLEZFmjDbYmHk0fmoxpRoqetLyTmm0DNyp+jexpNq2ulX/XFcgg2t4qU qKxQ== MIME-Version: 1.0 X-Received: by 10.60.135.98 with SMTP id pr2mr59854393oeb.65.1452056123456; Tue, 05 Jan 2016 20:55:23 -0800 (PST) Received: by 10.76.8.74 with HTTP; Tue, 5 Jan 2016 20:55:23 -0800 (PST) In-Reply-To: References: Date: Tue, 5 Jan 2016 20:55:23 -0800 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b4179216ec6330528a32902 Archived-At: Cc: Ben Bangert , Costin Manolache , "webpush@ietf.org" Subject: Re: [Webpush] Application server authentication new years edition X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jan 2016 04:55:29 -0000 --047d7b4179216ec6330528a32902 Content-Type: text/plain; charset=UTF-8 It is important to define what "voluntary" means :-). My understanding is that it involves a choice made by an entity, either the app server and push service. The only 'voluntary' choice an app server has is to not use a push service and UAs that requires authentication/authorization. Separate comments on the 3 elements - authentication, authorization and contact info. For authentication: 2.1(certificate) would be my preference, and is a well known and established mechanism, followed by 2.6, 2.3. -2.4 doesn't cover authentication, -2.5 seems too complicated (2.5 maps to Oauth1, 2.3 to Oauth2 - we know the outcome) -2.2 is what we use now, but doesn't work well with 3. - subscription association - if public keys are used. For authorization - or "subscription association" - big +1 :-) I like using the public key of the sender - in which case authentication must use 2.1, 2.6 or 2.3. Using an ID provided by the push service will be complicated if multiple push services are used. I don't see any other option - whatever the subscriber uses needs to be verifiable by the push service when send happens. For contact - each of the authentication schemes in the draft provide a way to include contact info, and the choice for senders is to include it or not, and the choice for push services is to throttle/reject or not. The tricky part is if any additional verification will be done by push services. I guess some providers (in particular free services) may be ok with a more relaxed verification or even allow some rate-limited sending without contact info, I personally don't mind it - if we can't contact a sender in case of problems we just block it. Costin On Tue, Jan 5, 2016 at 7:35 PM, Martin Thomson wrote: > With Peter's help, I've just submitted a new version of a draft that > attempts to enumerate the options for application server > authentication (issue #44). > > https://tools.ietf.org/html/draft-thomson-webpush-vapid-01 > > This assumes the following requirements: > > 1. A push service would like to be able to correlate requests from a > particular application server over time. > > 2. A push service would like to be able to contact the > operator/developer of an application server. > > This takes the position that any correlation or contact information is > provided voluntarily by an application server and that we don't > require strong authentication for application servers. > > Both Ben and Costin have suggested that we could (SHOULD?) construct a > scheme to strongly authenticate servers. Ben observed that most web > push consumers will have HTTPS endpoints with valid server > certificates and we could use that to construct a system that strongly > authenticates senders. That might be possible, but it's likely to be > a complicated system that introduces a whole new set of technical, > operational and privacy problems. > > The voluntary authentication incrementally improves the situation and > allows us to build stronger authentication systems on top in future. > I think that we should look at doing that, but I would be opposed to > anything that made a more heavyweight authentication system mandatory > to use. > > So I come to the question: what levels of authentication do we want > to support for application servers? > > A. anonymous/none - push without being authenticated > > B. voluntary authentication - as proposed in the draft > > C. strong - proposal TBD > On Tue, Jan 5, 2016 at 7:35 PM, Martin Thomson wrote: > With Peter's help, I've just submitted a new version of a draft that > attempts to enumerate the options for application server > authentication (issue #44). > > https://tools.ietf.org/html/draft-thomson-webpush-vapid-01 > > This assumes the following requirements: > > 1. A push service would like to be able to correlate requests from a > particular application server over time. > > 2. A push service would like to be able to contact the > operator/developer of an application server. > > This takes the position that any correlation or contact information is > provided voluntarily by an application server and that we don't > require strong authentication for application servers. > > Both Ben and Costin have suggested that we could (SHOULD?) construct a > scheme to strongly authenticate servers. Ben observed that most web > push consumers will have HTTPS endpoints with valid server > certificates and we could use that to construct a system that strongly > authenticates senders. That might be possible, but it's likely to be > a complicated system that introduces a whole new set of technical, > operational and privacy problems. > > The voluntary authentication incrementally improves the situation and > allows us to build stronger authentication systems on top in future. > I think that we should look at doing that, but I would be opposed to > anything that made a more heavyweight authentication system mandatory > to use. > > So I come to the question: what levels of authentication do we want > to support for application servers? > > A. anonymous/none - push without being authenticated > > B. voluntary authentication - as proposed in the draft > > C. strong - proposal TBD > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --047d7b4179216ec6330528a32902 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It is important to define what "voluntary" = means :-). My understanding is that it involves=C2=A0
a choice ma= de by an entity, either the app server and push service.=C2=A0
The only 'voluntary' choice an app server has is to no= t use =C2=A0
a push service and UAs that requires authenticat= ion/authorization.

Separate comments on the 3 elem= ents - authentication, authorization and contact info.

=
For authentication: =C2=A02.1(certificate) would be my preference, and= is a well known and established
mechanism, followed by 2.6, 2.3.=
-2.4 doesn't cover authentication,=C2=A0
-2.5 seem= s too complicated (2.5 maps to Oauth1, 2.3 to Oauth2 - we know the outcome)=
-2.2 is what we use now, but doesn't work well with 3. - sub= scription association - if=C2=A0
public keys are used.
=
For authorization - or "subscription association" = - big +1 :-)
I like using the public key of the sender - in w= hich case authentication must use 2.1, 2.6 or 2.3.=C2=A0
Using an= ID provided by the push service will be complicated if multiple push servi= ces are used.
I don't see any other option - whatever the sub= scriber uses needs to be verifiable by the push service
when send= happens.

For contact - each of the authentication= schemes in the draft provide a way to include contact info, and=C2=A0
the choice for senders is to include it or not, and the choice for pu= sh services is to throttle/reject
=C2=A0or not. The tricky part i= s if any additional verification will be done by push services.=C2=A0
=
I guess some providers (in particular free services) may be ok with a = more relaxed verification=C2=A0
or even allow some rate-limited s= ending without contact info, I personally don't mind it - if we
can't contact a sender in case of problems we just block it.=C2=A0

Costin

On Tue, Jan 5, 2016 at 7:35 PM, Martin Thomson=C2=A0<martin.thomson@gmail.com>=C2=A0wrote:
With Peter's help, I've just submitted a new version of a draft t= hat
attempts to enumerate the options for application server
authenti= cation (issue #44).

=C2=A0=C2=A0htt= ps://tools.ietf.org/html/draft-thomson-webpush-vapid-01

This ass= umes the following requirements:

1. A push service would like to be = able to correlate requests from a
particular application server over tim= e.

2. A push service would like to be able to contact the
operato= r/developer of an application server.

This takes the position that a= ny correlation or contact information is
provided voluntarily by an appl= ication server and that we don't
require strong authentication for a= pplication servers.

Both Ben and Costin have suggested that we could= (SHOULD?) construct a
scheme to strongly authenticate servers.=C2=A0 Be= n observed that most web
push consumers will have HTTPS endpoints with v= alid server
certificates and we could use that to construct a system tha= t strongly
authenticates senders.=C2=A0 That might be possible, but it&#= 39;s likely to be
a complicated system that introduces a whole new set o= f technical,
operational and privacy problems.

The voluntary auth= entication incrementally improves the situation and
allows us to build s= tronger authentication systems on top in future.
I think that we should = look at doing that, but I would be opposed to
anything that made a more = heavyweight authentication system mandatory
to use.

So I come to = the question:=C2=A0 what levels of authentication do we want
to support = for application servers?

=C2=A0 A. anonymous/none - push without bei= ng authenticated

=C2=A0 B. voluntary authentication - as proposed in= the draft

=C2=A0 C. strong - proposal TBD

=

On Tue, Jan 5, 2016 at 7:35 PM, Martin Thomson <= ;martin.thoms= on@gmail.com> wrote:
With P= eter's help, I've just submitted a new version of a draft that
attempts to enumerate the options for application server
authentication (issue #44).

=C2=A0 https://tools.ietf.org/html/draft-t= homson-webpush-vapid-01

This assumes the following requirements:

1. A push service would like to be able to correlate requests from a
particular application server over time.

2. A push service would like to be able to contact the
operator/developer of an application server.

This takes the position that any correlation or contact information is
provided voluntarily by an application server and that we don't
require strong authentication for application servers.

Both Ben and Costin have suggested that we could (SHOULD?) construct a
scheme to strongly authenticate servers.=C2=A0 Ben observed that most web push consumers will have HTTPS endpoints with valid server
certificates and we could use that to construct a system that strongly
authenticates senders.=C2=A0 That might be possible, but it's likely to= be
a complicated system that introduces a whole new set of technical,
operational and privacy problems.

The voluntary authentication incrementally improves the situation and
allows us to build stronger authentication systems on top in future.
I think that we should look at doing that, but I would be opposed to
anything that made a more heavyweight authentication system mandatory
to use.

So I come to the question:=C2=A0 what levels of authentication do we want to support for application servers?

=C2=A0 A. anonymous/none - push without being authenticated

=C2=A0 B. voluntary authentication - as proposed in the draft

=C2=A0 C. strong - proposal TBD

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

--047d7b4179216ec6330528a32902-- From nobody Wed Jan 6 01:16:35 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45811ACDD2 for ; Wed, 6 Jan 2016 01:16:34 -0800 (PST) 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 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 2Hr6jeYkNZqm for ; Wed, 6 Jan 2016 01:16:33 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 75B861ACDD0 for ; Wed, 6 Jan 2016 01:16:33 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id 1so166014344ion.1 for ; Wed, 06 Jan 2016 01:16:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zH5puJi0ytBzTgiIT7WcLtpUVSn3OrPwh/K2i+0fkWY=; b=ZmbSWF4yxhpeuj5IbLmY0rXJ9AHY8EFGTPj7AX13N27+VmOUL+kU7nyXbQpvQeIjR0 bQRo7PkU7YaxJEoV16dooTFhqQmc68pOIzrjL3LbSUhHGmKTI5IsUJlg1ARfV7arU/HQ YHLuQzjgPUJu5VM9DBMEvGT+UwFRMYgmgjkFAGku0ma+xX5pdwAqONexIQWH5oa4JYXW iyD0YUkSKWImKS6TTCnoYCxIzT4bUhdzm/2mPgijIL/pnpoUl8y/l13Nun2zbGLr0Wrd vWnpDEKUAzJjSuCCKU/JJflhT113yQrfOT5ghjT45VUH67X81tAz0EnTF4ZvZnbDj/uQ bOnA== MIME-Version: 1.0 X-Received: by 10.107.131.40 with SMTP id f40mr80562826iod.190.1452071792910; Wed, 06 Jan 2016 01:16:32 -0800 (PST) Received: by 10.36.149.130 with HTTP; Wed, 6 Jan 2016 01:16:32 -0800 (PST) In-Reply-To: References: Date: Wed, 6 Jan 2016 20:16:32 +1100 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ben Bangert , Costin Manolache , "webpush@ietf.org" Subject: Re: [Webpush] Application server authentication new years edition X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jan 2016 09:16:35 -0000 On 6 January 2016 at 15:55, Costin Manolache wrote: > It is important to define what "voluntary" means :-). My understanding is > that it involves > a choice made by an entity, either the app server and push service. I hope that the draft makes it clear enough: "voluntary" refers to the choice at the app server whether to provide this information. > The only 'voluntary' choice an app server has is to not use > a push service and UAs that requires authentication/authorization. Right, and I don't think that this is a choice we want to force people into making. That has some fairly dire market effects. > For authentication: 2.1(certificate) would be my preference, and is a well > known and established > mechanism, followed by 2.6, 2.3. Both 2.1 (certs) and 2.6 (token binding) require access to the TLS connection. Token binding has the added concern that it is a new mechanism that might not be well deployed. When I inquired, certs did seem possible, but Mozilla folks (JR can speak to this better than I), had some operational concerns. JWT hoists the authentication information up into HTTP, which was a lot easier to manage. > -2.4 doesn't cover authentication, > -2.5 seems too complicated (2.5 maps to Oauth1, 2.3 to Oauth2 - we know the > outcome) I agree. We don't really know how to solve the signing problem, and not from a lack of trying. > -2.2 is what we use now, but doesn't work well with 3. - subscription > association - if > public keys are used. > > For authorization - or "subscription association" - big +1 :-) Yeah, I like the subscription association feature too. I think that it's an important consideration in choosing a mechanism. > For contact - each of the authentication schemes in the draft provide a way > to include contact info, and > the choice for senders is to include it or not, and the choice for push > services is to throttle/reject > or not. The tricky part is if any additional verification will be done by > push services. > I guess some providers (in particular free services) may be ok with a more > relaxed verification > or even allow some rate-limited sending without contact info, I personally > don't mind it - if we > can't contact a sender in case of problems we just block it. That's the policy that we've discussed having. I think that it is very important to allow requests from all comers, even without authentication. Of course, services should be prepared to cut off those unauthenticated requests very quickly as load increases. From nobody Wed Jan 6 08:28:24 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA1B1A8A0F for ; Wed, 6 Jan 2016 08:28:23 -0800 (PST) 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 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 FiEePlIMdHqE for ; Wed, 6 Jan 2016 08:28:21 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (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 940D21A891B for ; Wed, 6 Jan 2016 08:28:21 -0800 (PST) Received: by mail-ob0-x22d.google.com with SMTP id wp13so168438876obc.1 for ; Wed, 06 Jan 2016 08:28:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j08WoZG68AX2YL85nVwPkkfD5pdSeFSUD2jvVOryn4Q=; b=mle6D8rkGvICnN8kQxcEunSXjav0DC/9HYYLOtfWonXhLbV4oK6i6bKkPfzW4dZ3I+ 8pgh/CWTd6pFBGr4zm2nVW6XxVwln9/5f2KoTYRRkMBSyU+hy/6q4hNU1X7JrDcs4EHX V6QaaQCFmzQMJHo2waEEfh+XOxT0C1hI8i6eS2i0EP6LRJylAaFJLI0EzarO3Ixbp93n gPPgMiOGgehytDzkbYl9VNg2L+hKRijw1fD+8bty6z0sECnZIQJpTq7+oNYXJz0jnJkw qpeyEiSswuazmpDo/DcO+X+nLncmcccy2cto9y8g6gzpt7iYD56gTIaHB7Al/qnnc13B nBkQ== MIME-Version: 1.0 X-Received: by 10.182.171.8 with SMTP id aq8mr28955106obc.51.1452097700925; Wed, 06 Jan 2016 08:28:20 -0800 (PST) Received: by 10.76.8.74 with HTTP; Wed, 6 Jan 2016 08:28:20 -0800 (PST) In-Reply-To: References: Date: Wed, 6 Jan 2016 08:28:20 -0800 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=e89a8ff1ccaaa497820528acd75c Archived-At: Cc: Ben Bangert , Costin Manolache , "webpush@ietf.org" Subject: Re: [Webpush] Application server authentication new years edition X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jan 2016 16:28:23 -0000 --e89a8ff1ccaaa497820528acd75c Content-Type: text/plain; charset=UTF-8 On Wed, Jan 6, 2016 at 1:16 AM, Martin Thomson wrote: > On 6 January 2016 at 15:55, Costin Manolache wrote: > > It is important to define what "voluntary" means :-). My understanding is > > that it involves > > a choice made by an entity, either the app server and push service. > > I hope that the draft makes it clear enough: "voluntary" refers to the > choice at the app server whether to provide this information. > > > The only 'voluntary' choice an app server has is to not use > > a push service and UAs that requires authentication/authorization. > > Right, and I don't think that this is a choice we want to force people > into making. That has some fairly dire market effects. > > > For authentication: 2.1(certificate) would be my preference, and is a > well > > known and established > > mechanism, followed by 2.6, 2.3. > > Both 2.1 (certs) and 2.6 (token binding) require access to the TLS > connection. Token binding has the added concern that it is a new > mechanism that might not be well deployed. > > When I inquired, certs did seem possible, but Mozilla folks (JR can > speak to this better than I), had some operational concerns. JWT > hoists the authentication information up into HTTP, which was a lot > easier to manage. > > > -2.4 doesn't cover authentication, > > -2.5 seems too complicated (2.5 maps to Oauth1, 2.3 to Oauth2 - we know > the > > outcome) > > I agree. We don't really know how to solve the signing problem, and > not from a lack of trying. > > > -2.2 is what we use now, but doesn't work well with 3. - subscription > > association - if > > public keys are used. > > > > For authorization - or "subscription association" - big +1 :-) > > Yeah, I like the subscription association feature too. I think that > it's an important consideration in choosing a mechanism. > > > For contact - each of the authentication schemes in the draft provide a > way > > to include contact info, and > > the choice for senders is to include it or not, and the choice for push > > services is to throttle/reject > > or not. The tricky part is if any additional verification will be done > by > > push services. > > I guess some providers (in particular free services) may be ok with a > more > > relaxed verification > > or even allow some rate-limited sending without contact info, I > personally > > don't mind it - if we > > can't contact a sender in case of problems we just block it. > > That's the policy that we've discussed having. I think that it is > very important to allow requests from all comers, even without > authentication. Of course, services should be prepared to cut off > those unauthenticated requests very quickly as load increases. > --e89a8ff1ccaaa497820528acd75c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 6, 2016 at 1:16 AM, Martin Thomson = <martin.th= omson@gmail.com> wrote:
On 6 January 2016 at 15:55, Costin Manolache <costin@gmail.com> wrote:
> It is important to define what "voluntary" means :-). My und= erstanding is
> that it involves
> a choice made by an entity, either the app server and push service.
I hope that the draft makes it clear enough: "voluntary" r= efers to the
choice at the app server whether to provide this information.

> The only 'voluntary' choice an app server has is to not use > a push service and UAs that requires authentication/authorization.

Right, and I don't think that this is a choice we want to force = people
into making.=C2=A0 That has some fairly dire market effects.

> For authentication:=C2=A0 2.1(certificate) would be my preference, and= is a well
> known and established
> mechanism, followed by 2.6, 2.3.

Both 2.1 (certs) and 2.6 (token binding) require access to the TLS connection.=C2=A0 Token binding has the added concern that it is a new
mechanism that might not be well deployed.

When I inquired, certs did seem possible, but Mozilla folks (JR can
speak to this better than I), had some operational concerns.=C2=A0 JWT
hoists the authentication information up into HTTP, which was a lot
easier to manage.

> -2.4 doesn't cover authentication,
> -2.5 seems too complicated (2.5 maps to Oauth1, 2.3 to Oauth2 - we kno= w the
> outcome)

I agree.=C2=A0 We don't really know how to solve the signing pro= blem, and
not from a lack of trying.

> -2.2 is what we use now, but doesn't work well with 3. - subscript= ion
> association - if
> public keys are used.
>
> For authorization - or "subscription association" - big +1 := -)

Yeah, I like the subscription association feature too.=C2=A0 I think= that
it's an important consideration in choosing a mechanism.

> For contact - each of the authentication schemes in the draft provide = a way
> to include contact info, and
> the choice for senders is to include it or not, and the choice for pus= h
> services is to throttle/reject
>=C2=A0 or not. The tricky part is if any additional verification will b= e done by
> push services.
> I guess some providers (in particular free services) may be ok with a = more
> relaxed verification
> or even allow some rate-limited sending without contact info, I person= ally
> don't mind it - if we
> can't contact a sender in case of problems we just block it.

That's the policy that we've discussed having.=C2=A0 I think= that it is
very important to allow requests from all comers, even without
authentication.=C2=A0 Of course, services should be prepared to cut off
those unauthenticated requests very quickly as load increases.

--e89a8ff1ccaaa497820528acd75c-- From nobody Wed Jan 6 08:33:31 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858D01A8827 for ; Wed, 6 Jan 2016 08:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham 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 jkY-ZILJjcEv for ; Wed, 6 Jan 2016 08:33:26 -0800 (PST) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 929A31A02BE for ; Wed, 6 Jan 2016 08:33:26 -0800 (PST) Received: by mail-pf0-x231.google.com with SMTP id 78so244588443pfw.2 for ; Wed, 06 Jan 2016 08:33:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=yuVkzOU+kSr00A6aYwwQJh1ZTmi6PNkDVkBjI0DMNPA=; b=TTLL2vaw6q9OvvmjOMMXGQx32jTeymjhwlNwhIK1tyCfpVV3pMgBx+IKtWBE0Fiibl Pk+0n8v/pJMvPOp+kKVdwHHeTwtNV3SuM9bStpkk0dBnAGjBy8tB+ZR5ahsPrFsRUdaM Mh1YPXQ1EFmX+JnaDxBCmmviv4Lp8cvpLxmjBdnPQc6A4yx+aBYc67cvNPwYRS4eZDw3 WYUUk/5oAJ/ZtsQ9howN8OFBcuSgHq+MNKt2Zzr+d9YE0TCfn7/kuxTex0GB7sByIh7s o9G+jmctzS4qAuvpVhx915Vfc/zifADuQv1vVUzegEdueWpbWs4L0BEX2nMNHsgaxDER Ecqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=yuVkzOU+kSr00A6aYwwQJh1ZTmi6PNkDVkBjI0DMNPA=; b=GxHal/wOWXctRQ7awVhCzeb4GbZcoOI/VLzqG1xCd9qwusrmbaGAYo28SEybhkOGs/ O0LQhLUyrWebVg95Q2ehr69XM4YcW2d+55JIEO32uSI/bMSV75tmg+7d3IK5CWh5B29R ZIv+jF4vvgtShDma//XqzgzOAerTEh1qFWkVAyMkHB8cg4nFwRuAfVzQw/2qk4wFY+zf XPyWGKGJjaxEnDv9+/CXcBhaTALpfU2wVE42TNemhmcvqLKdiGb9Dcg7hrI/GQ+6lKTO 3Fsr3Vvyy0c44NIN8d5YMmtYRfi1g0yw2U2kR82Bc2I9juexwD6wJzed30eqORe6Mzvs kq6A== X-Gm-Message-State: ALoCoQmg+IH7+2bChDiMbj/reUd6y/rJQAJKIL/ihuA8V9TVxnBLf3NAuWablH4kx6qIEdN2rLyHBPdeg2vi5Zu6H7ZdOZHScw== X-Received: by 10.98.13.86 with SMTP id v83mr125079867pfi.127.1452098006111; Wed, 06 Jan 2016 08:33:26 -0800 (PST) Received: from [192.168.2.102] (107-130-102-77.lightspeed.sntcca.sbcglobal.net. [107.130.102.77]) by smtp.googlemail.com with ESMTPSA id a15sm115883836pfj.31.2016.01.06.08.33.25 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Jan 2016 08:33:25 -0800 (PST) To: webpush@ietf.org References: From: jr conlin Message-ID: <568D41D6.40904@mozilla.com> Date: Wed, 6 Jan 2016 08:33:26 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Webpush] Application server authentication new years edition X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jan 2016 16:33:29 -0000 On 01/06/2016 01:16 AM, Martin Thomson wrote: > On 6 January 2016 at 15:55, Costin Manolache wrote: >> For authentication: 2.1(certificate) would be my preference, and is a well >> known and established >> mechanism, followed by 2.6, 2.3. > Both 2.1 (certs) and 2.6 (token binding) require access to the TLS > connection. Token binding has the added concern that it is a new > mechanism that might not be well deployed. > > When I inquired, certs did seem possible, but Mozilla folks (JR can > speak to this better than I), had some operational concerns. JWT > hoists the authentication information up into HTTP, which was a lot > easier to manage. We are currently deployed on Amazon Web Services (AWS) using Elastic Load Balancers (ELBs) to terminate TLS connections for both cost and performance reasons. The ELBs act as a simple proxy, consume the certificate and provide no certificate information. AWS has no plans to modify ELB software to relay the cert information as part of the proxied connection. It is not possible for any AWS based service to use any cert information to show authentication, since it is impossible to get that information. From nobody Wed Jan 6 10:02:02 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0CD1A0053 for ; Wed, 6 Jan 2016 10:02:01 -0800 (PST) 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 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 owwC6aOIvoGx for ; Wed, 6 Jan 2016 10:01:58 -0800 (PST) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::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 366401A0031 for ; Wed, 6 Jan 2016 10:01:58 -0800 (PST) Received: by mail-oi0-x229.google.com with SMTP id y66so298261832oig.0 for ; Wed, 06 Jan 2016 10:01:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=srHe8Z+Z6knAzptY+V3RtxSrXiBS9MzFd8vOSGnghUs=; b=q7EYEZbzD8iQ1bPZSJnnU3s2yztvUGgHVm9P36rH7/ZcDUZHxcspBXnVcJo4dqQnp0 E5G5fmPkBKtha6h/aPCg7tF8s5teyuRlyOMiJdzm1pSb9H8g/K7UrVy9XHTu6EtAw16P 83KzqU4KQ3PEkb/Auh1AbAfUOhUUdQ4BeBPpaTHWaT5p+CpOKSmxP/xjyZtpxyU6J7Wd 8Uu84EKEMmWrCNW5K3QmAVSWGwL5p10RqIMGpaE6/K8eucOgO3nwDbMtYrCgEfvHx6kl RL5ccNPr3An11DtysJFHQVetUJHIN9msvritvi2get25pAweabGiS54KefQ5fjKKN77h rhGg== MIME-Version: 1.0 X-Received: by 10.202.204.136 with SMTP id c130mr69642935oig.93.1452103317589; Wed, 06 Jan 2016 10:01:57 -0800 (PST) Received: by 10.76.8.74 with HTTP; Wed, 6 Jan 2016 10:01:57 -0800 (PST) In-Reply-To: References: Date: Wed, 6 Jan 2016 10:01:57 -0800 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1137b1126c149e0528ae263f Archived-At: Cc: Ben Bangert , Costin Manolache , "webpush@ietf.org" Subject: Re: [Webpush] Application server authentication new years edition X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jan 2016 18:02:01 -0000 --001a1137b1126c149e0528ae263f Content-Type: text/plain; charset=UTF-8 On Wed, Jan 6, 2016 at 1:16 AM, Martin Thomson wrote: > On 6 January 2016 at 15:55, Costin Manolache wrote: > > It is important to define what "voluntary" means :-). My understanding is > > that it involves > > a choice made by an entity, either the app server and push service. > > I hope that the draft makes it clear enough: "voluntary" refers to the > choice at the app server whether to provide this information. > > > The only 'voluntary' choice an app server has is to not use > > a push service and UAs that requires authentication/authorization. > > Right, and I don't think that this is a choice we want to force people > into making. That has some fairly dire market effects. > At the same time you can't force push service providers to accept unauthenticated/unauthorized sending either. Or require them to provide unlimited (and free) service to everyone regardless of how much they're abusing/hurting users or networks. > > For authentication: 2.1(certificate) would be my preference, and is a > well > > known and established > > mechanism, followed by 2.6, 2.3 > > Both 2.1 (certs) and 2.6 (token binding) require access to the TLS > connection. Token binding has the added concern that it is a new > mechanism that might not be well deployed. > > When I inquired, certs did seem possible, but Mozilla folks (JR can > speak to this better than I), had some operational concerns. JWT > hoists the authentication information up into HTTP, which was a lot > easier to manage. > How about 2.1 AND 2.3 ? Push servers should support both, clients should use what they can. I think there are some benefits in 2.1. > > > -2.4 doesn't cover authentication, > > -2.5 seems too complicated (2.5 maps to Oauth1, 2.3 to Oauth2 - we know > the > > outcome) > > I agree. We don't really know how to solve the signing problem, and > not from a lack of trying. > > > -2.2 is what we use now, but doesn't work well with 3. - subscription > > association - if > > public keys are used. > > > > For authorization - or "subscription association" - big +1 :-) > > Yeah, I like the subscription association feature too. I think that > it's an important consideration in choosing a mechanism. > And it may be the way to allow the choice on app server side - either by having an 'isAuthorizationRequired()' or an error code when attempting to subscribe without a public key. If they subscribe without the sender id, than on some push services send will fail - and they can't do anything about it. > > > For contact - each of the authentication schemes in the draft provide a > way > > to include contact info, and > > the choice for senders is to include it or not, and the choice for push > > services is to throttle/reject > > or not. The tricky part is if any additional verification will be done > by > > push services. > > I guess some providers (in particular free services) may be ok with a > more > > relaxed verification > > or even allow some rate-limited sending without contact info, I > personally > > don't mind it - if we > > can't contact a sender in case of problems we just block it. > > That's the policy that we've discussed having. I think that it is > very important to allow requests from all comers, even without > authentication. Of course, services should be prepared to cut off > those unauthenticated requests very quickly as load increases. > Of course, you have the choice and I'm very curious to know how it works, but based on our experience we are not ready to make the same choice :-) I'm personally ok to not require contact info ( with understanding that if it is missing the sender accepts some limitations ). Unfortunately it's not my choice, people who support the service may have a different opinion, and each service provider may make a choice or another. However authorization and authentication are a different story than contact info. Costin --001a1137b1126c149e0528ae263f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 6, 2016 at 1:16 AM, Martin Thomson <martin.thomson@= gmail.com> wrote:
On= 6 January 2016 at 15:55, Costin Manolache <costin@gmail.com> wrote:
> It is important to define what "voluntary" means :-). My und= erstanding is
> that it involves
> a choice made by an entity, either the app server and push service.
I hope that the draft makes it clear enough: "voluntary" r= efers to the
choice at the app server whether to provide this information.

> The only 'voluntary' choice an app server has is to not use > a push service and UAs that requires authentication/authorization.

Right, and I don't think that this is a choice we want to force = people
into making.=C2=A0 That has some fairly dire market effects.

At the same time you can't force push service pro= viders to accept
=C2=A0unauthenticated/unauthorized sending eithe= r. Or require them to=C2=A0
provide unlimited (and free) service = to everyone regardless of how much
they're abusing/hurting us= ers or networks.



> For authentication:=C2=A0 2.1(certificate) would be my preference, and= is a well
> known and established
> mechanism, followed by 2.6, 2.3

Both 2.1 (certs) and 2.6 (token binding) require access to the TLS connection.=C2=A0 Token binding has the added concern that it is a new
mechanism that might not be well deployed.

When I inquired, certs did seem possible, but Mozilla folks (JR can
speak to this better than I), had some operational concerns.=C2=A0 JWT
hoists the authentication information up into HTTP, which was a lot
easier to manage.

How about 2.1 AND 2.3= ? Push servers should support both, clients should
use what they= can.

I think there are some benefits in 2.1.

=C2=A0

> -2.4 doesn't cover authentication,
> -2.5 seems too complicated (2.5 maps to Oauth1, 2.3 to Oauth2 - we kno= w the
> outcome)

I agree.=C2=A0 We don't really know how to solve the signing pro= blem, and
not from a lack of trying.

> -2.2 is what we use now, but doesn't work well with 3. - subscript= ion
> association - if
> public keys are used.
>
> For authorization - or "subscription association" - big +1 := -)

Yeah, I like the subscription association feature too.=C2=A0 I think= that
it's an important consideration in choosing a mechanism.

And it may be the way to allow the choice on app serv= er side - either by=C2=A0
having an 'isAuthorizationRequired(= )' or an error code when attempting to=C2=A0
subscribe withou= t a public key.

If they subscribe without the send= er id, than on some push services send=C2=A0
will fail - and they= can't do anything about it.=C2=A0

=C2=A0

> For contact - each of the authentication schemes in the draft provide = a way
> to include contact info, and
> the choice for senders is to include it or not, and the choice for pus= h
> services is to throttle/reject
>=C2=A0 or not. The tricky part is if any additional verification will b= e done by
> push services.
> I guess some providers (in particular free services) may be ok with a = more
> relaxed verification
> or even allow some rate-limited sending without contact info, I person= ally
> don't mind it - if we
> can't contact a sender in case of problems we just block it.

That's the policy that we've discussed having.=C2=A0 I think= that it is
very important to allow requests from all comers, even without
authentication.=C2=A0 Of course, services should be prepared to cut off
those unauthenticated requests very quickly as load increases.

Of course, you have= the choice and I'm very curious to know how it works,=C2=A0
but based on our experience we are not ready to make = the same choice :-)

I'm personally ok to not require contact info ( with unde= rstanding that if it is missing
the sen= der accepts some limitations ). Unfortunately it's not my choice, peopl= e who=C2=A0
support the service may have a = different opinion, and each service provider may
make a choice or another.

<= div class=3D"gmail_extra">However authorization and authentication are a di= fferent story than contact info.

=
Costin


--001a1137b1126c149e0528ae263f-- From nobody Wed Jan 6 11:30:03 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE99A1A0143 for ; Wed, 6 Jan 2016 11:30:01 -0800 (PST) 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 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 dWxIA7BLGeS7 for ; Wed, 6 Jan 2016 11:30:00 -0800 (PST) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::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 C77B71A011C for ; Wed, 6 Jan 2016 11:29:59 -0800 (PST) Received: by mail-ob0-x235.google.com with SMTP id bx1so280893260obb.0 for ; Wed, 06 Jan 2016 11:29:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XKXJjeHmrj3jwS2HSjZEcqZld5fyS0BQ+vc4Z8FK6No=; b=YvVCwtpd68pzjXCeBq+A3HjBQXcZMt0OHdb6/VkYziKC9w3cLc1NOnhZonL6rOxO1o lBnuOqt7TFoZ6/5VvAWljihs+EsS8LkZ7UYMzuqaMtm7nAIqb0iT6bADhIUlK2fXQ9KL X4Nt94epKWPD9RlH9DcMS4W+1vSvbKVqkDGmlg2HGsrkAcuGHgmL8S6hog5zHZSZN9F6 0t1VoH4G50eDqqljDkcQBz0tTtJ7/tbRc73tdB5TQA1ueOjGEaHg18BFfclHBUCLleaj N4ciR2ojP1EIsNiwLbC4vrcYR1vbHlvsVvI52dXAdmAPOU9t/y279r6IH8UlKkD8LRZj vhpA== MIME-Version: 1.0 X-Received: by 10.182.200.201 with SMTP id ju9mr71164683obc.30.1452108599207; Wed, 06 Jan 2016 11:29:59 -0800 (PST) Received: by 10.76.8.74 with HTTP; Wed, 6 Jan 2016 11:29:59 -0800 (PST) In-Reply-To: <568D41D6.40904@mozilla.com> References: <568D41D6.40904@mozilla.com> Date: Wed, 6 Jan 2016 11:29:59 -0800 Message-ID: From: Costin Manolache To: jr conlin Content-Type: multipart/alternative; boundary=001a11c252843b356c0528af614b Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Application server authentication new years edition X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jan 2016 19:30:02 -0000 --001a11c252843b356c0528af614b Content-Type: text/plain; charset=UTF-8 Understood - I assume other push services may have similar restrictions, and in general TLS client auth is tricky on both client and server side. That leaves 2.3 only ? I think it's ok - it relies on the same thing as TLS client auth, the sender signing with the private key, and push service checking it against the public key provided at subscribe time. Can we at least make it consistent with the the encryption - i.e. use the same type of key ? In particular it would be nice if an app instance (A) could even use the public key of another instance (B), to allow B to send messages directly to A, without using the app server ( for a future version of the standard, of course - but we should keep it in mind ). Costin On Wed, Jan 6, 2016 at 8:33 AM, jr conlin wrote: > > > On 01/06/2016 01:16 AM, Martin Thomson wrote: > >> On 6 January 2016 at 15:55, Costin Manolache wrote: >> >>> For authentication: 2.1(certificate) would be my preference, and is a >>> well >>> known and established >>> mechanism, followed by 2.6, 2.3. >>> >> Both 2.1 (certs) and 2.6 (token binding) require access to the TLS >> connection. Token binding has the added concern that it is a new >> mechanism that might not be well deployed. >> >> When I inquired, certs did seem possible, but Mozilla folks (JR can >> speak to this better than I), had some operational concerns. JWT >> hoists the authentication information up into HTTP, which was a lot >> easier to manage. >> > We are currently deployed on Amazon Web Services (AWS) using Elastic Load > Balancers (ELBs) to terminate TLS connections for both cost and performance > reasons. The ELBs act as a simple proxy, consume the certificate and > provide no certificate information. AWS has no plans to modify ELB software > to relay the cert information as part of the proxied connection. It is not > possible for any AWS based service to use any cert information to show > authentication, since it is impossible to get that information. > > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --001a11c252843b356c0528af614b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Understood - I assume other push services may have similar= restrictions, and in general TLS client
auth is tricky on both client = and server side.=C2=A0

That leaves 2.3 only ? I th= ink it's ok - it relies on the same thing as TLS client auth, the sende= r=C2=A0
signing with the private key, and push service checking i= t against the public key provided at subscribe time.
Can we at le= ast make it consistent with the the encryption - i.e. use the same type of = key ?=C2=A0
In particular it would be nice if an app instance (A)= could even use the public key of another instance (B),
to allow = B to send messages directly to A, without using the app server ( for a futu= re version of the=C2=A0
standard, of course - but we should keep = it in mind ).=C2=A0



= Costin

On Wed, Jan 6, 2016 at 8:33 AM, jr conlin <jconlin@mozilla.com><= /span> wrote:


On 01/06/2016 01:16 AM, Martin Thomson wrote:
On 6 January 2016 at 15:55, Costin Manolache <costin@gmail.com> wrote:
For authentication:=C2=A0 2.1(certificate) would be my preference, and is a= well
known and established
mechanism, followed by 2.6, 2.3.
Both 2.1 (certs) and 2.6 (token binding) require access to the TLS
connection.=C2=A0 Token binding has the added concern that it is a new
mechanism that might not be well deployed.

When I inquired, certs did seem possible, but Mozilla folks (JR can
speak to this better than I), had some operational concerns.=C2=A0 JWT
hoists the authentication information up into HTTP, which was a lot
easier to manage.
We are currently deployed on Amazon Web Services (AWS) using Elastic Load B= alancers (ELBs) to terminate TLS connections for both cost and performance = reasons. The ELBs act as a simple proxy, consume the certificate and provid= e no certificate information. AWS has no plans to modify ELB software to re= lay the cert information as part of the proxied connection. It is not possi= ble for any AWS based service to use any cert information to show authentic= ation, since it is impossible to get that information.



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

--001a11c252843b356c0528af614b-- From nobody Wed Jan 6 14:24:28 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52EBF1A1ADC for ; Wed, 6 Jan 2016 14:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 hoD6XruQ9I6s for ; Wed, 6 Jan 2016 14:24:22 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 79DA41A1AE3 for ; Wed, 6 Jan 2016 14:24:22 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id n135so165580297qka.2 for ; Wed, 06 Jan 2016 14:24:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5y3zaXqBN7tCKxTWjnerOu3ikTyOFUhEbXJUOYBGUU4=; b=D6VwEdOTYIrTcyZeR14r5x+RPoiPVpklF5c2Jv1+ZMNf/v4XFgn+0GPmKNwfDH5UK7 nqiy9CyWF/+IlaqMO+Atpkc76om3h33vFPESEX4i+ihla+f3c8jQr6X7tuAvjb2nEdOQ 4HFYY9J1n0XIS7r4caTGNLzXvWamoqnzpdK1bS8EKU2sEoFPMLNvAEOpED+s3hqBEQY3 +2vEn22ssHHYJoDGuvCBKWki/+UlkdShLXYgISEA3kapNS+1Gpq6DFa1kzasC0RTrGKw jHy6vLUzCY+o79XwS63SSVy06JIKnRTu1DbQ+6sOmdGx76dB9GMw2ofg358MTB0/p5Cf 4M4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5y3zaXqBN7tCKxTWjnerOu3ikTyOFUhEbXJUOYBGUU4=; b=Tv+rH6hUokkxztFlQvV4IbJlo3p8zWVwb2iwbn3zUcAGBAmjtGG7l6SOOxtNVqKEA9 nSN1D5s3EF51W307PLUjmS2LYHs+6F2rQVpabHEEueinYoRStYkIVkKdUcCOQvGFAI/V yhBYjRTf0n4kyiZSX+wWh9U27E7F/HTi/EBSsOROiT6CT1GbdQUXDeU/OwaQU7A/uoIx xk9YS3ArBfR7G3EuR7EUvGodBTHkkOvaeScEgR/mo3vKUptGpnp2wnFNSprZJTYP4Qks D75ZalIbqKZriDgL33xG079alathLxNSa5Y+cipDZOYgxkpvrFWvasK6bU3MpYsXoxb4 OTkQ== X-Gm-Message-State: ALoCoQnXo5h3xVQIX8Kkxiod1Dj2fIGVN2B0Uva4Qo0gLd48jf7I/OgyatzEPi3Zp7Fc7uFDapIhNQn2I1v502DhMjDVCciHJn8eJZUrFQ2xd19+8TG4nus= MIME-Version: 1.0 X-Received: by 10.129.133.193 with SMTP id v184mr82161884ywf.262.1452119061405; Wed, 06 Jan 2016 14:24:21 -0800 (PST) Received: by 10.37.224.9 with HTTP; Wed, 6 Jan 2016 14:24:21 -0800 (PST) In-Reply-To: References: <568D41D6.40904@mozilla.com> Date: Wed, 6 Jan 2016 14:24:21 -0800 Message-ID: From: Benjamin Bangert To: Costin Manolache Content-Type: multipart/alternative; boundary=001a114f02bed3d4b80528b1d039 Archived-At: Cc: jr conlin , "webpush@ietf.org" Subject: Re: [Webpush] Application server authentication new years edition X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jan 2016 22:24:26 -0000 --001a114f02bed3d4b80528b1d039 Content-Type: text/plain; charset=UTF-8 2.3 would allow us to get the data, but it doesn't address strongly authenticate senders. Discussing this earlier with my manager, there are two additional schemes that we could consider instead of or in addition to 2.3 on a voluntary basis for app-servers. - DKIM: Re-use DKIM in some manner so that an app-server can claim a domain its sending notifications on behalf of. Since DKIM also includes a body hash, it could be used instead of JWT if an app-server wishes to strongly authenticate. - Lets Encrypt Domain Validation: The Lets Encrypt folks have a scheme and tools that automate Domain Validation to prove ownership of a domain (though it unfortunately needs to be tied into a webserver, DKIM is nicer in that aspect of only requiring a DNS addition). Both of these would allow an app-server to change the JWT secret being used if needed with no interaction needed with the push service. Cheers, Ben On Wed, Jan 6, 2016 at 11:29 AM, Costin Manolache wrote: > Understood - I assume other push services may have similar restrictions, > and in general TLS client > auth is tricky on both client and server side. > > That leaves 2.3 only ? I think it's ok - it relies on the same thing as > TLS client auth, the sender > signing with the private key, and push service checking it against the > public key provided at subscribe time. > Can we at least make it consistent with the the encryption - i.e. use the > same type of key ? > In particular it would be nice if an app instance (A) could even use the > public key of another instance (B), > to allow B to send messages directly to A, without using the app server ( > for a future version of the > standard, of course - but we should keep it in mind ). > > > > Costin > > On Wed, Jan 6, 2016 at 8:33 AM, jr conlin wrote: > >> >> >> On 01/06/2016 01:16 AM, Martin Thomson wrote: >> >>> On 6 January 2016 at 15:55, Costin Manolache wrote: >>> >>>> For authentication: 2.1(certificate) would be my preference, and is a >>>> well >>>> known and established >>>> mechanism, followed by 2.6, 2.3. >>>> >>> Both 2.1 (certs) and 2.6 (token binding) require access to the TLS >>> connection. Token binding has the added concern that it is a new >>> mechanism that might not be well deployed. >>> >>> When I inquired, certs did seem possible, but Mozilla folks (JR can >>> speak to this better than I), had some operational concerns. JWT >>> hoists the authentication information up into HTTP, which was a lot >>> easier to manage. >>> >> We are currently deployed on Amazon Web Services (AWS) using Elastic Load >> Balancers (ELBs) to terminate TLS connections for both cost and performance >> reasons. The ELBs act as a simple proxy, consume the certificate and >> provide no certificate information. AWS has no plans to modify ELB software >> to relay the cert information as part of the proxied connection. It is not >> possible for any AWS based service to use any cert information to show >> authentication, since it is impossible to get that information. >> >> >> >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush >> > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > --001a114f02bed3d4b80528b1d039 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2.3 would allow us to get th= e data, but it doesn't address strongly authenticate senders.

Discussing this earlier with my manager, there are two additional schem= es that we could consider instead of or in addition to 2.3 on a voluntary b= asis for app-servers.

- DKIM: Re-use DKIM in some manner so th= at an app-server can claim a domain its sending notifications on behalf of.= Since DKIM also includes a body hash, it could be used instead of JWT if a= n app-server wishes to strongly authenticate.
- Lets Encrypt Domai= n Validation: The Lets Encrypt folks have a scheme and tools that automate = Domain Validation to prove ownership of a domain (though it unfortunately n= eeds to be tied into a webserver, DKIM is nicer in that aspect of only requ= iring a DNS addition).

Both of these would allow an app-server= to change the JWT secret being used if needed with no interaction needed w= ith the push service.

Cheers,
Ben

On Wed, Jan 6, 2016 at 11:2= 9 AM, Costin Manolache <costin@gmail.com> wrote:
Understood - I assume other push ser= vices may have similar restrictions, and in general TLS client
auth is = tricky on both client and server side.=C2=A0

That = leaves 2.3 only ? I think it's ok - it relies on the same thing as TLS = client auth, the sender=C2=A0
signing with the private key, and p= ush service checking it against the public key provided at subscribe time.<= /div>
Can we at least make it consistent with the the encryption - i.e.= use the same type of key ?=C2=A0
In particular it would be nice = if an app instance (A) could even use the public key of another instance (B= ),
to allow B to send messages directly to A, without using the a= pp server ( for a future version of the=C2=A0
standard, of course= - but we should keep it in mind ).=C2=A0



Costin=

On Wed, Jan 6, 2016 at 8:3= 3 AM, jr conlin <jconlin@mozilla.com> wrote:


On 01/06/2016 01:16 AM, Martin Thomson wrote:
On 6 January 2016 at 15:55, Costin Manolache <costin@gmail.com> wrote:
For authentication:=C2=A0 2.1(certificate) would be my preference, and is a= well
known and established
mechanism, followed by 2.6, 2.3.
Both 2.1 (certs) and 2.6 (token binding) require access to the TLS
connection.=C2=A0 Token binding has the added concern that it is a new
mechanism that might not be well deployed.

When I inquired, certs did seem possible, but Mozilla folks (JR can
speak to this better than I), had some operational concerns.=C2=A0 JWT
hoists the authentication information up into HTTP, which was a lot
easier to manage.
We are currently deployed on Amazon Web Services (AWS) using Elastic Load B= alancers (ELBs) to terminate TLS connections for both cost and performance = reasons. The ELBs act as a simple proxy, consume the certificate and provid= e no certificate information. AWS has no plans to modify ELB software to re= lay the cert information as part of the proxied connection. It is not possi= ble for any AWS based service to use any cert information to show authentic= ation, since it is impossible to get that information.



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


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


--001a114f02bed3d4b80528b1d039-- From nobody Wed Jan 6 17:43:12 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004A61A3BA6 for ; Wed, 6 Jan 2016 17:43:11 -0800 (PST) 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 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 SpvCJ-QvNHEz for ; Wed, 6 Jan 2016 17:43:08 -0800 (PST) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::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 3FA661A6EE9 for ; Wed, 6 Jan 2016 17:43:08 -0800 (PST) Received: by mail-ob0-x22f.google.com with SMTP id ba1so314744579obb.3 for ; Wed, 06 Jan 2016 17:43:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sExRTrcTv3Sy+zxDsZWR05+VNF2fjHVM/ZNnal1xM6g=; b=AN/0FkD1mQufh4TjQFihx7ZMLbCGl2Sv5FxhaMzqBihnkCQp7ztSzVnletUNGL6e2+ +Yc0Z+hHzT0vrqfnxETnh/S39WZebNn4zlEMz2FexE0XuTbpEIdfy10Wl4s2S0SX7iE2 PCZDHdqCF9DcsJ36sLpZQYHdhXha/abhFjyNa1z67ARpthffHWdDBMpAGbJ9HEiPU59V RvCuDRrjZSaAOqxnTfUE38jG1RuPKeEqed4i/6mZuN3hjTXn9a4kXrVTygLY0OLdW1WU G3WRXzixELBCxaFP/89RnWjKeUnpVe1rICkShjvkMVcQXOsJAds6+R2ey4FlkFLffWNy luzw== MIME-Version: 1.0 X-Received: by 10.182.171.8 with SMTP id aq8mr30897632obc.51.1452130987558; Wed, 06 Jan 2016 17:43:07 -0800 (PST) Received: by 10.76.8.74 with HTTP; Wed, 6 Jan 2016 17:43:07 -0800 (PST) In-Reply-To: References: <568D41D6.40904@mozilla.com> Date: Wed, 6 Jan 2016 17:43:07 -0800 Message-ID: From: Costin Manolache To: Benjamin Bangert Content-Type: multipart/alternative; boundary=e89a8ff1ccaaae50fd0528b497de Archived-At: Cc: jr conlin , "webpush@ietf.org" Subject: Re: [Webpush] Application server authentication new years edition X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jan 2016 01:43:11 -0000 --e89a8ff1ccaaae50fd0528b497de Content-Type: text/plain; charset=UTF-8 On Wed, Jan 6, 2016 at 2:24 PM, Benjamin Bangert wrote: > 2.3 would allow us to get the data, but it doesn't address strongly > authenticate senders. > 2.3 is not authenticating the contact info provided by senders, just that sender is the same that the UA requested. The subscribe in the UA includes the public key of the sender, and 2.3 AFAIK strongly authenticate the fact that the sender has access to the private key. The contact information they chose to include in the JWT is not authenticated at all the push service can only verify the sender is what the UA authorized, and can block/throttle that sender without affecting other senders. > > Discussing this earlier with my manager, there are two additional schemes > that we could consider instead of or in addition to 2.3 on a voluntary > basis for app-servers. > > - DKIM: Re-use DKIM in some manner so that an app-server can claim a > domain its sending notifications on behalf of. Since DKIM also includes a > body hash, it could be used instead of JWT if an app-server wishes to > strongly authenticate. > - Lets Encrypt Domain Validation: The Lets Encrypt folks have a scheme and > tools that automate Domain Validation to prove ownership of a domain > (though it unfortunately needs to be tied into a webserver, DKIM is nicer > in that aspect of only requiring a DNS addition). > > Both of these would allow an app-server to change the JWT secret being > used if needed with no interaction needed with the push service. > Yes, they would also verify contact info - I have a feeling we're trying to avoid relying too much on the contact info ( i.e. domain name of the app server ). If the contact info is voluntary - I don't think we need to make it too complex by adding verification. Rotating the identity and keys used by sender normally happens when the app is updated, the sender can subscribe with the new key, and can use 2 subscriptions while migrating. The fact that subscriptions can be rotated or can expire helps. Would be good to mention in the draft that a push service that requires or accepts subscription association (== authorization) should also allow multiple subscriptions for an app. I would expect verification of the sender to be useful for non-free services - in which case the public key of the sender will need more than verification (i.e. will need to be associated with a credit card :-) Costin > > Cheers, > Ben > > On Wed, Jan 6, 2016 at 11:29 AM, Costin Manolache > wrote: > >> Understood - I assume other push services may have similar restrictions, >> and in general TLS client >> auth is tricky on both client and server side. >> >> That leaves 2.3 only ? I think it's ok - it relies on the same thing as >> TLS client auth, the sender >> signing with the private key, and push service checking it against the >> public key provided at subscribe time. >> Can we at least make it consistent with the the encryption - i.e. use the >> same type of key ? >> In particular it would be nice if an app instance (A) could even use the >> public key of another instance (B), >> to allow B to send messages directly to A, without using the app server ( >> for a future version of the >> standard, of course - but we should keep it in mind ). >> >> >> >> Costin >> >> On Wed, Jan 6, 2016 at 8:33 AM, jr conlin wrote: >> >>> >>> >>> On 01/06/2016 01:16 AM, Martin Thomson wrote: >>> >>>> On 6 January 2016 at 15:55, Costin Manolache wrote: >>>> >>>>> For authentication: 2.1(certificate) would be my preference, and is a >>>>> well >>>>> known and established >>>>> mechanism, followed by 2.6, 2.3. >>>>> >>>> Both 2.1 (certs) and 2.6 (token binding) require access to the TLS >>>> connection. Token binding has the added concern that it is a new >>>> mechanism that might not be well deployed. >>>> >>>> When I inquired, certs did seem possible, but Mozilla folks (JR can >>>> speak to this better than I), had some operational concerns. JWT >>>> hoists the authentication information up into HTTP, which was a lot >>>> easier to manage. >>>> >>> We are currently deployed on Amazon Web Services (AWS) using Elastic >>> Load Balancers (ELBs) to terminate TLS connections for both cost and >>> performance reasons. The ELBs act as a simple proxy, consume the >>> certificate and provide no certificate information. AWS has no plans to >>> modify ELB software to relay the cert information as part of the proxied >>> connection. It is not possible for any AWS based service to use any cert >>> information to show authentication, since it is impossible to get that >>> information. >>> >>> >>> >>> _______________________________________________ >>> Webpush mailing list >>> Webpush@ietf.org >>> https://www.ietf.org/mailman/listinfo/webpush >>> >> >> >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush >> >> > --e89a8ff1ccaaae50fd0528b497de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 6, 2016 at 2:24 PM, Benjamin Bangert <bbangert@mozilla.com= > wrote:
=
2.3 would allow us to get the data, but it doesn&#= 39;t address strongly authenticate senders.

2.3 is not authenticating th= e contact info provided by senders, just that sender is the same that
=
the UA requested.

The subscribe in the UA inc= ludes the public key of the sender, and 2.3 AFAIK strongly authenticate
the fact that the sender has access to the private key.=C2=A0
<= div>
The contact information they chose to include in the JWT= is not authenticated at all =C2=A0the push
service can only veri= fy the sender is what the UA authorized, and can block/throttle that sender= without=C2=A0
affecting other senders.=C2=A0

=C2=A0

Discussing this earlier with my manager, the= re are two additional schemes that we could consider instead of or in addit= ion to 2.3 on a voluntary basis for app-servers.

- DKIM: Re-us= e DKIM in some manner so that an app-server can claim a domain its sending = notifications on behalf of. Since DKIM also includes a body hash, it could = be used instead of JWT if an app-server wishes to strongly authenticate.
- Lets Encrypt Domain Validation: The Lets Encrypt folks have a sche= me and tools that automate Domain Validation to prove ownership of a domain= (though it unfortunately needs to be tied into a webserver, DKIM is nicer = in that aspect of only requiring a DNS addition).

Both of thes= e would allow an app-server to change the JWT secret being used if needed w= ith no interaction needed with the push service.

Yes, they would also verify contact info - I ha= ve a feeling we're trying to avoid relying too much on=C2=A0
= the contact info ( i.e. domain name of the app server ). If the contact inf= o is voluntary - I don't think we need
to make it too complex= by adding verification.

Rotating the identity and= keys used by sender normally happens when the app is updated, the sender c= an subscribe with the new key, and can use 2 subscriptions while migrating.= The fact that subscriptions can be
rotated or can expire helps. = Would be good to mention in the draft that a push service that requires or = accepts subscription
association (=3D=3D authorization) should al= so allow multiple subscriptions for an app.=C2=A0

= I would expect verification of the sender to be useful for non-free service= s - in which case the public key
=C2=A0of the sender will need mo= re than verification (i.e. will need to be associated with a credit card :-= )

Costin

=C2=A0

Cheers,
=
Ben

On Wed, Jan 6, 2016 at 11:29 AM, = Costin Manolache <costin@gmail.com> wrote:
Understood - I assume other push services = may have similar restrictions, and in general TLS client
auth is tricky= on both client and server side.=C2=A0

That leaves= 2.3 only ? I think it's ok - it relies on the same thing as TLS client= auth, the sender=C2=A0
signing with the private key, and push se= rvice checking it against the public key provided at subscribe time.
<= div>Can we at least make it consistent with the the encryption - i.e. use t= he same type of key ?=C2=A0
In particular it would be nice if an = app instance (A) could even use the public key of another instance (B),
to allow B to send messages directly to A, without using the app ser= ver ( for a future version of the=C2=A0
standard, of course - but= we should keep it in mind ).=C2=A0



Costin

On W= ed, Jan 6, 2016 at 8:33 AM, jr conlin <jconlin@mozilla.com> wrote:


On 01/06/2016 01:16 AM, Martin Thomson wrote:
On 6 January 2016 at 15:55, Costin Manolache <costin@gmail.com> wrote:
For authentication:=C2=A0 2.1(certificate) would be my preference, and is a= well
known and established
mechanism, followed by 2.6, 2.3.
Both 2.1 (certs) and 2.6 (token binding) require access to the TLS
connection.=C2=A0 Token binding has the added concern that it is a new
mechanism that might not be well deployed.

When I inquired, certs did seem possible, but Mozilla folks (JR can
speak to this better than I), had some operational concerns.=C2=A0 JWT
hoists the authentication information up into HTTP, which was a lot
easier to manage.
We are currently deployed on Amazon Web Services (AWS) using Elastic Load B= alancers (ELBs) to terminate TLS connections for both cost and performance = reasons. The ELBs act as a simple proxy, consume the certificate and provid= e no certificate information. AWS has no plans to modify ELB software to re= lay the cert information as part of the proxied connection. It is not possi= ble for any AWS based service to use any cert information to show authentic= ation, since it is impossible to get that information.



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


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



--e89a8ff1ccaaae50fd0528b497de-- From nobody Wed Jan 6 18:11:19 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE951A6F51 for ; Wed, 6 Jan 2016 18:11:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 74ro_9Yx-qAi for ; Wed, 6 Jan 2016 18:11:14 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::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 347731A03AB for ; Wed, 6 Jan 2016 18:11:14 -0800 (PST) Received: by mail-yk0-x230.google.com with SMTP id v14so232288466ykd.3 for ; Wed, 06 Jan 2016 18:11:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dIku4mCbTrKim3MNwK53XiDs60ETkznrgAsGuk3pEuQ=; b=PNq1KCdp4C3n/Ac4etGtcj2GjtPkeXrwawPbBCB854zTSedwgyHdUH17wN49DJS1H9 9bOLxkU1FxPKcuNfbtUTSiApOUqmOepLBbSWujemKSXauv9DI9N+zCZsCytcRDG0xuiP YjDFJcr8SyfdzxorCna5E6/6p6ZRi9xKyo0X/awRkm1ABgNhYqVShuWj+/ISDelkkV3q YmN/2ULoAOo0i6yse3y8K+bfZmRyvoVaKQOknZBLlcASBV3h5gwv86+N2aIt9xOPCFwp keh5RpbbJzUYyhulojWe+mObxzTqkvPPogn5R6CKQ8CgAaK+XoFI6J6Tg/w+IFQDYUqD ewLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dIku4mCbTrKim3MNwK53XiDs60ETkznrgAsGuk3pEuQ=; b=NBA7fuk0SSUKdTWu7NBoC3oDv/lfTr0Zgo3htd/V2lqaDd8Nr8Cm+2IKPt6ZGQVE4u GISMWdLs28sYKobwi0xLK97CJ+m5mu7PGuumA4xKTCxaivnToaku2rWTMLcPT7GBtiqf dbrX4JXzyd4ZbQRleXIL7vOV/Mv6eQEEkKpkne8FxyTgF/jlGKSEGzeKwgDshVu8n8Vv FWA8a/4uk6FOKKdSLk0/MwgNoWUk77aDIvSor/EJzp5vmmIwznviygPAvgJjl+XcHlfA T+NFtyES/Fd3v1IUusiM1os/o4umDXhETP0Hr0Yk63LmSnZYANvu11lE0/sAFhCN7Dji PC2Q== X-Gm-Message-State: ALoCoQlBW7U0cLuIMsrxWbd+LHoe9Z9yt0LXbb2eNR9XT6KtuuJiD0uYIegocmdfCcJEXZiiC0HYldmZKny4Ja3yjlgxBf1Nkf2Q5FPKfKeAKa8DB7bZFjk= MIME-Version: 1.0 X-Received: by 10.13.207.129 with SMTP id r123mr83993162ywd.27.1452132673346; Wed, 06 Jan 2016 18:11:13 -0800 (PST) Received: by 10.37.224.9 with HTTP; Wed, 6 Jan 2016 18:11:13 -0800 (PST) In-Reply-To: References: <568D41D6.40904@mozilla.com> Date: Wed, 6 Jan 2016 18:11:13 -0800 Message-ID: From: Benjamin Bangert To: Costin Manolache Content-Type: multipart/alternative; boundary=001a114e68862997e90528b4fcf6 Archived-At: Cc: jr conlin , "webpush@ietf.org" Subject: Re: [Webpush] Application server authentication new years edition X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jan 2016 02:11:18 -0000 --001a114e68862997e90528b4fcf6 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 6, 2016 at 5:43 PM, Costin Manolache wrote: > On Wed, Jan 6, 2016 at 2:24 PM, Benjamin Bangert > wrote: > >> 2.3 would allow us to get the data, but it doesn't address strongly >> authenticate senders. >> > > 2.3 is not authenticating the contact info provided by senders, just that > sender is the same that > the UA requested. > > The subscribe in the UA includes the public key of the sender, and 2.3 > AFAIK strongly authenticate > the fact that the sender has access to the private key. > > The contact information they chose to include in the JWT is not > authenticated at all the push > service can only verify the sender is what the UA authorized, and can > block/throttle that sender without > affecting other senders. > Right, that this is not strongly authenticated means we can't do something like build a developer dashboard that might expose notification traffic information associated with the JWT. ie, if a Push Service wanted to provide developers with a diagnostic dashboard similar to what GCM Diagnostics provides GCM users. > > > >> >> Discussing this earlier with my manager, there are two additional schemes >> that we could consider instead of or in addition to 2.3 on a voluntary >> basis for app-servers. >> >> - DKIM: Re-use DKIM in some manner so that an app-server can claim a >> domain its sending notifications on behalf of. Since DKIM also includes a >> body hash, it could be used instead of JWT if an app-server wishes to >> strongly authenticate. >> - Lets Encrypt Domain Validation: The Lets Encrypt folks have a scheme >> and tools that automate Domain Validation to prove ownership of a domain >> (though it unfortunately needs to be tied into a webserver, DKIM is nicer >> in that aspect of only requiring a DNS addition). >> >> Both of these would allow an app-server to change the JWT secret being >> used if needed with no interaction needed with the push service. >> > > Yes, they would also verify contact info - I have a feeling we're trying > to avoid relying too much on > the contact info ( i.e. domain name of the app server ). If the contact > info is voluntary - I don't think we need > to make it too complex by adding verification. > > Rotating the identity and keys used by sender normally happens when the > app is updated, the sender can subscribe with the new key, and can use 2 > subscriptions while migrating. The fact that subscriptions can be > rotated or can expire helps. Would be good to mention in the draft that a > push service that requires or accepts subscription > association (== authorization) should also allow multiple subscriptions > for an app. > > I would expect verification of the sender to be useful for non-free > services - in which case the public key > of the sender will need more than verification (i.e. will need to be > associated with a credit card :-) > > Ah, in our case we were thinking of providing some basic diagnostic information in a dashboard free-of-charge. I didn't think the GCM Diagnostic panel required payment, but it uses the strong authentication by requiring a sign-up process and such. I was hoping that there would be some way push service providers could provide a higher degree of authentication in a standard way that wouldn't require app developers to go through extensive sign-up processes at each push service, but perhaps that's just wishful thinking. Cheers, Ben --001a114e68862997e90528b4fcf6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 6, 2016 at 5:43 PM, Costin Manolache <costin@gmail.com> wrote:
On Wed, Jan 6, 20= 16 at 2:24 PM, Benjamin Bangert <bbangert@mozilla.com> wr= ote:
2.3 would allow us to get the data, but it doesn't address s= trongly authenticate senders.
=

2.3 is not authenticating the conta= ct info provided by senders, just that sender is the same that
th= e UA requested.

The subscribe in the UA includes t= he public key of the sender, and 2.3 AFAIK strongly authenticate
= the fact that the sender has access to the private key.=C2=A0
The contact information they chose to include in the JWT is not= authenticated at all =C2=A0the push
service can only verify the = sender is what the UA authorized, and can block/throttle that sender withou= t=C2=A0
affecting other senders.=C2=A0

Right, that this is not strongly authenticate= d means we can't do something like build a developer dashboard that mig= ht expose notification traffic information associated with the JWT. ie, if = a Push Service wanted to provide developers with a diagnostic dashboard sim= ilar to what GCM Diagnostics provides GCM users.

=C2=A0
=C2=A0

= Discussing this earlier with my manager, there are two additional schemes t= hat we could consider instead of or in addition to 2.3 on a voluntary basis= for app-servers.

- DKIM: Re-use DKIM in some manner so that a= n app-server can claim a domain its sending notifications on behalf of. Sin= ce DKIM also includes a body hash, it could be used instead of JWT if an ap= p-server wishes to strongly authenticate.
- Lets Encrypt Domain Va= lidation: The Lets Encrypt folks have a scheme and tools that automate Doma= in Validation to prove ownership of a domain (though it unfortunately needs= to be tied into a webserver, DKIM is nicer in that aspect of only requirin= g a DNS addition).

Both of these would allow an app-server to = change the JWT secret being used if needed with no interaction needed with = the push service.

<= div>Yes, they would also verify contact info - I have a feeling we're t= rying to avoid relying too much on=C2=A0
the contact info ( i.e. = domain name of the app server ). If the contact info is voluntary - I don&#= 39;t think we need
to make it too complex by adding verification.=

Rotating the identity and keys used by sender nor= mally happens when the app is updated, the sender can subscribe with the ne= w key, and can use 2 subscriptions while migrating. The fact that subscript= ions can be
rotated or can expire helps. Would be good to mention= in the draft that a push service that requires or accepts subscription
association (=3D=3D authorization) should also allow multiple subscr= iptions for an app.=C2=A0

I would expect verificat= ion of the sender to be useful for non-free services - in which case the pu= blic key
=C2=A0of the sender will need more than verification (i.= e. will need to be associated with a credit card :-)

<= /div>

Ah, in our case we were thinking of p= roviding some basic diagnostic information in a dashboard free-of-charge. I= didn't think the GCM Diagnostic panel required payment, but it uses th= e strong authentication by requiring a sign-up process and such.

I was hoping that there would be some way push service providers co= uld provide a higher degree of authentication in a standard way that wouldn= 't require app developers to go through extensive sign-up processes at = each push service, but perhaps that's just wishful thinking.

Cheers,
Ben
--001a114e68862997e90528b4fcf6-- From nobody Wed Jan 6 19:29:47 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9434E1A6FBE for ; Wed, 6 Jan 2016 19:29:45 -0800 (PST) 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 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 Rvp-qhdA6WDh for ; Wed, 6 Jan 2016 19:29:44 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::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 C958B1A6FB9 for ; Wed, 6 Jan 2016 19:29:43 -0800 (PST) Received: by mail-ig0-x231.google.com with SMTP id ik10so46490829igb.1 for ; Wed, 06 Jan 2016 19:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ow89xlItmQubNAcLyqTlfGEkiwfABANn3VzfDGnlqOc=; b=eUN3HC3CDt1L4k4h9A/mbQVudOiAUVLpu9V2gNtOQL/VHgabL0Dox6LgY1MB3CShG6 ejd6tUM+nAmwN1tLZz1+arMN73W+hpP6adQnnopsSfuaUmgxVzUWanc41Fj2A3RLTQ3O 86EOvke7qh91p3anN64tFKcv54sK1yiih7ZNdGLlUcZj5pyGO87RzsPalW3qzjR5R3ag hqZRPS+Nqic7J87lwW+b3b2UQSjFnnR2evuvu7O8pMMuvaJNunoUIPLOUdI4PuI8ZOm8 ZusnoNytUicAvkWcQhyVfhdZMxYRU8MwQ47sFhTk847aJfV5IxiGGsSPxKrxeE9RN8Er bW0w== MIME-Version: 1.0 X-Received: by 10.50.60.6 with SMTP id d6mr13537926igr.94.1452137383204; Wed, 06 Jan 2016 19:29:43 -0800 (PST) Received: by 10.36.149.130 with HTTP; Wed, 6 Jan 2016 19:29:43 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Jan 2016 14:29:43 +1100 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ben Bangert , Costin Manolache , "webpush@ietf.org" Subject: Re: [Webpush] Application server authentication new years edition X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jan 2016 03:29:45 -0000 Mega-multi-response. On 7 January 2016 at 05:01, Costin Manolache wrote: > At the same time you can't force push service providers to accept > unauthenticated/unauthorized sending either. Or require them to > provide unlimited (and free) service to everyone regardless of how much > they're abusing/hurting users or networks. The authorization question is challenging, particularly when it comes to abuse of limited resources (user attention, battery power, push service capacity). It would be good to understand what the invariants are on each service. If Google are unwilling to allow completely unauthenticated requests, then I think that we could insist on something voluntary. I'm reluctant to do that because it makes it more difficult for application server developers to get a start, but that can be mitigate with good tooling, I guess. On the other hand, if there are cases where a small number of requests can be made without extra authentication, then the proposed option would be ideal. That would allow people to experiment a little before having to tool up. > How about 2.1 AND 2.3 ? Push servers should support both, clients > should use what they can. I'd like to avoid that situation because it hurts a lot more all around. We like to save that option for the really tough problems (video codecs, for example). > And it may be the way to allow the choice on app server side - either by > having an 'isAuthorizationRequired()' or an error code when attempting to > subscribe without a public key. Again, that makes it more difficult to use the API, and I'd be very reluctant to take that option unless the alternatives are untenable. On 7 January 2016 at 06:29, Costin Manolache wrote: > That leaves 2.3 only ? I think it's ok - it relies on the same thing as TLS > client auth, the sender > signing with the private key, and push service checking it against the > public key provided at subscribe time. > Can we at least make it consistent with the the encryption - i.e. use the > same type of key ? We can certainly use P-256 for that as well; that's what is proposed. However, it would need to be a different key pair, since all the experts recommend against using the same key for signing and key exchange. (There isn't an actual attack, but the dual use isn't provably safe.) On 7 January 2016 at 12:43, Costin Manolache wrote: > Yes, they would also verify contact info - I have a feeling we're trying to > avoid relying too much on > the contact info ( i.e. domain name of the app server ). If the contact info > is voluntary - I don't think we need > to make it too complex by adding verification. I very much agree with this sentiment. That contact information can be verified, though I think that we should probably start out by relying on manual processes for that. We can layer other mechanisms on top. I'm not particularly fond of the idea of using something as heavyweight as what Ben suggested. Something much simpler might work, but I don't think that we need that. An absolute requirement to use something that that would be a big problem. On 7 January 2016 at 13:11, Benjamin Bangert wrote: > Right, that this is not strongly authenticated means we can't do something > like build a developer dashboard that might expose notification traffic > information associated with the JWT. ie, if a Push Service wanted to provide > developers with a diagnostic dashboard similar to what GCM Diagnostics > provides GCM users. If this is your concern, why not ask the dashboard user to prove that they have access to the JWK private key when logging in? That's relatively easy to do. You don't actually need to know who they are in that case. (Though you could use the dashboard UI to do things like email verification, as many sites do.) From nobody Wed Jan 6 21:21:24 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD0F1A21A3 for ; Wed, 6 Jan 2016 21:21:23 -0800 (PST) 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 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 mGkmdErZO8T9 for ; Wed, 6 Jan 2016 21:21:21 -0800 (PST) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::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 2B80E1A1BFE for ; Wed, 6 Jan 2016 21:21:21 -0800 (PST) Received: by mail-ob0-x22c.google.com with SMTP id ba1so318027317obb.3 for ; Wed, 06 Jan 2016 21:21:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e09Boqp8ATSeSuFNdHoUeOGJxEfFFrNUaUIpXAqnoY0=; b=DM/koGpX2K3bCzjSSTX+hR5O2TVxHNmciDJXA0/fIk2Eo+y0/JVGsDWy5iUFgHWTZ5 cAywzmA9Y6D+jYSUQ5XXCfT81Ve1b64LPup9/Hiv0PSlC9DD36uysxtq7x1u66cSiSMD EmvhtdJSxnfJzoNVkbLQc3ALuk8HFobrSclO50hJk3I0HS8UHdZ9w/SBMfdW0vSyFMhC t8tvdaLaFEmYTAQjRpd3pkaZ+SlihQ36uu43STYTCJJL0gZ+yWPaBN/gjgOZdEcKWE2E JntvNBAjesczCX5UD03FTJqKRvoIhdo6jv7B/kRMxo+6erak9ePEvPlmru29R+mPk/Oc aMpA== MIME-Version: 1.0 X-Received: by 10.60.135.98 with SMTP id pr2mr65021348oeb.65.1452144080462; Wed, 06 Jan 2016 21:21:20 -0800 (PST) Received: by 10.76.8.74 with HTTP; Wed, 6 Jan 2016 21:21:20 -0800 (PST) In-Reply-To: References: <568D41D6.40904@mozilla.com> Date: Wed, 6 Jan 2016 21:21:20 -0800 Message-ID: From: Costin Manolache To: Benjamin Bangert Content-Type: multipart/alternative; boundary=047d7b417921142b2b0528b7a4a5 Archived-At: Cc: jr conlin , "webpush@ietf.org" Subject: Re: [Webpush] Application server authentication new years edition X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jan 2016 05:21:23 -0000 --047d7b417921142b2b0528b7a4a5 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 6, 2016 at 6:11 PM, Benjamin Bangert wrote: > On Wed, Jan 6, 2016 at 5:43 PM, Costin Manolache wrote: > >> On Wed, Jan 6, 2016 at 2:24 PM, Benjamin Bangert >> wrote: >> >>> 2.3 would allow us to get the data, but it doesn't address strongly >>> authenticate senders. >>> >> >> 2.3 is not authenticating the contact info provided by senders, just that >> sender is the same that >> the UA requested. >> >> The subscribe in the UA includes the public key of the sender, and 2.3 >> AFAIK strongly authenticate >> the fact that the sender has access to the private key. >> >> The contact information they chose to include in the JWT is not >> authenticated at all the push >> service can only verify the sender is what the UA authorized, and can >> block/throttle that sender without >> affecting other senders. >> > > Right, that this is not strongly authenticated means we can't do something > like build a developer dashboard that might expose notification traffic > information associated with the JWT. ie, if a Push Service wanted to > provide developers with a diagnostic dashboard similar to what GCM > Diagnostics provides GCM users. > That shouldn't be a problem - there are many ways you can associate a real developer account with the public key, using the private key to sign a statement. Or you could exchange a JWT with a cookie or token that allows access to the dev tools, without requiring a separate account. > > > >> >> >> >>> >>> Discussing this earlier with my manager, there are two additional >>> schemes that we could consider instead of or in addition to 2.3 on a >>> voluntary basis for app-servers. >>> >>> - DKIM: Re-use DKIM in some manner so that an app-server can claim a >>> domain its sending notifications on behalf of. Since DKIM also includes a >>> body hash, it could be used instead of JWT if an app-server wishes to >>> strongly authenticate. >>> - Lets Encrypt Domain Validation: The Lets Encrypt folks have a scheme >>> and tools that automate Domain Validation to prove ownership of a domain >>> (though it unfortunately needs to be tied into a webserver, DKIM is nicer >>> in that aspect of only requiring a DNS addition). >>> >>> Both of these would allow an app-server to change the JWT secret being >>> used if needed with no interaction needed with the push service. >>> >> >> Yes, they would also verify contact info - I have a feeling we're trying >> to avoid relying too much on >> the contact info ( i.e. domain name of the app server ). If the contact >> info is voluntary - I don't think we need >> to make it too complex by adding verification. >> >> Rotating the identity and keys used by sender normally happens when the >> app is updated, the sender can subscribe with the new key, and can use 2 >> subscriptions while migrating. The fact that subscriptions can be >> rotated or can expire helps. Would be good to mention in the draft that a >> push service that requires or accepts subscription >> association (== authorization) should also allow multiple subscriptions >> for an app. >> >> I would expect verification of the sender to be useful for non-free >> services - in which case the public key >> of the sender will need more than verification (i.e. will need to be >> associated with a credit card :-) >> >> > Ah, in our case we were thinking of providing some basic diagnostic > information in a dashboard free-of-charge. I didn't think the GCM > Diagnostic panel required payment, but it uses the strong authentication by > requiring a sign-up process and such. > GCM doesn't require payment for diagnostic or anything else, but there are providers that charge, and for them the 'contact info' would be more important and need to be more specific. > > I was hoping that there would be some way push service providers could > provide a higher degree of authentication in a standard way that wouldn't > require app developers to go through extensive sign-up processes at each > push service, but perhaps that's just wishful thinking. > It is not impossible - once we have the auth defined, it can be used to access other endpoints - debugging, etc. But probably their definition will need to be in a separate future draft. Costin --047d7b417921142b2b0528b7a4a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 6, 2016 at 6:11 PM, Benjamin Bangert <= bbangert@mozilla.= com> wrote:
On= Wed, Jan 6, 2016 at 5:43 PM, Costin Manolache <costin@gmail.com> wrote:
On Wed, Jan 6, 2016 at 2:= 24 PM, Benjamin Bangert <bbangert@mozilla.com> wrote:
=
2.3 would allow us to get the data, but it doesn't address strongly = authenticate senders.

2.3 is not authenticating the contact info = provided by senders, just that sender is the same that
the UA req= uested.

The subscribe in the UA includes the publi= c key of the sender, and 2.3 AFAIK strongly authenticate
the fact= that the sender has access to the private key.=C2=A0

<= div>The contact information they chose to include in the JWT is not authent= icated at all =C2=A0the push
service can only verify the sender i= s what the UA authorized, and can block/throttle that sender without=C2=A0<= /div>
affecting other senders.=C2=A0

Right, that this is not strongly authenticated= means we can't do something like build a developer dashboard that migh= t expose notification traffic information associated with the JWT. ie, if a= Push Service wanted to provide developers with a diagnostic dashboard simi= lar to what GCM Diagnostics provides GCM users.
=

That shouldn't be a problem - there ar= e many ways you can associate a real developer account with the public key,=
using the private key to sign a statement.=C2=A0

<= /div>
Or you could exchange a JWT with a cookie or token that allows ac= cess to the dev tools, without requiring a separate=C2=A0
account= .=C2=A0

=C2=A0

=C2=A0

=C2=A0

Discussing this earlier with my manager, the= re are two additional schemes that we could consider instead of or in addit= ion to 2.3 on a voluntary basis for app-servers.

- DKIM: Re-us= e DKIM in some manner so that an app-server can claim a domain its sending = notifications on behalf of. Since DKIM also includes a body hash, it could = be used instead of JWT if an app-server wishes to strongly authenticate.
- Lets Encrypt Domain Validation: The Lets Encrypt folks have a sche= me and tools that automate Domain Validation to prove ownership of a domain= (though it unfortunately needs to be tied into a webserver, DKIM is nicer = in that aspect of only requiring a DNS addition).

Both of thes= e would allow an app-server to change the JWT secret being used if needed w= ith no interaction needed with the push service.

Yes, they would also verify contact info= - I have a feeling we're trying to avoid relying too much on=C2=A0
the contact info ( i.e. domain name of the app server ). If the cont= act info is voluntary - I don't think we need
to make it too = complex by adding verification.

Rotating the ident= ity and keys used by sender normally happens when the app is updated, the s= ender can subscribe with the new key, and can use 2 subscriptions while mig= rating. The fact that subscriptions can be
rotated or can expire = helps. Would be good to mention in the draft that a push service that requi= res or accepts subscription
association (=3D=3D authorization) sh= ould also allow multiple subscriptions for an app.=C2=A0

I would expect verification of the sender to be useful for non-free = services - in which case the public key
=C2=A0of the sender will = need more than verification (i.e. will need to be associated with a credit = card :-)


Ah, in our case we were thinking of providing some basic diagnostic inform= ation in a dashboard free-of-charge. I didn't think the GCM Diagnostic = panel required payment, but it uses the strong authentication by requiring = a sign-up process and such.
GCM doesn't require payment for diagnostic or anything els= e, but there are providers that charge, and for them
the 'con= tact info' would be more important and need to be more specific.=C2=A0<= /div>


=C2=A0

I was hoping that there would be some way push serv= ice providers could provide a higher degree of authentication in a standard= way that wouldn't require app developers to go through extensive sign-= up processes at each push service, but perhaps that's just wishful thin= king.

It is not= impossible - once we have the auth defined, it can be used to access other= endpoints - debugging, etc.
But probably their definition will n= eed to be in a separate future draft.

Costin
=

--047d7b417921142b2b0528b7a4a5-- From nobody Wed Jan 6 21:43:19 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A84D1A6FFC for ; Wed, 6 Jan 2016 21:43:18 -0800 (PST) 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 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 I9YhgHjFbIMs for ; Wed, 6 Jan 2016 21:43:15 -0800 (PST) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::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 C023F1A6FF8 for ; Wed, 6 Jan 2016 21:43:15 -0800 (PST) Received: by mail-ob0-x22c.google.com with SMTP id wp13so183216283obc.1 for ; Wed, 06 Jan 2016 21:43:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DLl16LRDbNwMacmaQAd3zvQcOW2KEdLkp0e6cqCKDqw=; b=Rx3VauhThvb4hOW00rzhEXRRHCcFa0cYI1X2FRas9CAj1UvlK5WWaR0agstIuzYj3c QcV4QmCGaUefWN0U88BGv1L3LO86CiDE+XQIIntJDSEw1Cf4MVKS5zZDSupb3KLces6j zdeXH7nALOfSZ5s53k0y/TD7vN8gYvMbHt0TQ8kV1+verWhDGdno5c/yZa2/XrxaQYEG IWpNvGZVVE7OlWhy5J+P3N63c4BUhBFPfi1wIIXlA6T3xAiIHU3kc15l4N6wzg/r5lyK 0zfwSJa4IXj8+Ja/P9kAZH9ehYk2IuYp2QP8no+Ys/xBqtHAbXVFehMPrTo4j5CIzN84 3DEg== MIME-Version: 1.0 X-Received: by 10.60.159.105 with SMTP id xb9mr46701384oeb.26.1452145395136; Wed, 06 Jan 2016 21:43:15 -0800 (PST) Received: by 10.76.8.74 with HTTP; Wed, 6 Jan 2016 21:43:15 -0800 (PST) In-Reply-To: References: Date: Wed, 6 Jan 2016 21:43:15 -0800 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7bd768e870858c0528b7f248 Archived-At: Cc: Ben Bangert , Costin Manolache , "webpush@ietf.org" Subject: Re: [Webpush] Application server authentication new years edition X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jan 2016 05:43:18 -0000 --047d7bd768e870858c0528b7f248 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 6, 2016 at 7:29 PM, Martin Thomson wrote: > Mega-multi-response. > > On 7 January 2016 at 05:01, Costin Manolache wrote: > > At the same time you can't force push service providers to accept > > unauthenticated/unauthorized sending either. Or require them to > > provide unlimited (and free) service to everyone regardless of how much > > they're abusing/hurting users or networks. > > The authorization question is challenging, particularly when it comes > to abuse of limited resources (user attention, battery power, push > service capacity). It would be good to understand what the invariants > are on each service. > > If Google are unwilling to allow completely unauthenticated requests, > then I think that we could insist on something voluntary. I'm > reluctant to do that because it makes it more difficult for > application server developers to get a start, but that can be mitigate > with good tooling, I guess. > > On the other hand, if there are cases where a small number of requests > can be made without extra authentication, then the proposed option > would be ideal. That would allow people to experiment a little before > having to tool up. > Completely unauthenticated requests would be an extremely hard sell, and I suspect other push services will be in the same position (at least after some time). Also I don't think developers would benefit much - generating a signed JWT token is much simpler than encryption, and it already has plenty of libraries. And it won't benefit them too much to start an app without authentication, than get random rejections or errors - or worse, launch it and than realizing it doesn't work. We had a period of 'free quota/contact us if you need more' - it was not fun. > > How about 2.1 AND 2.3 ? Push servers should support both, clients > > should use what they can. > > I'd like to avoid that situation because it hurts a lot more all > around. We like to save that option for the really tough problems > (video codecs, for example). > I think the fact TLS client auth doesn't work on some providers is enough to kill it at least for this version, I didn't know it's not supported. That leaves 2.3 only. > > > And it may be the way to allow the choice on app server side - either by > > having an 'isAuthorizationRequired()' or an error code when attempting to > > subscribe without a public key. > > Again, that makes it more difficult to use the API, and I'd be very > reluctant to take that option unless the alternatives are untenable. > I agree - IMHO just passing the sender key for all providers is cleanest and least risky option. > > On 7 January 2016 at 06:29, Costin Manolache wrote: > > That leaves 2.3 only ? I think it's ok - it relies on the same thing as > TLS > > client auth, the sender > > signing with the private key, and push service checking it against the > > public key provided at subscribe time. > > Can we at least make it consistent with the the encryption - i.e. use the > > same type of key ? > > We can certainly use P-256 for that as well; that's what is proposed. > However, it would need to be a different key pair, since all the > experts recommend against using the same key for signing and key > exchange. (There isn't an actual attack, but the dual use isn't > provably safe.) > I know it's recommended, but it would be very convenient for device2device to be able to use the public key generated by subscribe. In any case, the UA will need to provide some special API to send() or just an API to sign or generate JWT token - it could generate a second key for authentication. > > On 7 January 2016 at 12:43, Costin Manolache wrote: > > Yes, they would also verify contact info - I have a feeling we're trying > to > > avoid relying too much on > > the contact info ( i.e. domain name of the app server ). If the contact > info > > is voluntary - I don't think we need > > to make it too complex by adding verification. > > I very much agree with this sentiment. That contact information can > be verified, though I think that we should probably start out by > relying on manual processes for that. We can layer other mechanisms > on top. > > I'm not particularly fond of the idea of using something as > heavyweight as what Ben suggested. Something much simpler might work, > but I don't think that we need that. An absolute requirement to use > something that that would be a big problem. > Agreed, and while his suggestion would work for checking the contact info, it will still not be enough for possible charging providers, or for providers offering dashboards or other tools. Better to keep verification and association of the public key with a 'real' account as out of scope of this draft. Costin > > On 7 January 2016 at 13:11, Benjamin Bangert wrote: > > Right, that this is not strongly authenticated means we can't do > something > > like build a developer dashboard that might expose notification traffic > > information associated with the JWT. ie, if a Push Service wanted to > provide > > developers with a diagnostic dashboard similar to what GCM Diagnostics > > provides GCM users. > > If this is your concern, why not ask the dashboard user to prove that > they have access to the JWK private key when logging in? That's > relatively easy to do. You don't actually need to know who they are > in that case. (Though you could use the dashboard UI to do things > like email verification, as many sites do.) > --047d7bd768e870858c0528b7f248 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 6, 2016 at 7:29 PM, Martin Thomson <martin.thomson@= gmail.com> wrote:
Mega-mul= ti-response.

On 7 January 2016 at 05:01, Costin Manolache <costin@gmail.com> wrote:
> At the same time you can't force push service providers to accept<= br> >=C2=A0 unauthenticated/unauthorized sending either. Or require them to<= br> > provide unlimited (and free) service to everyone regardless of how muc= h
> they're abusing/hurting users or networks.

The authorization question is challenging, particularly when it come= s
to abuse of limited resources (user attention, battery power, push
service capacity).=C2=A0 It would be good to understand what the invariants=
are on each service.

If Google are unwilling to allow completely unauthenticated requests,
then I think that we could insist on something voluntary.=C2=A0 I'm
reluctant to do that because it makes it more difficult for
application server developers to get a start, but that can be mitigate
with good tooling, I guess.

On the other hand, if there are cases where a small number of requests
can be made without extra authentication, then the proposed option
would be ideal.=C2=A0 That would allow people to experiment a little before=
having to tool up.

Completely unauthent= icated requests would be an extremely hard sell, and=C2=A0
I susp= ect other push services will be in the same position (at least after some= =C2=A0
time).=C2=A0
=C2=A0
Also I don'= ;t think developers would benefit much - generating a signed
JWT = token is much simpler than encryption, and it already has plenty of librari= es.

And it won't benefit them too much to star= t an app without authentication, than
get random rejections or er= rors - or worse, launch it and than realizing it doesn't work.
We had a period of 'free quota/contact us if you need more' - it = was not fun.



> How about 2.1 AND 2.3 ? Push servers should support both, clients
> should use what they can.

I'd like to avoid that situation because it hurts a lot more all=
around.=C2=A0 We like to save that option for the really tough problems
(video codecs, for example).

I think th= e fact TLS client auth doesn't work on some providers is enough to kill= it=C2=A0
at least for this version, I didn't know it's n= ot supported.

That leaves 2.3 only.
=C2= =A0

> And it may be the way to allow the choice on app server side - either = by
> having an 'isAuthorizationRequired()' or an error code when at= tempting to
> subscribe without a public key.

Again, that makes it more difficult to use the API, and I'd be v= ery
reluctant to take that option unless the alternatives are untenable.

I agree - IMHO just passing the sender key fo= r all providers is cleanest and least=C2=A0
risky option.=C2=A0

=C2=A0

On 7 January 2016 at 06:29, Costin Manolache <costin@gmail.com> wrote:
> That leaves 2.3 only ? I think it's ok - it relies on the same thi= ng as TLS
> client auth, the sender
> signing with the private key, and push service checking it against the=
> public key provided at subscribe time.
> Can we at least make it consistent with the the encryption - i.e. use = the
> same type of key ?

We can certainly use P-256 for that as well; that's what is prop= osed.
However, it would need to be a different key pair, since all the
experts recommend against using the same key for signing and key
exchange.=C2=A0 (There isn't an actual attack, but the dual use isn'= ;t
provably safe.)

I know it's recomme= nded, but it would be very convenient for device2device
=C2=A0to = be able to use the public key generated by subscribe.=C2=A0

<= /div>
In any case, the UA will need to provide some special API to send= () or just an API to=C2=A0
sign or generate JWT token - it could = generate a second key for authentication.=C2=A0

= =C2=A0

On 7 January 2016 at 12:43, Costin Manolache <costin@gmail.com> wrote:
> Yes, they would also verify contact info - I have a feeling we're = trying to
> avoid relying too much on
> the contact info ( i.e. domain name of the app server ). If the contac= t info
> is voluntary - I don't think we need
> to make it too complex by adding verification.

I very much agree with this sentiment.=C2=A0 That contact informatio= n can
be verified, though I think that we should probably start out by
relying on manual processes for that.=C2=A0 We can layer other mechanisms on top.

I'm not particularly fond of the idea of using something as
heavyweight as what Ben suggested.=C2=A0 Something much simpler might work,=
but I don't think that we need that.=C2=A0 An absolute requirement to u= se
something that that would be a big problem.

=
Agreed, and while his suggestion would work for checking the contact i= nfo, it will still=C2=A0
not be enough for possible charging prov= iders, or for providers offering dashboards or
other tools. Bette= r to keep verification and association of the public key with a=C2=A0
=
'real' account as out of scope of this draft.

Costin
=C2=A0

On 7 January 2016 at 13:11, Benjamin Bangert <bbangert@mozilla.com> wrote:
> Right, that this is not strongly authenticated means we can't do s= omething
> like build a developer dashboard that might expose notification traffi= c
> information associated with the JWT. ie, if a Push Service wanted to p= rovide
> developers with a diagnostic dashboard similar to what GCM Diagnostics=
> provides GCM users.

If this is your concern, why not ask the dashboard user to prove tha= t
they have access to the JWK private key when logging in?=C2=A0 That's relatively easy to do.=C2=A0 You don't actually need to know who they a= re
in that case.=C2=A0 (Though you could use the dashboard UI to do things
like email verification, as many sites do.)



--047d7bd768e870858c0528b7f248-- From nobody Wed Jan 6 23:53:16 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E578C1A8738 for ; Wed, 6 Jan 2016 23:53:15 -0800 (PST) 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 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 rjieAtCVOsIE for ; Wed, 6 Jan 2016 23:53:14 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 E4CED1A8734 for ; Wed, 6 Jan 2016 23:53:13 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id 1so197338125ion.1 for ; Wed, 06 Jan 2016 23:53:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KQedWKUWIEI7F4gZ5Zn89mHFrj27yty607D1igxwS8I=; b=gqMXJTGtuujDyKCK3lqp2bnnxr1Pq0UiLtrMrxaaV72uQ2NKsx7HY4e8hTShwiGIji 61CGfEkGmx/CYm6IUhRHnuX+M/ax7QUuFpUypAOF6KKRZSJAHiTVMyGvw2DQl/Zxzafo v+9Ej4+YctTmz++Bpt5ja/FzXyfSJ7tIMM8mmE/mL6pOlA2afsBE4DgmXYrTtJn0vN9t efFJk3h6fMSp4mO+ihsjrCa7t48vFdLZyUwGZGEcSLikGuDSI+y9Io+/gLe9nYuZCZCV 5kOwnO2bEswKcfZOwIeiJ6xAOQ1y9NNCiNhjJLkhYjnNDpnrFfMRPyVyMF+9lT8p2Oko lMlA== MIME-Version: 1.0 X-Received: by 10.107.131.40 with SMTP id f40mr86299965iod.190.1452153193437; Wed, 06 Jan 2016 23:53:13 -0800 (PST) Received: by 10.36.149.130 with HTTP; Wed, 6 Jan 2016 23:53:13 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Jan 2016 18:53:13 +1100 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ben Bangert , Costin Manolache , "webpush@ietf.org" Subject: Re: [Webpush] Application server authentication new years edition X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jan 2016 07:53:16 -0000 On 7 January 2016 at 16:43, Costin Manolache wrote: > That leaves 2.3 only. It looks like we're mostly in agreement for something like 2.3. Should I take some time and flesh out the details? Does anyone disagree? From nobody Thu Jan 7 08:59:23 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2531A90D1 for ; Thu, 7 Jan 2016 08:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 xk56CmGPmP4A for ; Thu, 7 Jan 2016 08:59:19 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 CB4FF1A90CC for ; Thu, 7 Jan 2016 08:59:18 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id p186so106962015qke.0 for ; Thu, 07 Jan 2016 08:59:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nwqOGlvUg1paf9uor+86pT+3STefSonFO2VmxOrAuao=; b=rwxX0ruxvyjeJRVwEt1ZixBcF40E9SF46UqS54N0ELlpIxIfAXBGgIif2lylglhqRD lDmVU8+x900ljcXB47p4oZu0FvKQNEWfdpH4Jgap/xvw/Hup2AU/PLlEHEOcz3tSbUlD Db7u2/i3+7vwSSRfUzjAd1iBIsM6rKSts+gB6mXtsJow0qcS6cRbuWJMGbz0CzSNrM8n fwKEC36RjYo5qav9oBLg6Tu8XO/GHDbzMt4mj0hj56383MU/UrAm3sqtK9ytv+Ukebb6 43UPZ/V178+bT+YJQRJi5sYzt0YUWht6MeOutGTX8CyVJ+e3kBgQfwTbySaYfgj9ppFc gcjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nwqOGlvUg1paf9uor+86pT+3STefSonFO2VmxOrAuao=; b=gS/oDIxImHQA57hj28A6Cj92wOPnQv6hZXqd9IZ3hRham5m0PUnkPgTQEIw0r/egnD RmSGmC3XcXNczyaQspzqrTp+wqq+0sfzldCE8PJ2EKh3sIxnr5oRXprrPjDNZIxjFdDB MPaKSbbGDyUQytCj+sBVvZBxuhwRoslC9GqpEQ6gKdbI57Pxtjq2YrR+d569GkUaT81X wQovtesLUvjQsfiwooqaXMsYe0dnQ6cfK6hPNbc5KyTj/GHUaXmC1ZDfExuEKhrFaczR LJmZ8iTr23ENw9UQX01Pb7ASs+OkDUG7apIjW0Afj/4aE7ymCGpMiBo2SzVidCmxEjD9 13BQ== X-Gm-Message-State: ALoCoQmzra6H7XPPIvOMhCSRSkxUqCu8EBF/TZ/Gq1YlYINoxveqGJJ5MeCI8la2yOpXggxl0hwxr7m4WiEO2UvByUBbfodg5DNrCUiaiA/nsUWdG98pjbQ= MIME-Version: 1.0 X-Received: by 10.13.250.196 with SMTP id k187mr90558405ywf.23.1452185957811; Thu, 07 Jan 2016 08:59:17 -0800 (PST) Received: by 10.37.224.9 with HTTP; Thu, 7 Jan 2016 08:59:17 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Jan 2016 08:59:17 -0800 Message-ID: From: Benjamin Bangert To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c05ed502a057d0528c164bc Archived-At: Cc: Costin Manolache , Costin Manolache , "webpush@ietf.org" Subject: Re: [Webpush] Application server authentication new years edition X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jan 2016 16:59:21 -0000 --94eb2c05ed502a057d0528c164bc Content-Type: text/plain; charset=UTF-8 2.3 sounds fine. I'm curious what thoughts there are around charging providers, but that can wait for a separate thread. On Wed, Jan 6, 2016 at 11:53 PM, Martin Thomson wrote: > On 7 January 2016 at 16:43, Costin Manolache wrote: > > That leaves 2.3 only. > > It looks like we're mostly in agreement for something like 2.3. > Should I take some time and flesh out the details? Does anyone > disagree? > --94eb2c05ed502a057d0528c164bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2.3 sounds fine.

I'm curious what th= oughts there are around charging providers, but that can wait for a separat= e thread.

On Wed, Jan 6, 2016 at 11:53 PM, Martin Thomson <martin.thomson@g= mail.com> wrote:
On 7 Jan= uary 2016 at 16:43, Costin Manolache <costin@gmail.com> wrote:
> That leaves 2.3 only.

It looks like we're mostly in agreement for something like 2.3.
Should I take some time and flesh out the details?=C2=A0 Does anyone
disagree?

--94eb2c05ed502a057d0528c164bc-- From nobody Thu Jan 7 10:59:51 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50591A930A for ; Thu, 7 Jan 2016 10:59:50 -0800 (PST) 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 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 PgFXDP-J6l-v for ; Thu, 7 Jan 2016 10:59:49 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003: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 12AE61A92FD for ; Thu, 7 Jan 2016 10:59:49 -0800 (PST) Received: by mail-oi0-x231.google.com with SMTP id y66so319901146oig.0 for ; Thu, 07 Jan 2016 10:59:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gyMy+iOsi9IsBGFt2jcqy0iCoT60HSmQVdSBjlZEbKI=; b=M7YzaGfscurjtqPHVh/fJNKdto0BnIPEGUo0VFgaH1GEKLTlubfuyczLtuRAkn0M8t j/d5QU834WbMSIpBEC2sZmt1jpxERLiNWLhxmUs5s02IrySmFUAB61Ik2ZeUeBAXOeMq LKwYH4PfvvErakUZAWZ2+RadX5P+2RstItADegXCSxrRnTBZLT8VR3ow/sNhpvLLTefg HdishBnyC8ujtwGIueN6mGe73DCMjt5GdEnl2HQ1mOiDx56BFph82ZXkRUXA+hK88Q2j jR5tPPpRrlinLrNB1P4lyrtGDPu6UY0QwgusV4Aw2i+LesaPQmBukM2kX19EvGM8q23y p6dw== MIME-Version: 1.0 X-Received: by 10.202.201.77 with SMTP id z74mr75337587oif.24.1452193188465; Thu, 07 Jan 2016 10:59:48 -0800 (PST) Received: by 10.76.8.74 with HTTP; Thu, 7 Jan 2016 10:59:48 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Jan 2016 10:59:48 -0800 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1134f92024d3b10528c313ac Archived-At: Cc: Ben Bangert , Costin Manolache , "webpush@ietf.org" Subject: Re: [Webpush] Application server authentication new years edition X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jan 2016 18:59:51 -0000 --001a1134f92024d3b10528c313ac Content-Type: text/plain; charset=UTF-8 On Wed, Jan 6, 2016 at 11:53 PM, Martin Thomson wrote: > On 7 January 2016 at 16:43, Costin Manolache wrote: > > That leaves 2.3 only. > > It looks like we're mostly in agreement for something like 2.3. > Should I take some time and flesh out the details? Does anyone > disagree? > Sounds good, but I have few questions/comments on the details. 1. Key identifiers ('kid') - for normal JWT, the key is known from the issuer or 'sub'. Since in our case we'll have self-generated keys, and we want to avoid having each key registered with all providers - all that a push service will know when seeing a JWT token the first time will be the content of the token. So we need a way to find the public key needed to verify the content - and the only one I know is to use something like the SHA of the public key. On subscribe - the provider can store the public key, with the kid as lookup key, than on send it can verify. For example kid == (SHA1 or SHA256 truncated to 64bits) would work. 2. 'aud' field - not sure what would be the right value, maybe the domain of the push provider ? 3. Going back to the 'voluntary'/optional part: I'm not sure if encryption is going to be required or optional in the final version ? 4. I think we can have the sender key optional in the subscribe operation, in particular for cases like low end IOT - not including it would give permission to anyone with the URL and pubkey of the device to send messages. There is another case where it helps - pairing, in cases of D2D - but with restrictions ( either time, or binding the subscription to the sender at first use ). In other words: I'm not opposed to having 'optional' on the subscribe (and on contact info). 5. This may be a bit controversial :-), if we require the developers to use a JOSE library to generate JWT tokens, signed with a ES256 - wouldn't make sense to also allow them to use the same library to encrypt the payload for the e2e ? There is already a content type defined, so easy to differentiate. Costin --001a1134f92024d3b10528c313ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 6, 2016 at 11:53 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 7 Jan= uary 2016 at 16:43, Costin Manolache <costin@gmail.com> wrote:
> That leaves 2.3 only.

It looks like we're mostly in agreement for something like 2.3.
Should I take some time and flesh out the details?=C2=A0 Does anyone
disagree?

Sounds good, but I have few q= uestions/comments on the details.

1. Key identifie= rs ('kid') - for normal JWT, the key is known from the issuer or=C2= =A0
'sub'. Since in our case we'll have self-generate= d keys, and we want to avoid=C2=A0
having each key registered wit= h all providers - all that a push service will know
when seeing a= JWT token the first time will be the content of the token.=C2=A0
So we need a way to find the public key needed to verify the content - and= =C2=A0
the only one I know is to use something like the SHA of th= e public key.=C2=A0
On subscribe - the provider can store the pub= lic key, with the kid as lookup key, than
on send it can verify. = For example kid =3D=3D (SHA1 or SHA256 truncated to 64bits) would work.

2. 'aud' field - not sure what would be the r= ight value, maybe the domain of the push provider ?=C2=A0

3. Going back to the 'voluntary'/optional part: I'm not= sure if encryption is going to be required or
optional in the fi= nal version ?=C2=A0

4. I think we can have the sen= der key optional in the subscribe operation, in particular for cases
<= div>like low end IOT - not including it would give permission to anyone wit= h the URL and pubkey=C2=A0
of the device to send messages. There = is another case where it helps - pairing, in cases of D2D -=C2=A0
but with restrictions ( either time, or binding the subscription to the se= nder at first use ).
In other words: I'm not opposed to havin= g 'optional' on the subscribe (and on contact info).

=
5. This may be a bit controversial :-), if we require the develo= pers to use a JOSE library to=C2=A0
generate JWT tokens, signed w= ith a ES256 - wouldn't make sense to also allow them to use=C2=A0
=
the same library to encrypt the payload for the e2e ? There is already= a content type defined, so easy to
differentiate.=C2=A0


Costin


<= div>

=C2=A0

--001a1134f92024d3b10528c313ac-- From nobody Thu Jan 7 12:56:16 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C661A0016 for ; Thu, 7 Jan 2016 12:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 E-doyeGyrhij for ; Thu, 7 Jan 2016 12:56:12 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::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 AB6431A00BE for ; Thu, 7 Jan 2016 12:56:12 -0800 (PST) Received: by mail-yk0-x232.google.com with SMTP id k129so320269632yke.0 for ; Thu, 07 Jan 2016 12:56:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c+unUPKATTA0bDXEk+DSk/trJGOgUJOEr82EXP07Ju4=; b=NUfKl7DWsgHOgzq5a8unWM7y8NPdQPYdrovxj5l/wvDN+61WKP+mTxMq/ajZwdZT4k vxJkkYBGjPTu1Q31SVtxl1cTHiG8kKFNjRPD9uonvnfen75O/9v8a3QWXHk5QkvALWgR YtYAmDXEWdUP76kdVt4GAU223pVb4cEQ5kg1ZDN7UehZ+xEsxfDHHQo5HOCgmsST2Cjz f5C0WV+XibpvtgGPNCC1VqQMadjYeA/QSexcXJBkqmaGv3PJwWGo6YHJJgieLbbzk0Ne MDD813pOwToUtWRM1PZq8i4A6bcwGDkbozcZqyJUmVw+ly9PhbS1FYf+vT7l+yo/DhMI uWKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=c+unUPKATTA0bDXEk+DSk/trJGOgUJOEr82EXP07Ju4=; b=UlsLlOMDmma3XnrQkPqzkEqHau2tJAEwNlD20HUwIUozlrrKMI8ZRRXPG/ztEhNueJ 6ATyCtmXlwo7N6qIPpeHivNWzKUknntq5V907gYI2TwNTE1Qt2eTEenHavPB9yyEWi5v nikxPC43G+KA/NuGugQa23yjWbqXzqA/SC/xxGeBcyg3IZOh1oax7Ew0BaW6G6RNmRYo /AewA7W9cC69Dkfybe1/LAr6k0eoWEnfu2UzhZajis5eZFMJo9mGbCpBGm7zuG3sKpZJ bJysYFjpDAE0ezy11r8BmLNnN8hkGDkpilTLtGyd1dnmlbGxslbSYhBxr6ZEVchyARqJ 3CZg== X-Gm-Message-State: ALoCoQnlMtB/rCka8thq/DIsxgqCcKKSP63r0lXA4ijbvI9nBKIuf5LeIncrMttQOAy+EX3dWjHApcqU8bp24lJE6iyANLnsDBWq/plnAKVgf3x4a7v0t3g= MIME-Version: 1.0 X-Received: by 10.13.218.129 with SMTP id c123mr86946863ywe.4.1452200171831; Thu, 07 Jan 2016 12:56:11 -0800 (PST) Received: by 10.37.224.9 with HTTP; Thu, 7 Jan 2016 12:56:11 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Jan 2016 12:56:11 -0800 Message-ID: From: Benjamin Bangert To: Costin Manolache Content-Type: multipart/alternative; boundary=94eb2c08090c62c03c0528c4b354 Archived-At: Cc: Costin Manolache , Martin Thomson , "webpush@ietf.org" Subject: Re: [Webpush] Application server authentication new years edition X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jan 2016 20:56:16 -0000 --94eb2c08090c62c03c0528c4b354 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 7, 2016 at 10:59 AM, Costin Manolache wrote: > > > On Wed, Jan 6, 2016 at 11:53 PM, Martin Thomson > wrote: > >> On 7 January 2016 at 16:43, Costin Manolache wrote: >> > That leaves 2.3 only. >> >> It looks like we're mostly in agreement for something like 2.3. >> Should I take some time and flesh out the details? Does anyone >> disagree? >> > > Sounds good, but I have few questions/comments on the details. > > 1. Key identifiers ('kid') - for normal JWT, the key is known from the > issuer or > 'sub'. Since in our case we'll have self-generated keys, and we want to > avoid > having each key registered with all providers - all that a push service > will know > when seeing a JWT token the first time will be the content of the token. > So we need a way to find the public key needed to verify the content - and > the only one I know is to use something like the SHA of the public key. > On subscribe - the provider can store the public key, with the kid as > lookup key, than > on send it can verify. For example kid == (SHA1 or SHA256 truncated to > 64bits) would work. > If an app-server has a private key leak and needs all its users to rotate sender keys, that will also tie up a substantial amount of server resources having such a large unsubscribe/subscribe cycle. Key rotation for private keys is common in many cases already, it'd be nice if such a thing wasn't expensive for the server. > 2. 'aud' field - not sure what would be the right value, maybe the domain > of the push provider ? > I know it doesn't seem popular to include stronger authentication at this layer.... but if 'aud' was the domain (or sub-domain for per-push-provider public keys), and there was a DNS TXT record that contained the JWT public key then the push service would have a way to lookup the key. It'd also allow the app-server to rotate keys used without all the push clients needing to resubscribe. This would bump the authentication to domain verified, while remedying the issue of how to get the public key to the push service and reducing server resources needed to handle sender key rotation. > 3. Going back to the 'voluntary'/optional part: I'm not sure if encryption > is going to be required or > optional in the final version ? > > 4. I think we can have the sender key optional in the subscribe operation, > in particular for cases > like low end IOT - not including it would give permission to anyone with > the URL and pubkey > of the device to send messages. There is another case where it helps - > pairing, in cases of D2D - > but with restrictions ( either time, or binding the subscription to the > sender at first use ). > In other words: I'm not opposed to having 'optional' on the subscribe (and > on contact info). > > 5. This may be a bit controversial :-), if we require the developers to > use a JOSE library to > generate JWT tokens, signed with a ES256 - wouldn't make sense to also > allow them to use > the same library to encrypt the payload for the e2e ? There is already a > content type defined, so easy to > differentiate. > +1 on simplifying this for developers. Cheers, Ben --94eb2c08090c62c03c0528c4b354 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 7, 2016 at 10:59 AM, Costin Manolache <costin@gmail.com> wrote:


On = Wed, Jan 6, 2016 at 11:53 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 7 January 2= 016 at 16:43, Costin Manolache <costin@gmail.com> wrote:
> That leaves 2.3 only.

It looks like we're mostly in agreement for something like 2.3.
Should I take some time and flesh out the details?=C2=A0 Does anyone
disagree?

Sounds good, but = I have few questions/comments on the details.

1. K= ey identifiers ('kid') - for normal JWT, the key is known from the = issuer or=C2=A0
'sub'. Since in our case we'll have s= elf-generated keys, and we want to avoid=C2=A0
having each key re= gistered with all providers - all that a push service will know
w= hen seeing a JWT token the first time will be the content of the token.=C2= =A0
So we need a way to find the public key needed to verify the = content - and=C2=A0
the only one I know is to use something like = the SHA of the public key.=C2=A0
On subscribe - the provider can = store the public key, with the kid as lookup key, than
on send it= can verify. For example kid =3D=3D (SHA1 or SHA256 truncated to 64bits) wo= uld work.

If an app= -server has a private key leak and needs all its users to rotate sender key= s, that will also tie up a substantial amount of server resources having su= ch a large unsubscribe/subscribe cycle.

Key rotation for = private keys is common in many cases already, it'd be nice if such a th= ing wasn't expensive for the server.
=C2=A0
2. 'aud' field - not sure wh= at would be the right value, maybe the domain of the push provider ?=C2=A0<= /div>

I know it doesn'= ;t seem popular to include stronger authentication at this layer.... but if= 'aud' was the domain (or sub-domain for per-push-provider public k= eys), and there was a DNS TXT record that contained the JWT public key then= the push service would have a way to lookup the key. It'd also allow t= he app-server to rotate keys used without all the push clients needing to r= esubscribe.

This would bump the authentication to domain = verified, while remedying the issue of how to get the public key to the pus= h service and reducing server resources needed to handle sender key rotatio= n.
=C2=A0
3. = Going back to the 'voluntary'/optional part: I'm not sure if en= cryption is going to be required or
optional in the final version= ?=C2=A0

4. I think we can have the sender key opt= ional in the subscribe operation, in particular for cases
like lo= w end IOT - not including it would give permission to anyone with the URL a= nd pubkey=C2=A0
of the device to send messages. There is another = case where it helps - pairing, in cases of D2D -=C2=A0
but with r= estrictions ( either time, or binding the subscription to the sender at fir= st use ).
In other words: I'm not opposed to having 'opti= onal' on the subscribe (and on contact info).

= 5. This may be a bit controversial :-), if we require the developers to use= a JOSE library to=C2=A0
generate JWT tokens, signed with a ES256= - wouldn't make sense to also allow them to use=C2=A0
the sa= me library to encrypt the payload for the e2e ? There is already a content = type defined, so easy to
differentiate.=C2=A0

+1 on simplifying this for developers.
<= br>
Cheers,
Ben

--94eb2c08090c62c03c0528c4b354-- From nobody Thu Jan 7 13:33:23 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6801A0149 for ; Thu, 7 Jan 2016 13:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 FoJKEZWbYmVy for ; Thu, 7 Jan 2016 13:33:19 -0800 (PST) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::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 C27721A0145 for ; Thu, 7 Jan 2016 13:33:18 -0800 (PST) Received: by mail-ob0-x22e.google.com with SMTP id wp13so202852375obc.1 for ; Thu, 07 Jan 2016 13:33:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xSVi+f9cuRlZ8WuTw5f1jkIZvxNalqCauAd/o8uTiso=; b=OMuyB86jKD4xNXsEUh28Ac2HWlo0Z2j8F8SYYOvMx8St2dD/avCvchc2/kSmquebH4 EKoJzTPwKiqdxLOr9EdMVi5qZFPjBxh+3iczy+b/kuRu25/2EUruwRMG9ZnugFDKnbGx Iq7vaDDFnFb7z/VuxiDwtwJHjQ4YoGDOk26ndqChFf6/GSoM9RZ7a1NBjWnWmn3GAmlZ 20X9nAYBcYk07DP/3OiT5tdNn/VnqV6Gg8urhvalHLR6EblHGnw5qOOw67qkz2i912oo vvNP4TP9zxJx8IovrMY6YO4UumLnG5tT/gQXmMj952Hndsj26SzJnsRRn/PWqMbLEuCy SRHQ== MIME-Version: 1.0 X-Received: by 10.182.19.164 with SMTP id g4mr80115145obe.15.1452202398082; Thu, 07 Jan 2016 13:33:18 -0800 (PST) Received: by 10.76.8.74 with HTTP; Thu, 7 Jan 2016 13:33:17 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Jan 2016 13:33:17 -0800 Message-ID: From: Costin Manolache To: Benjamin Bangert Content-Type: multipart/alternative; boundary=001a11c2a5f61471cd0528c5387c Archived-At: Cc: Costin Manolache , Martin Thomson , "webpush@ietf.org" Subject: Re: [Webpush] Application server authentication new years edition X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jan 2016 21:33:21 -0000 --001a11c2a5f61471cd0528c5387c Content-Type: text/plain; charset=UTF-8 On Thu, Jan 7, 2016 at 12:56 PM, Benjamin Bangert wrote: > On Thu, Jan 7, 2016 at 10:59 AM, Costin Manolache > wrote: > >> >> >> On Wed, Jan 6, 2016 at 11:53 PM, Martin Thomson > > wrote: >> >>> On 7 January 2016 at 16:43, Costin Manolache wrote: >>> > That leaves 2.3 only. >>> >>> It looks like we're mostly in agreement for something like 2.3. >>> Should I take some time and flesh out the details? Does anyone >>> disagree? >>> >> >> Sounds good, but I have few questions/comments on the details. >> >> 1. Key identifiers ('kid') - for normal JWT, the key is known from the >> issuer or >> 'sub'. Since in our case we'll have self-generated keys, and we want to >> avoid >> having each key registered with all providers - all that a push service >> will know >> when seeing a JWT token the first time will be the content of the token. >> So we need a way to find the public key needed to verify the content - >> and >> the only one I know is to use something like the SHA of the public key. >> On subscribe - the provider can store the public key, with the kid as >> lookup key, than >> on send it can verify. For example kid == (SHA1 or SHA256 truncated to >> 64bits) would work. >> > > If an app-server has a private key leak and needs all its users to rotate > sender keys, that will also tie up a substantial amount of server resources > having such a large unsubscribe/subscribe cycle. > > Key rotation for private keys is common in many cases already, it'd be > nice if such a thing wasn't expensive for the server. > > Key rotation can be spread over a long interval - normal subscriptions expire anyways and need to be rotated, so for a periodic rotation it shouldn't add extra load. The push service itself may rotate its keys (assuming that the URLs are generated using keys) - which will also likely be staged with the periodic expiration of subscriptions. If only the private key is leaked - I assume it's a tradeoff, users are still protected by the secrecy of the URL/secret-public key. For 'my private key AND the database of subscription have been stolen' - I don't think there are many options except taking the extra load hit (for the general case). Some providers may allow additional options - in particular if the public key is linked to some developer account (for tools or other purposes). ( we discussed in the past the case of 'private keys of the push service leaking', and at least the js API has support for handling it ) > 2. 'aud' field - not sure what would be the right value, maybe the domain >> of the push provider ? >> > > I know it doesn't seem popular to include stronger authentication at this > layer.... but if 'aud' was the domain (or sub-domain for per-push-provider > public keys), and there was a DNS TXT record that contained the JWT public > key then the push service would have a way to lookup the key. It'd also > allow the app-server to rotate keys used without all the push clients > needing to resubscribe. > > This would bump the authentication to domain verified, while remedying the > issue of how to get the public key to the push service and reducing server > resources needed to handle sender key rotation. > Audience is one of the most confusing concepts :-). My understanding is that it means 'identifies who will process/consume the JWT token', in our case the push service provider. The draft defines it as 'full push resource URL', meaning developer needs to generate a new token for each message. I think using just the domain name is more efficient ( less overhead on client, possible caching on server ) - and it's what Oauth2 is doing as well. Using DNS TXT records or any other mechanism for verifying the 'contact info' - i.e. the domain of the sender is tricky, and on top there is strong opposition to even include contact info in requests. I suggest leaving this for a separate discussion/standard. But I agree, if a 'contact info' is provided, it would be good to use DNS TXT records or even a "well known" URL to fetch the current public key. > > >> 3. Going back to the 'voluntary'/optional part: I'm not sure if >> encryption is going to be required or >> optional in the final version ? >> >> 4. I think we can have the sender key optional in the subscribe >> operation, in particular for cases >> like low end IOT - not including it would give permission to anyone with >> the URL and pubkey >> of the device to send messages. There is another case where it helps - >> pairing, in cases of D2D - >> but with restrictions ( either time, or binding the subscription to the >> sender at first use ). >> In other words: I'm not opposed to having 'optional' on the subscribe >> (and on contact info). >> >> 5. This may be a bit controversial :-), if we require the developers to >> use a JOSE library to >> generate JWT tokens, signed with a ES256 - wouldn't make sense to also >> allow them to use >> the same library to encrypt the payload for the e2e ? There is already a >> content type defined, so easy to >> differentiate. >> > > +1 on simplifying this for developers. > > Cheers, > Ben > > --001a11c2a5f61471cd0528c5387c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 7, 2016 at 12:56 PM, Benjamin Bangert <= ;bbangert@mozilla= .com> wrote:
On Thu, Jan 7,= 2016 at 10:59 AM, Costin Manolache <costin@gmail.com> wrote:=


On Wed, Jan 6, 2016 at 11:53 PM, Martin = Thomson <martin.thomson@gmail.com> wrote:
On 7 January 2016 at 16:43, Costin Manolache <costin@gmail.com> wrote:
> That leaves 2.3 only.

It looks like we're mostly in agreement for something like 2.3.
Should I take some time and flesh out the details?=C2=A0 Does anyone
disagree?

Sounds good, but = I have few questions/comments on the details.

1. K= ey identifiers ('kid') - for normal JWT, the key is known from the = issuer or=C2=A0
'sub'. Since in our case we'll have s= elf-generated keys, and we want to avoid=C2=A0
having each key re= gistered with all providers - all that a push service will know
w= hen seeing a JWT token the first time will be the content of the token.=C2= =A0
So we need a way to find the public key needed to verify the = content - and=C2=A0
the only one I know is to use something like = the SHA of the public key.=C2=A0
On subscribe - the provider can = store the public key, with the kid as lookup key, than
on send it= can verify. For example kid =3D=3D (SHA1 or SHA256 truncated to 64bits) wo= uld work.

If= an app-server has a private key leak and needs all its users to rotate sen= der keys, that will also tie up a substantial amount of server resources ha= ving such a large unsubscribe/subscribe cycle.

Key rotati= on for private keys is common in many cases already, it'd be nice if su= ch a thing wasn't expensive for the server.
<= div>=C2=A0

Key rotation can be spread over a long interval - normal subscripti= ons expire anyways and need to be rotated,
=C2=A0so for a periodi= c rotation it shouldn't add extra load. The push service itself may rot= ate its keys (assuming that
the URLs are generated using keys) - = which will also likely be staged with the periodic expiration of subscripti= ons.

If only the private key is leaked - I assume = it's a tradeoff, users are still protected by=C2=A0
the secre= cy of the URL/secret-public key.

For 'my priva= te key AND the database of subscription have been stolen' - I don't= think there=C2=A0
are many options except taking the extra l= oad hit (for the general case). Some providers may
allow ad= ditional options - in particular if the public key is linked to some develo= per account
(for tools or other purposes).=C2=A0

( we discussed in the past the case of 'private keys of the pu= sh service leaking', and at least the js API=C2=A0
has suppor= t for handling it )
=C2=A0
2. 'aud' field - not sure what= would be the right value, maybe the domain of the push provider ?=C2=A0

I know it does= n't seem popular to include stronger authentication at this layer.... b= ut if 'aud' was the domain (or sub-domain for per-push-provider pub= lic keys), and there was a DNS TXT record that contained the JWT public key= then the push service would have a way to lookup the key. It'd also al= low the app-server to rotate keys used without all the push clients needing= to resubscribe.

This would bump the authentication to do= main verified, while remedying the issue of how to get the public key to th= e push service and reducing server resources needed to handle sender key ro= tation.

Audience is one of the most confusing concepts = :-). My understanding is that it means 'identifies who will=C2=A0
=
process/consume the JWT token', in our case the push service provi= der. The draft defines it as 'full push resource URL',=C2=A0
<= div>meaning developer needs to generate a new token for each message. I thi= nk using just the domain name
is more efficient ( less overhead o= n client, possible caching on server ) - and it's what Oauth2 is doing = as well.


Using DNS TXT records or a= ny other mechanism for verifying the 'contact info' - i.e. the doma= in of the=C2=A0
sender is tricky, and on top there is strong oppo= sition to even include contact info in requests.=C2=A0
I suggest = leaving this for a separate discussion/standard. But I agree, if a 'con= tact info' is provided, it
would be good to use DNS TXT recor= ds or even a "well known" URL to fetch the current public key.

=C2=A0
=C2= =A0
3. Going back to the 'voluntary&#= 39;/optional part: I'm not sure if encryption is going to be required o= r
optional in the final version ?=C2=A0

= 4. I think we can have the sender key optional in the subscribe operation, = in particular for cases
like low end IOT - not including it would= give permission to anyone with the URL and pubkey=C2=A0
of the d= evice to send messages. There is another case where it helps - pairing, in = cases of D2D -=C2=A0
but with restrictions ( either time, or bind= ing the subscription to the sender at first use ).
In other words= : I'm not opposed to having 'optional' on the subscribe (and on= contact info).

5. This may be a bit controversial= :-), if we require the developers to use a JOSE library to=C2=A0
generate JWT tokens, signed with a ES256 - wouldn't make sense to also= allow them to use=C2=A0
the same library to encrypt the payload = for the e2e ? There is already a content type defined, so easy to
differentiate.=C2=A0

+1 on simplifying this for developers.

Cheers,
Ben


--001a11c2a5f61471cd0528c5387c-- From nobody Thu Jan 7 13:57:11 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62001A01A3 for ; Thu, 7 Jan 2016 13:57:09 -0800 (PST) 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 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 zSBVA6uRxCld for ; Thu, 7 Jan 2016 13:57:08 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 24D061A01A2 for ; Thu, 7 Jan 2016 13:57:08 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id g73so69713796ioe.3 for ; Thu, 07 Jan 2016 13:57:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/4ULt0dQcubTG2WuHUnc2yasyOnQbg6NxEW0XwpSv8Q=; b=q8HPWJtjoySGpWXH5T4FnXo0q3bkHRfDkfSe0tgT2h0b3i2Bmj1YiwKlc9sU468mYF +2bdCwZNuUYf9U0xWac8aMYAl2t8N/sOTeLJX1j5nP0gzdCmrrcKgdpjOgpAW6WeO91V x0nhyDpXVdIKsKJ11hbjQsoxqRjukT8yvpFjOnxZEk4KwXqpr3HMMT5LHUi+cXynvFit R8xB8MpXh4hhN7XRUEMxvXn3mQ600GAXNlQSg8aeXi3hqWbrVBF9h5eOngELwYih9lqB 3fkwszItBiA4+lzIhzgQnwaUDF20v5OA1qWW2rcCK6ziASTgqIpH1FoGDLlVnENqlSLj 9bDw== MIME-Version: 1.0 X-Received: by 10.107.131.40 with SMTP id f40mr90651008iod.190.1452203827429; Thu, 07 Jan 2016 13:57:07 -0800 (PST) Received: by 10.36.149.130 with HTTP; Thu, 7 Jan 2016 13:57:07 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Jan 2016 08:57:07 +1100 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ben Bangert , Costin Manolache , "webpush@ietf.org" Subject: Re: [Webpush] Application server authentication new years edition X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jan 2016 21:57:10 -0000 On 8 January 2016 at 05:59, Costin Manolache wrote: > 1. Key identifiers ('kid') - for normal JWT, the key is known from the > issuer or > 'sub'. Since in our case we'll have self-generated keys, and we want to > avoid > having each key registered with all providers - all that a push service will > know > when seeing a JWT token the first time will be the content of the token. > So we need a way to find the public key needed to verify the content - and > the only one I know is to use something like the SHA of the public key. > On subscribe - the provider can store the public key, with the kid as lookup > key, than > on send it can verify. For example kid == (SHA1 or SHA256 truncated to > 64bits) would work. The push service is going to need the public key, so that means including a JWK in the message, I think. Knowing a hash of the public key isn't enough. I think that we can avoid using key identifiers. We could include one and use that to reference another header field, but it is easier to say that there is exactly one JWT and exactly one JWK and that one depends on the other. > 2. 'aud' field - not sure what would be the right value, maybe the domain of > the push provider ? I specified URL at the suggestion of Chris, but I had the same thought you did. Maybe we can trim it to origin. That reduces portability considerably and also shortens the token somewhat. > 3. Going back to the 'voluntary'/optional part: I'm not sure if encryption > is going to be required or > optional in the final version ? The protocol won't absolutely require it, though it will strongly recommend it. (I'd prefer to require it, but there you have it.) The W3C API will require encryption. Does that make sense? > 4. I think we can have the sender key optional in the subscribe operation, > in particular for cases > like low end IOT - not including it would give permission to anyone with the > URL and pubkey > of the device to send messages. There is another case where it helps - > pairing, in cases of D2D - > but with restrictions ( either time, or binding the subscription to the > sender at first use ). > In other words: I'm not opposed to having 'optional' on the subscribe (and > on contact info). I agree. Making the JWT mandatory on the subscription would introduce some operational problems for the cases where one endpoint has to be used by several different application servers too. > 5. This may be a bit controversial :-), if we require the developers to use > a JOSE library to > generate JWT tokens, signed with a ES256 - wouldn't make sense to also allow > them to use > the same library to encrypt the payload for the e2e ? There is already a > content type defined, so easy to > differentiate. I don't know of any way to do that without also massively inflating the size of the payload. There is a mapping to JWE already in the encryption draft for those who would prefer to reuse their library. The tricky part is key derivation, but I think that's largely unavoidable in this case. From nobody Fri Jan 8 00:07:00 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886A21ACE98 for ; Fri, 8 Jan 2016 00:06:59 -0800 (PST) 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 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 Zctd6Nl4X7UD for ; Fri, 8 Jan 2016 00:06:57 -0800 (PST) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::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 27DD91ACE97 for ; Fri, 8 Jan 2016 00:06:57 -0800 (PST) Received: by mail-ob0-x233.google.com with SMTP id bx1so321140282obb.0 for ; Fri, 08 Jan 2016 00:06:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xNx0UMrXUDz9/zdCNTPbAETgGtWv86ay0nHoFqSJfKU=; b=Vw8A64DKNFDNtXpAPCQ1fH3tkK5GRIdJQlnY350Y7mbz21pBSulkISXNo8ZXSuqbur 5Y+sGg+YrinE1f4Ghhs5u5YOXpweeyvur1uJ/bWLUKdCoROrlAHbxYnMHoiNwrNT372E Pscjnr8YWuWxXBkYWhDhF38+Cv3vh9hY2h15+shB+r34wTHuIBD79mH/OREKflacEsj/ prmpEnq8y8gSsZ4RZcoSlSLoRzDHx4fhrr+m+CFZ1Pe+rn2YrZrmf3zqNt0PlYMzKUAE dWRQv9TnAuZQc8DNXAW/a1iEr2du4D3kPbayvHY+GXjl5eNpbJsBxtPXgBKWNOOLry8F ohtg== MIME-Version: 1.0 X-Received: by 10.60.135.98 with SMTP id pr2mr71323742oeb.65.1452240416521; Fri, 08 Jan 2016 00:06:56 -0800 (PST) Received: by 10.76.8.74 with HTTP; Fri, 8 Jan 2016 00:06:56 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Jan 2016 00:06:56 -0800 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b41792127c6a00528ce1288 Archived-At: Cc: Ben Bangert , Costin Manolache , "webpush@ietf.org" Subject: Re: [Webpush] Application server authentication new years edition X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jan 2016 08:06:59 -0000 --047d7b41792127c6a00528ce1288 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 7, 2016 at 1:57 PM, Martin Thomson wrote: > On 8 January 2016 at 05:59, Costin Manolache wrote: > > 1. Key identifiers ('kid') - for normal JWT, the key is known from the > > issuer or > > 'sub'. Since in our case we'll have self-generated keys, and we want to > > avoid > > having each key registered with all providers - all that a push service > will > > know > > when seeing a JWT token the first time will be the content of the token. > > So we need a way to find the public key needed to verify the content - > and > > the only one I know is to use something like the SHA of the public key. > > On subscribe - the provider can store the public key, with the kid as > lookup > > key, than > > on send it can verify. For example kid == (SHA1 or SHA256 truncated to > > 64bits) would work. > > The push service is going to need the public key, so that means > including a JWK in the message, I think. Knowing a hash of the public > key isn't enough. > The push service can store the key when subscribe() is called. I think we can make it work without a key ID - the send URL will decode to the registration, which would include the authorized public key. But I think it would still be a bit cleaner and simpler if the JWT key could be verified without having to use the URL. > > I think that we can avoid using key identifiers. We could include one > and use that to reference another header field, but it is easier to > say that there is exactly one JWT and exactly one JWK and that one > depends on the other. > That would work too, but the push service still need to verify that the key in subscribe is the same as the key in JWT. If you load the subscription - using either the URL or the key id - there is no need to send the JWK. > > 2. 'aud' field - not sure what would be the right value, maybe the > domain of > > the push provider ? > > I specified URL at the suggestion of Chris, but I had the same thought > you did. Maybe we can trim it to origin. That reduces portability > considerably and also shortens the token somewhat. > > > 3. Going back to the 'voluntary'/optional part: I'm not sure if > encryption > > is going to be required or > > optional in the final version ? > > The protocol won't absolutely require it, though it will strongly > recommend it. (I'd prefer to require it, but there you have it.) The > W3C API will require encryption. Does that make sense? > Yes. > > 4. I think we can have the sender key optional in the subscribe > operation, > > in particular for cases > > like low end IOT - not including it would give permission to anyone with > the > > URL and pubkey > > of the device to send messages. There is another case where it helps - > > pairing, in cases of D2D - > > but with restrictions ( either time, or binding the subscription to the > > sender at first use ). > > In other words: I'm not opposed to having 'optional' on the subscribe > (and > > on contact info). > > I agree. Making the JWT mandatory on the subscription would introduce > some operational problems for the cases where one endpoint has to be > used by several different application servers too. > > It shouldn't be mandatory - just recommended that subscribe indicates who is authorized to send. A push service that doesn't require authentication can just ignore it. > > 5. This may be a bit controversial :-), if we require the developers to > use > > a JOSE library to > > generate JWT tokens, signed with a ES256 - wouldn't make sense to also > allow > > them to use > > the same library to encrypt the payload for the e2e ? There is already a > > content type defined, so easy to > > differentiate. > > I don't know of any way to do that without also massively inflating > the size of the payload. There is a mapping to JWE already in the > encryption draft for those who would prefer to reuse their library. > The tricky part is key derivation, but I think that's largely > unavoidable in this case. > Yes, it doesn't seem possible to convert from JWE to the binary format, so UAs would need to support both, I don't think this would work. And it may be more confusing in the end. Costin --047d7b41792127c6a00528ce1288 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 7, 2016 at 1:57 PM, Martin Thomson <martin.thomson@= gmail.com> wrote:
On 8 January 2016 at 05:59, Costin Manolache <costin@gmail.com> wrote:
> 1. Key identifiers ('kid') - for normal JWT, the key is known = from the
> issuer or
> 'sub'. Since in our case we'll have self-generated keys, a= nd we want to
> avoid
> having each key registered with all providers - all that a push servic= e will
> know
> when seeing a JWT token the first time will be the content of the toke= n.
> So we need a way to find the public key needed to verify the content -= and
> the only one I know is to use something like the SHA of the public key= .
> On subscribe - the provider can store the public key, with the kid as = lookup
> key, than
> on send it can verify. For example kid =3D=3D (SHA1 or SHA256 truncate= d to
> 64bits) would work.

The push service is going to need the public key, so that means
including a JWK in the message, I think.=C2=A0 Knowing a hash of the public=
key isn't enough.

The push service = can store the key when subscribe() is called.

I th= ink we can make it work without a key ID - the send URL will decode
to the registration, which would include the authorized public key. But= =C2=A0
I think it would still be a bit cleaner and simpler if the= JWT key could be verified
without having to use the URL.

=C2=A0

I think that we can avoid using key identifiers.=C2=A0 We could include one=
and use that to reference another header field, but it is easier to
say that there is exactly one JWT and exactly one JWK and that one
depends on the other.

That would work t= oo, but the push service still need to verify that the=C2=A0
key = in subscribe is the same as the key in JWT. If you load the subscription -= =C2=A0
using either the URL or the key id - there is no need to s= end the JWK.
=C2=A0


> 2. 'aud' field - not sure what would be the right value, maybe= the domain of
> the push provider ?

I specified URL at the suggestion of Chris, but I had the same thoug= ht
you did.=C2=A0 Maybe we can trim it to origin.=C2=A0 That reduces portabili= ty
considerably and also shortens the token somewhat.

> 3. Going back to the 'voluntary'/optional part: I'm not su= re if encryption
> is going to be required or
> optional in the final version ?

The protocol won't absolutely require it, though it will strongl= y
recommend it.=C2=A0 (I'd prefer to require it, but there you have it.)= =C2=A0 The
W3C API will require encryption.=C2=A0 Does that make sense?

Yes.=C2=A0


> 4. I think we can have the sender key optional in the subscribe operat= ion,
> in particular for cases
> like low end IOT - not including it would give permission to anyone wi= th the
> URL and pubkey
> of the device to send messages. There is another case where it helps -=
> pairing, in cases of D2D -
> but with restrictions ( either time, or binding the subscription to th= e
> sender at first use ).
> In other words: I'm not opposed to having 'optional' on th= e subscribe (and
> on contact info).

I agree.=C2=A0 Making the JWT mandatory on the subscription would in= troduce
some operational problems for the cases where one endpoint has to be
used by several different application servers too.


It shouldn'= ;t be mandatory - just recommended that subscribe indicates who is authoriz= ed
to send.=C2=A0

A push service that do= esn't require authentication can just ignore it.=C2=A0
=C2=A0= =C2=A0
=C2=A0
> 5. This may be a bit controversial :-), if we require the developers t= o use
> a JOSE library to
> generate JWT tokens, signed with a ES256 - wouldn't make sense to = also allow
> them to use
> the same library to encrypt the payload for the e2e ? There is already= a
> content type defined, so easy to
> differentiate.

I don't know of any way to do that without also massively inflat= ing
the size of the payload.=C2=A0 There is a mapping to JWE already in the
encryption draft for those who would prefer to reuse their library.
The tricky part is key derivation, but I think that's largely
unavoidable in this case.

Yes, it doesn't seem possible t= o convert from JWE to the binary format,
so UAs would need to support b= oth, I don't think this would work. And it may be=C2=A0
more = confusing in the end.

Costin

--047d7b41792127c6a00528ce1288-- From nobody Fri Jan 8 11:25:36 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432741B2B32 for ; Fri, 8 Jan 2016 11:25:24 -0800 (PST) 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 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 8FBUl4m1C_hH for ; Fri, 8 Jan 2016 11:25:20 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::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 68B111B2B29 for ; Fri, 8 Jan 2016 11:25:20 -0800 (PST) Received: by mail-ig0-x22e.google.com with SMTP id mw1so79899926igb.1 for ; Fri, 08 Jan 2016 11:25:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=v3hq4cTIQ/UbNDW4TPfrFxW+hUhs0zKK4ZKwHcZPleM=; b=wIbCEP0OuhkvbF7J75WRzOXr30WI7uXySEBbQSy1JK2KuXAfCSdIgb2jaAMo3LPMsM 8um/LZK8YunLV/EynjBTPv1PtQKBQ0ZmoK0O/koao5I1JyB9yv4FNxcspOrZyRbfAxBX 8Pgt86DkXs89jU6SeGQ8UkfeS+3plDjH9RcwWgEiPWPBvPiosGAq4Os5C5Jt0Xq2r2NF RYD/MclrVKD2eOyVk8Va9N4T8jd5YTw+Dhy/yw5hFLq+c20pFIn5KEVQPmqYN+oBEF5p Iswjqq7GBCtShQeGOyYa8RgiHbHlllfjRL1DWQkwWAObLKHTUCesHoqm/7gS64VyF0Qb 9gyA== MIME-Version: 1.0 X-Received: by 10.50.143.103 with SMTP id sd7mr615569igb.58.1452281119792; Fri, 08 Jan 2016 11:25:19 -0800 (PST) Received: by 10.36.149.130 with HTTP; Fri, 8 Jan 2016 11:25:19 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Jan 2016 06:25:19 +1100 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ben Bangert , Costin Manolache , "webpush@ietf.org" Subject: Re: [Webpush] Application server authentication new years edition X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jan 2016 19:25:24 -0000 On 8 January 2016 at 19:06, Costin Manolache wrote: > It shouldn't be mandatory - just recommended that subscribe indicates who is > authorized > to send. > > A push service that doesn't require authentication can just ignore it. I don't think that ignoring is a good option. I think that the user agent should be able to expect that the push service is enforcing access control if it provides an application server key. From nobody Fri Jan 8 17:05:51 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9D01B2D1B for ; Fri, 8 Jan 2016 17:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.492 X-Spam-Level: X-Spam-Status: No, score=-1.492 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=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 2RhCwo886beE for ; Fri, 8 Jan 2016 17:05:48 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0122.outbound.protection.outlook.com [65.55.169.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36D281B2D1A for ; Fri, 8 Jan 2016 17:05:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+093fRNqJ9VEHV0q3XxkkJplMkwOYHaLX70GlRlqmTw=; b=eq/XVCNEmo/zJ6QpgolGYxmHLgyw0d2fH8HGMGmcbUGVsGFQN/IaRFFBINuLdL4yUm4yKYdnTjRZLR0ofCkZgq5p6xuZP0GHY6OzysYC+QmcnfJo125gX2jg1AjPkld+CnMHOisS4uD/lFGAHnRfjxf1m74XmmrGavGfzlbJA+M= Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) with Microsoft SMTP Server (TLS) id 15.1.365.19; Sat, 9 Jan 2016 01:05:45 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) with mapi id 15.01.0365.022; Sat, 9 Jan 2016 01:05:44 +0000 From: Brian Raymor To: =?utf-8?B?SGVydsOpIFJ1ZWxsYW4=?= , "Martin Thomson" Thread-Topic: [Webpush] Use Case related to subscription sets Thread-Index: AQHRIeqmRM5eVbt/pk6X9PcfmrGbf56iF+eAgAKj+YCAAGUkgIAADnDwgAQ3KYCAAH8PgIAADLUAgAAosSCAACwKgIABPwUAgEcmOKA= Date: Sat, 9 Jan 2016 01:05:44 +0000 Message-ID: References: <564C50B7.7070505@crf.canon.fr> <564EF895.4020200@crf.canon.fr> <5652E2CD.8090709@crf.canon.fr> <5654AABC.3000000@crf.canon.fr> In-Reply-To: <5654AABC.3000000@crf.canon.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [2601:600:8000:5a8:c031:180b:19c3:bca6] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0647; 5:n8oy84b6VVNG5NjzbT9wIGDp+gwu0x2uZQCDZEPqG99ecP53j+5fdzIbqbHGhbzdK4/h7kPZvoMaFUTwf5lo95gKoqJFvGKt/7TemSOGjsirp7WOofCsbzPbN0PiC/0WmW5R/z032yty9y4/FiQ1RQ==; 24:bgIwrjwS0DXFrWp/AxHGCB+AkDtW5N2IlSjz6t3jU8rvkc3EWT0nUXgKDVEH+4Tpli/i4pA9bK3ujXrmwdR8aHBHwCgc+bdXfW3cvM5P8zA= x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42140001); SRVR:BY2PR0301MB0647; x-ms-office365-filtering-correlation-id: d440c0c3-cf58-4be8-cdf7-08d318910086 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR0301MB0647; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0647; x-forefront-prvs: 0816F1D86E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(479174004)(377454003)(51914003)(199003)(13464003)(24454002)(40100003)(33656002)(101416001)(87936001)(15975445007)(5008740100001)(77096005)(2906002)(5002640100001)(93886004)(74316001)(10090500001)(10290500002)(5004730100002)(5005710100001)(10400500002)(99286002)(8990500004)(86362001)(105586002)(86612001)(102836003)(106116001)(122556002)(106356001)(19580405001)(19580395003)(5001960100002)(6116002)(189998001)(1220700001)(586003)(92566002)(5003600100002)(5001770100001)(81156007)(97736004)(76576001)(2950100001)(1096002)(2900100001)(76176999)(50986999)(4326007)(54356999)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0647; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2016 01:05:44.5812 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0647 Archived-At: Cc: Benjamin Bangert , "webpush@ietf.org" Subject: Re: [Webpush] Use Case related to subscription sets X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 09 Jan 2016 01:05:50 -0000 DQpJcyB0aGVyZSBhbnkgZnVydGhlciBmZWVkYmFjayBvbiBNYXJ0aW4ncyBwdWxsIHJlcXVlc3Q/ DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS93ZWJwdXNoLXdnL3dlYnB1c2gtcHJvdG9jb2wvcHVsbC82 Nw0KDQpJZiB0aGVyZSBhcmUgbm8gb2JqZWN0aW9ucywgSSdkIGxpa2UgdG8gbWVyZ2UgaW50byB0 aGUgd2VicHVzaCBkcmFmdCBlYXJseSBuZXh0IHdlZWsuDQoNCi4uLkJyaWFuDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEhlcnbDqSBSdWVsbGFuIFttYWlsdG86aGVydmUu cnVlbGxhbkBjcmYuY2Fub24uZnJdIA0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMjQsIDIwMTUg MTA6MjIgQU0NClRvOiBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPg0K Q2M6IEJlbmphbWluIEJhbmdlcnQgPGJiYW5nZXJ0QG1vemlsbGEuY29tPjsgd2VicHVzaEBpZXRm Lm9yZzsgQnJpYW4gUmF5bW9yIDxCcmlhbi5SYXltb3JAbWljcm9zb2Z0LmNvbT4NClN1YmplY3Q6 IFJlOiBbV2VicHVzaF0gVXNlIENhc2UgcmVsYXRlZCB0byBzdWJzY3JpcHRpb24gc2V0cw0KDQpU aGFua3MgZm9yIHRoZSBwdWxsIHJlcXVlc3QuDQoNCkkgZmluZCBpdCBhIGdvb2QgY29tcHJvbWlz ZTogaXQgY292ZXJzIG91ciB1c2UtY2FzZSB3aGlsZSBzdGlsbCBlbmNvdXJhZ2luZyBVQSB0byBy ZXVzZSBzdWJzY3JpcHRpb24gc2V0cy4NCg0KSGVydsOpDQoNCk9uIDI0LzExLzE1IDAwOjE5LCBN YXJ0aW4gVGhvbXNvbiB3cm90ZToNCj4gT24gMjMgTm92ZW1iZXIgMjAxNSBhdCAxMzo0NiwgQnJp YW4gUmF5bW9yIDxCcmlhbi5SYXltb3JAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQo+ID4gUGVyaGFw cyB0aGUgY29tYmluYXRpb24gb2YgInVzZXIgYWdlbnQgZGVjaWRlcyIgd2l0aCAicHVzaCBzZXJ2 aWNlICplbmNvdXJhZ2VzKiINCj4gPiBieSBsaW1pdGluZyBjb25jdXJyZW50IEhUVFAvMiBzdHJl YW1zIGlzIHRoZSBwb3RlbnRpYWwgY29tcHJvbWlzZS4NCj4NCj4gVGhhdCdzIHdoZXJlIEknbSBo ZWFkZWQuICBUaG91Z2ggSSdtIGFsc28gYWRkaW5nICJzcGVjICplbmNvdXJhZ2VzKiINCj4gYnkg dXNpbmcgdGhlIHdvcmQgTVVTVC4gIEkgZG9uJ3QgdGhpbmsgdGhhdCB3ZSBnZXQgYW55IGdhaW5z IGZvciB0aGUNCj4gaW1wb3J0YW50IHNjZW5hcmlvcyBpZiB3ZSBkb24ndCBwcm92aWRlIGF0IGxl YXN0IHNvbWUgZW5jb3VyYWdlbWVudCB0bw0KPiBhZ2dyZWdhdGUgaW50byBhIHNldC4NCj4NCj4g SSd2ZSBhZGRlZCB0ZXh0IHRvIHRoZSBQUiB0aGF0IGV4cGxhaW5zIHdoYXQgdGhlIHB1c2ggc2Vy dmljZSBtaWdodCBkbw0KPiB0byBwdW5pc2ggdXNlciBhZ2VudHMgdGhhdCBkb24ndCBhbGxvdyBm b3IgYWdncmVnYXRpb24uICBJdCdzIHJlbHlpbmcNCj4gb24gdGhlIHNhbWUgbWFnaWNhbCBhbnRp LURvUyBzdHVmZiBhZ2Fpbiwgd2hpY2ggaXMgaGFyZGx5IGV2ZXINCj4gcGVyZmVjdCwgYnV0IG9m dGVuIGFkZXF1YXRlIGluIHByYWN0aWNlLg0KPg0KPiBIZXJlIEkgZXhwZWN0IHRoYXQgbG9va2lu ZyBhdCB0aGUgY29ubmVjdGlvbiB3aWxsIHdvcmsgdG8gY2F0Y2gNCj4gZ2VudWluZSBidXQgaW5u b2NlbnQgbWlzdGFrZXMuICBUaGUgYmFkIGd1eXMgYXJlIGFsd2F5cyBnb2luZyB0byBiZQ0KPiBo YXJkZXIgdG8gcGluIGRvd24uDQo+DQoNCg== From nobody Fri Jan 8 17:11:20 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8771B2D11 for ; Fri, 8 Jan 2016 17:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 uOmrgR02a_I3 for ; Fri, 8 Jan 2016 17:11:16 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0749.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::749]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 155621B2D10 for ; Fri, 8 Jan 2016 17:11:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lmoNN+A07rjX2hwtYEs5DtdYHjBa/0yE8o8aYmLV4DI=; b=NC3AXn/HDnjc+zwjjO6pWUxga5dKhDJc1edjcd+ell8lb0uV8ZbwP96xs2/VIi29v1LdfJIcM5pZ4k3pqZFwHnlte/SbPFxqCUOllmq2eRGX1p6lxUIG+k6QhdQj+GXb9XKjtqAwGHAUJAbdbqvlEkvwI0sFYKuxT0MVW8ctKuI= Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) with Microsoft SMTP Server (TLS) id 15.1.365.19; Sat, 9 Jan 2016 01:10:56 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) with mapi id 15.01.0365.022; Sat, 9 Jan 2016 01:10:56 +0000 From: Brian Raymor To: Martin Thomson , "webpush@ietf.org" Thread-Topic: [Webpush] Message update PR Thread-Index: AQHRHY0OUNjvnweArUOkBsKYxmRdMJ7yuRcw Date: Sat, 9 Jan 2016 01:10:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [2601:600:8000:5a8:c031:180b:19c3:bca6] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0647; 5:lpYuffJOxm4wNt6FNMIhpf22CD+52ieJ51lVl4aB6oDFsR/nw3QaH4hiJiRVkpoiiThnzuOK3+VLuYJqI6PHuFDSS7GYvPsvbPdtaB/Wc8Ur5h+D22sLS8K+CiIEgiz7+4oP4eyVPw5WVsBrWmEHsg==; 24:eF72/B5i1WkI7maoJ1OIUVXim2ySBLwgUFLPK0x9cv7iMtdrCVF78fOnYSWXPjCBSTIenwda0optFLcpLM+FwlQkUkcC4Nc/LD9+I/1LQVQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0647; x-ms-office365-filtering-correlation-id: 6839047e-3027-4fe6-ca04-08d31891ba5a x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR0301MB0647; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0647; x-forefront-prvs: 0816F1D86E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(189002)(377454003)(199003)(13464003)(40100003)(33656002)(101416001)(87936001)(15975445007)(5008740100001)(77096005)(2906002)(5002640100001)(11100500001)(74316001)(10090500001)(10290500002)(5004730100002)(5005710100001)(10400500002)(99286002)(8990500004)(2501003)(86362001)(105586002)(86612001)(102836003)(106116001)(122556002)(106356001)(19580405001)(19580395003)(5001960100002)(107886002)(6116002)(189998001)(1220700001)(586003)(92566002)(5003600100002)(5001770100001)(81156007)(97736004)(76576001)(2950100001)(1096002)(2900100001)(76176999)(50986999)(54356999)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0647; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2016 01:10:56.2864 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0647 Archived-At: Subject: Re: [Webpush] Message update PR X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 09 Jan 2016 01:11:19 -0000 Is there any further feedback for Martin's pull request below? Thanks, ...Brian -----Original Message----- From: Webpush [mailto:webpush-bounces@ietf.org] On Behalf Of Martin Thomson Sent: Thursday, November 12, 2015 1:00 PM To: webpush@ietf.org Subject: [Webpush] Message update PR https://github.com/webpush-wg/webpush-protocol/pull/62 The above pull request and commit is the substance of what we discussed in Yokohama regarding push message updates. This proposes a new header field, Topic, which can be added to a push message. This doesn't really replace messages in the same way that the last one does. Instead, it causes the old message to be acknowledged/deleted at the same time that the new message is created. This avoids all the nasty race conditions we discussed at the meeting. If the old message is being delivered, then this causes it to be acknowledged early; since acknowledgment is idempotent, there are no race conditions. --Martin _______________________________________________ Webpush mailing list Webpush@ietf.org https://www.ietf.org/mailman/listinfo/webpush From nobody Fri Jan 8 17:38:08 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A109D1A0010 for ; Fri, 8 Jan 2016 17:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ZdI7eRTRpU1L for ; Fri, 8 Jan 2016 17:38:02 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0123.outbound.protection.outlook.com [207.46.100.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 879E21A000B for ; Fri, 8 Jan 2016 17:38:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=A2rf7sbyoYGEThRP7bXq9uoNa6OTAL1S5tk+wzV0+Gg=; b=RtsR7rbM2mimKaLnAF9EXDO8KXRRqa/hdHDMdaNnwvZyy2Ah0lssnsulpRW0t4FRCBzilVlOhQQ9u4akHqA3jkDqObZ+DMZ6ZUR3bHXXMHnCkX3418sJh+altnNOiYkM25j1UeL9kE3ZoMpuY5CEZFBY/wUSRLW7tduZ7ta3lZ4= Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0646.namprd03.prod.outlook.com (10.160.63.139) with Microsoft SMTP Server (TLS) id 15.1.365.19; Sat, 9 Jan 2016 01:38:00 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) with mapi id 15.01.0365.022; Sat, 9 Jan 2016 01:38:00 +0000 From: Brian Raymor To: "webpush@ietf.org" Thread-Topic: Niceness or urgency of messages Thread-Index: AdFKeqnKV7n3wo6ITMywOAMx/pggBw== Date: Sat, 9 Jan 2016 01:37:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [2601:600:8000:5a8:c031:180b:19c3:bca6] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0646; 5:TmXTDv/XiKa0n9AxWkKHa/hD5+Uw/FssRV6H96UUJtUN3NHeAAWStBtWGSPGzHwy3IDvRIe/E0mCkT8psSkHG71rk2pWyywF4LOrUUWkRMSadc2KNR4u/EIyE2QbUeJcFMkEckPoYsmzL8cMj0LF4g==; 24:QtEeDEb3tHxnvJIAIFrU2qO4LXRnXMcTgdZhpVn9uiZRxmW2DVUi9iBaX9OcXVYaFKxKQsGa7wJsle/0Q4GBGbuxmUUFjMxX3DKkfH4n7EA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0646; x-ms-office365-filtering-correlation-id: 842007d7-1b9e-4adf-8063-08d318958242 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR0301MB0646; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0646; x-forefront-prvs: 0816F1D86E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(164054003)(189002)(86362001)(1730700002)(229853001)(87936001)(2351001)(74316001)(19617315012)(99286002)(106356001)(92566002)(586003)(19625215002)(105586002)(101416001)(102836003)(1096002)(1220700001)(76576001)(790700001)(10400500002)(2906002)(33656002)(81156007)(5005710100001)(10710500007)(10290500002)(6116002)(2900100001)(5003600100002)(5002640100001)(10090500001)(40100003)(5004730100002)(2501003)(97736004)(77096005)(122556002)(8990500004)(19300405004)(5008740100001)(16236675004)(2420400006)(19580395003)(189998001)(7110500001)(50986999)(110136002)(107886002)(86612001)(450100001)(54356999)(11100500001)(15975445007)(5001960100002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0646; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR0301MB0647AF6178AB91A883D66B1683F70BY2PR0301MB0647_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2016 01:37:59.9430 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0646 Archived-At: Subject: [Webpush] Niceness or urgency of messages X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 09 Jan 2016 01:38:07 -0000 --_000_BY2PR0301MB0647AF6178AB91A883D66B1683F70BY2PR0301MB0647_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There's an active conversation occurring today in the "Niceness or urgency = of messages" github issue: https://github.com/webpush-wg/webpush-protocol/issues/28 I appreciate all the comments and encourage the WebPush WG to review ... bu= t let's also bring substantive discussions to the mailing list. Shida and Joe - would it make sense for the WebPush WG to adopt the HTTPbis= experiment - http://lists.w3.org/Archives/Public/ietf-http-wg/2015OctDec/0= 027.html - discussion and resolution of issues in the issue tracker itself? Thanks, ...Brian --_000_BY2PR0301MB0647AF6178AB91A883D66B1683F70BY2PR0301MB0647_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

There’s an active conversation occurring today= in the “Niceness or urgency of messages” github issue:

 

  https://github.com/webpush-wg/webpush-protocol/issues/28

 

I appreciate all the comments and encourage the WebP= ush WG to review ... but let’s also bring substantive discussions to = the mailing list.

 

Shida and Joe – would it make sense for the We= bPush WG to adopt the HTTPbis experiment - http://lists.w3.org/Archives/Public/ietf-http-wg/2015OctDec/0027.htm= l - discussion and resolution of issues in the issue tracker itself?

 

Thanks,

…Brian

 

 

 

 

--_000_BY2PR0301MB0647AF6178AB91A883D66B1683F70BY2PR0301MB0647_-- From nobody Sat Jan 9 10:41:51 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0AE1A8974 for ; Sat, 9 Jan 2016 10:41:50 -0800 (PST) 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 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 iFmaKC8IDuzR for ; Sat, 9 Jan 2016 10:41:49 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::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 D4EF91A896E for ; Sat, 9 Jan 2016 10:41:48 -0800 (PST) Received: by mail-ob0-x22b.google.com with SMTP id py5so3129113obc.2 for ; Sat, 09 Jan 2016 10:41:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y3saGfGNCJltxNw3x2KL1EmCZ7OdgliLIdqsnE4pymY=; b=mkuaIP6CtaZrMLCYevM8EgJ+tFJ39McSF9tRFs5SbPeJnl70wqx4yZ9nXI3ZNDEa0A FOcDzMgtbeHgrFrqX1xLJV/zEXU3oCyfRFaXeaV4c8oKTiRs6RN2vhTfdHieWeky6P4O qSrjNzEtC+QEasFflBePzHWNLdTzPWVZmhCiJ+CnnSgux+6O6KyL+EHNIpHoM57ae1lQ Y0sa7oO8skN3WWE8oehHM1V2grdzmurunKp8iMB2Cypmo02AuNhdBEoYM9yTpx65E7lu wTq1S8h7PBPI79/XoFHJ6GYnRk7BPG5KZ6z5tpAE28KjSARQs5fzu6LVu5jSGoW3Belk vxVQ== MIME-Version: 1.0 X-Received: by 10.60.135.98 with SMTP id pr2mr78250677oeb.65.1452364908196; Sat, 09 Jan 2016 10:41:48 -0800 (PST) Received: by 10.76.8.74 with HTTP; Sat, 9 Jan 2016 10:41:48 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Jan 2016 10:41:48 -0800 Message-ID: From: Costin Manolache To: Brian Raymor Content-Type: multipart/alternative; boundary=047d7b4179216ffa1b0528eb0ef6 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Niceness or urgency of messages X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 09 Jan 2016 18:41:50 -0000 --047d7b4179216ffa1b0528eb0ef6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Any way to get github to forward the bug updates to the mailing list ? Or is there a separate subscription to get all updates on the bugs ? Costin On Fri, Jan 8, 2016 at 5:37 PM, Brian Raymor wrote: > > > There=E2=80=99s an active conversation occurring today in the =E2=80=9CNi= ceness or urgency > of messages=E2=80=9D github issue: > > > > https://github.com/webpush-wg/webpush-protocol/issues/28 > > > > I appreciate all the comments and encourage the WebPush WG to review ... > but let=E2=80=99s also bring substantive discussions to the mailing list. > > > > Shida and Joe =E2=80=93 would it make sense for the WebPush WG to adopt t= he > HTTPbis experiment - > http://lists.w3.org/Archives/Public/ietf-http-wg/2015OctDec/0027.html - > discussion and resolution of issues in the issue tracker itself? > > > > Thanks, > > =E2=80=A6Brian > > > > > > > > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > --047d7b4179216ffa1b0528eb0ef6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Any way to get github to forward the bug updates to the ma= iling list ? Or is there a separate subscription to get all=C2=A0
updat= es on the bugs ?=C2=A0

Costin

On Fri, Jan 8, 2016 at 5:3= 7 PM, Brian Raymor <Brian.Raymor@microsoft.com> wro= te:

=C2=A0

There=E2=80=99s an active conversation occurring tod= ay in the =E2=80=9CNiceness or urgency of messages=E2=80=9D github issue:

=C2=A0

=C2=A0 https://github.com/webpush-wg/webpush-protocol/issues/28<= /p>

=C2=A0

I appreciate all the comments and encourage the WebP= ush WG to review ... but let=E2=80=99s also bring substantive discussions t= o the mailing list.

=C2=A0

Shida and Joe =E2=80=93 would it make sense for the = WebPush WG to adopt the HTTPbis experiment - http://lists.w3.org/Archives/Public/ietf-http-wg/2= 015OctDec/0027.html - discussion and resolution of issues in the issue = tracker itself?

=C2=A0

Thanks,

=E2=80=A6Brian

=C2=A0

=C2=A0

=C2=A0

=C2=A0


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


--047d7b4179216ffa1b0528eb0ef6-- From nobody Mon Jan 11 08:33:55 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C373E1A870F for ; Mon, 11 Jan 2016 08:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.648 X-Spam-Level: X-Spam-Status: No, score=0.648 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=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 F8wqLwLG7tul for ; Mon, 11 Jan 2016 08:33:53 -0800 (PST) Received: from inari-msr.crf.canon.fr (inari-msr.crf.canon.fr [194.2.158.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4218F1A86F1 for ; Mon, 11 Jan 2016 08:33:53 -0800 (PST) Received: from mir-bsr.corp.crf.canon.fr (mir-bsr.corp.crf.canon.fr [172.19.77.99]) by inari-msr.crf.canon.fr (8.13.8/8.13.8) with ESMTP id u0BGXnSc006141; Mon, 11 Jan 2016 17:33:49 +0100 Received: from Antiope.crf.canon.fr (antiope.fesl2.crf.canon.fr [172.19.70.56]) by mir-bsr.corp.crf.canon.fr (8.13.8/8.13.8) with ESMTP id u0BGXmIX014798; Mon, 11 Jan 2016 17:33:48 +0100 Received: from timor.intra-usr.crf.canon.fr (172.20.4.44) by Antiope.crf.canon.fr (172.19.70.62) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 11 Jan 2016 17:33:47 +0100 From: =?UTF-8?Q?Herv=c3=a9_Ruellan?= To: Brian Raymor References: <564C50B7.7070505@crf.canon.fr> <564EF895.4020200@crf.canon.fr> <5652E2CD.8090709@crf.canon.fr> <5654AABC.3000000@crf.canon.fr> Message-ID: <5693D96A.7000805@crf.canon.fr> Date: Mon, 11 Jan 2016 17:33:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.20.4.44] X-ClientProxiedBy: Antiope.crf.canon.fr (172.19.70.62) To Antiope.crf.canon.fr (172.19.70.62) Archived-At: Cc: Benjamin Bangert , Martin Thomson , "webpush@ietf.org" Subject: Re: [Webpush] Use Case related to subscription sets X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2016 16:33:54 -0000 The PR brings a good solution for our use case of a client acting as a proxy. I've got no objections merging it, on the contrary. Hervé On 09/01/16 02:05, Brian Raymor wrote: > > Is there any further feedback on Martin's pull request? > > https://github.com/webpush-wg/webpush-protocol/pull/67 > > If there are no objections, I'd like to merge into the webpush draft early next week. > > ...Brian > > > -----Original Message----- > From: Hervé Ruellan [mailto:herve.ruellan@crf.canon.fr] > Sent: Tuesday, November 24, 2015 10:22 AM > To: Martin Thomson > Cc: Benjamin Bangert ; webpush@ietf.org; Brian Raymor > Subject: Re: [Webpush] Use Case related to subscription sets > > Thanks for the pull request. > > I find it a good compromise: it covers our use-case while still encouraging UA to reuse subscription sets. > > Hervé > > On 24/11/15 00:19, Martin Thomson wrote: > > On 23 November 2015 at 13:46, Brian Raymor wrote: > >> Perhaps the combination of "user agent decides" with "push service *encourages*" > >> by limiting concurrent HTTP/2 streams is the potential compromise. > > > > That's where I'm headed. Though I'm also adding "spec *encourages*" > > by using the word MUST. I don't think that we get any gains for the > > important scenarios if we don't provide at least some encouragement to > > aggregate into a set. > > > > I've added text to the PR that explains what the push service might do > > to punish user agents that don't allow for aggregation. It's relying > > on the same magical anti-DoS stuff again, which is hardly ever > > perfect, but often adequate in practice. > > > > Here I expect that looking at the connection will work to catch > > genuine but innocent mistakes. The bad guys are always going to be > > harder to pin down. > > > From nobody Mon Jan 11 09:00:49 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AB01A8ABB for ; Mon, 11 Jan 2016 09:00:46 -0800 (PST) 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 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 VukqeQA5z1St for ; Mon, 11 Jan 2016 09:00:43 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003: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 AA5891A8AC0 for ; Mon, 11 Jan 2016 09:00:43 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id w75so23838953oie.0 for ; Mon, 11 Jan 2016 09:00:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e2hIQT9nZ5sY6HR06QtHcdZmOrWxZme+RrSuoDPb6g0=; b=MAYJ7FDjh9B1c9P9uQP5udS3/jz3OvRc3FJDqEf0fLIJRQyFM4tmO/R93MJMASPQqT oShH6B+TPAWgjUBy/unehR3xlls8MmzqeF1ari+siUwEQwKCaAa3Vi2HXG9jsX4PqpAv u8hI0XmuYh/aF56kYnWtYSKuQReC4bi9dWBhKIpnG6nPnloEGVjrtyEoA61iVY/9irna /mMhLBDtyrEkmBFLWfExUvLXJ3kb/VTDFuINIm/Sr6526gmYHTYXIaUqOfBBrZEzgpvs nwnTYl19jukeAP06d0iTwTI6jQgcTaQrfUmOVKAaoBX8NM+cEXyGpEQg7bw4aIuQ4V8y X0XA== MIME-Version: 1.0 X-Received: by 10.202.204.136 with SMTP id c130mr91921203oig.93.1452531643034; Mon, 11 Jan 2016 09:00:43 -0800 (PST) Received: by 10.76.8.74 with HTTP; Mon, 11 Jan 2016 09:00:42 -0800 (PST) In-Reply-To: References: Date: Mon, 11 Jan 2016 17:00:42 +0000 Message-ID: From: Costin Manolache To: Brian Raymor Content-Type: multipart/alternative; boundary=001a1137b1129bba49052911e031 Archived-At: Cc: Martin Thomson , "webpush@ietf.org" Subject: Re: [Webpush] Message update PR X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2016 17:00:46 -0000 --001a1137b1129bba49052911e031 Content-Type: text/plain; charset=UTF-8 - +1 in general - Doubts about the name "Topic" - many pubsub users will be confused, it is not really a topic, just a key - We may relax the '4 collapse keys' limit for GCM, shouldn't be a problem for webpush. Can we change a bit the wording to allow some optimizations we do: a message with topic (collapse key) may be optimized for 'sync usage' - i.e. even if the device is online, if push service detects frequent messages in a topic (for example user receives lots of email) it may delay and collapse messages. I.e. not only " If the user agent is offline". Also I would prefer (for implementation purpose) a simpler ID syntax instead of quoted string. It's going to be a database key, short an unambiguous seems better. URI path component would be nice. Finally, a more generic approach would be to allow the sender to specify a MessageID - than multiple messages with the same ID could override each other ( identical with topic ), but the main benefit is that senders will avoid a lookup and mapping push-service IDs to their internal IDs in acks. Push service can internally combine the subscription ID with the sender-provided message ID. Costin On Sat, Jan 9, 2016 at 1:10 AM, Brian Raymor wrote: > Is there any further feedback for Martin's pull request below? > > Thanks, > ...Brian > > -----Original Message----- > From: Webpush [mailto:webpush-bounces@ietf.org] On Behalf Of Martin > Thomson > Sent: Thursday, November 12, 2015 1:00 PM > To: webpush@ietf.org > Subject: [Webpush] Message update PR > > https://github.com/webpush-wg/webpush-protocol/pull/62 > > The above pull request and commit is the substance of what we > discussed in Yokohama regarding push message updates. This proposes a > new header field, Topic, which can be added to a push message. > > This doesn't really replace messages in the same way that the last one > does. Instead, it causes the old message to be acknowledged/deleted > at the same time that the new message is created. This avoids all the > nasty race conditions we discussed at the meeting. If the old message > is being delivered, then this causes it to be acknowledged early; > since acknowledgment is idempotent, there are no race conditions. > > --Martin > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --001a1137b1129bba49052911e031 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
- +1 in general

- Doubts about the name= "Topic" - many pubsub users will be confused, it is not really a= topic,
just a key

- =C2=A0We may relax = the '4 collapse keys' limit for GCM, shouldn't be a problem for= webpush.

Can we change a bit the wording to allow= some optimizations we do: a message with topic (collapse
key) ma= y be optimized for 'sync usage' - i.e. even if the device is online= , if push service detects=C2=A0
frequent messages in a topic (for= example user receives lots of email) it may delay and collapse
m= essages. I.e. not only "=C2=A0If the user agent is offline".

Also I would prefer (for implementation purpose) a sim= pler ID syntax instead of quoted string.
It's going to be a d= atabase key, short an unambiguous seems better. URI path component would
be nice.=C2=A0

Finally, a more generic app= roach would be to allow the sender to specify a MessageID - than
= multiple messages with the same ID could override each other ( identical wi= th topic ), but the main
benefit is that senders will avoid a loo= kup and mapping push-service IDs to their internal IDs in
acks. P= ush service can internally combine the subscription ID with the sender-prov= ided message ID.


Costin
=

On Sat, Jan 9, 20= 16 at 1:10 AM, Brian Raymor <Brian.Raymor@microsoft.com> wrote:
Is there any further feedbac= k for Martin's pull request below?

Thanks,
...Brian

-----Original Message-----
From: Webpush [mailto:webpush-b= ounces@ietf.org] On Behalf Of Martin Thomson
Sent: Thursday, November 12, 2015 1:00 PM
To: webpush@ietf.org
Subject: [Webpush] Message update PR

https://github.com/webpush-wg/webpush-protocol= /pull/62

The above pull request and commit is the substance of what we
discussed in Yokohama regarding push message updates.=C2=A0 This proposes a=
new header field, Topic, which can be added to a push message.

This doesn't really replace messages in the same way that the last one<= br> does.=C2=A0 Instead, it causes the old message to be acknowledged/deleted at the same time that the new message is created.=C2=A0 This avoids all the=
nasty race conditions we discussed at the meeting.=C2=A0 If the old message=
is being delivered, then this causes it to be acknowledged early;
since acknowledgment is idempotent, there are no race conditions.

--Martin

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

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

--001a1137b1129bba49052911e031-- From nobody Mon Jan 11 09:16:59 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A421A8ADA for ; Mon, 11 Jan 2016 09:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 9RmokNy-TEl8 for ; Mon, 11 Jan 2016 09:16:56 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003: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 9D9FE1A011C for ; Mon, 11 Jan 2016 09:16:56 -0800 (PST) Received: by mail-oi0-x232.google.com with SMTP id w75so24176845oie.0 for ; Mon, 11 Jan 2016 09:16:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ppyn1Wwi5tautCbGQO26Cy4RBqbfEStc7MvPtqwegio=; b=c3z0DLe8yYkIVth0wSb017LraVl7L0+GcOQkzk2RCI3mYJeC8EO3xFkKNhdIkM5whx kn+T9QiHLEthsU8q3il3DQacpL8psUMjq3VmxpBiYucV49uOSfVTpIFmIuHBF8rAKouw 8kZIvD08tEVnbo/8hybE5Xg7sWz3l8jKRrVST1HcKn//4yakr9u/ZSqYdPG8Smga1sX5 l6vQ4loq6ZDMdL0anIUs6yDSeog2egFD65aQWml/rpslhW5ZGhME34mYB4gnfd3601CX zmshjzqJ+PNKKpdJ/1f2Tstp9gmAqEGLZ/1Yg35eMsDt+jDVcZ5e09SCN+t6gxmbe5OD mEsA== MIME-Version: 1.0 X-Received: by 10.202.204.136 with SMTP id c130mr92005162oig.93.1452532615952; Mon, 11 Jan 2016 09:16:55 -0800 (PST) Received: by 10.76.8.74 with HTTP; Mon, 11 Jan 2016 09:16:55 -0800 (PST) In-Reply-To: <5693D96A.7000805@crf.canon.fr> References: <564C50B7.7070505@crf.canon.fr> <564EF895.4020200@crf.canon.fr> <5652E2CD.8090709@crf.canon.fr> <5654AABC.3000000@crf.canon.fr> <5693D96A.7000805@crf.canon.fr> Date: Mon, 11 Jan 2016 17:16:55 +0000 Message-ID: From: Costin Manolache To: =?UTF-8?Q?Herv=C3=A9_Ruellan?= Content-Type: multipart/alternative; boundary=001a1137b11299403b0529121a21 Archived-At: Cc: Benjamin Bangert , Brian Raymor , Martin Thomson , "webpush@ietf.org" Subject: Re: [Webpush] Use Case related to subscription sets X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2016 17:16:58 -0000 --001a1137b11299403b0529121a21 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It's even more complicated if you consider that a camera may have it's own wifi connection ( watches are in this situation). Another example is 'multiple profiles/users' on the same device, sharing a single TCP connection. No objections - but it's one of the most difficult problems, implementing it efficiently is tricky. I suggest considering the same authentication mechanism that we discussed for app servers in the case of UAs - i.e. a JWT, signed with UA-generated key. Would eliminate some ambiguity, and make it a bit more clear what happens in cases of multiple paths to reach the final device ( camera/watch/etc). Costin On Mon, Jan 11, 2016 at 4:33 PM, Herv=C3=A9 Ruellan wrote: > The PR brings a good solution for our use case of a client acting as a > proxy. I've got no objections merging it, on the contrary. > > Herv=C3=A9 > > > On 09/01/16 02:05, Brian Raymor wrote: > >> >> Is there any further feedback on Martin's pull request? >> >> https://github.com/webpush-wg/webpush-protocol/pull/67 >> >> If there are no objections, I'd like to merge into the webpush draft >> early next week. >> >> ...Brian >> >> >> -----Original Message----- >> From: Herv=C3=A9 Ruellan [mailto:herve.ruellan@crf.canon.fr] >> Sent: Tuesday, November 24, 2015 10:22 AM >> To: Martin Thomson >> Cc: Benjamin Bangert ; webpush@ietf.org; Brian >> Raymor >> Subject: Re: [Webpush] Use Case related to subscription sets >> >> Thanks for the pull request. >> >> I find it a good compromise: it covers our use-case while still >> encouraging UA to reuse subscription sets. >> >> Herv=C3=A9 >> >> On 24/11/15 00:19, Martin Thomson wrote: >> > On 23 November 2015 at 13:46, Brian Raymor >> wrote: >> >> Perhaps the combination of "user agent decides" with "push service >> *encourages*" >> >> by limiting concurrent HTTP/2 streams is the potential compromise. >> > >> > That's where I'm headed. Though I'm also adding "spec *encourages*" >> > by using the word MUST. I don't think that we get any gains for the >> > important scenarios if we don't provide at least some encouragement to >> > aggregate into a set. >> > >> > I've added text to the PR that explains what the push service might do >> > to punish user agents that don't allow for aggregation. It's relying >> > on the same magical anti-DoS stuff again, which is hardly ever >> > perfect, but often adequate in practice. >> > >> > Here I expect that looking at the connection will work to catch >> > genuine but innocent mistakes. The bad guys are always going to be >> > harder to pin down. >> > >> >> > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --001a1137b11299403b0529121a21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's even more complicated if you consider that a came= ra may have it's
own wifi connection ( watches are in this situatio= n). Another example is=C2=A0
'multiple profiles/users' on= the same device, sharing a single TCP connection.=C2=A0

No objections - but it's one of the most difficult problems, implement= ing it efficiently is tricky.

I suggest considerin= g the same authentication mechanism that we discussed for app servers
=
in the case of UAs - i.e. a JWT, signed with UA-generated key. W= ould eliminate some=C2=A0
ambiguity, and make it a bit more clear= what happens in cases of multiple paths to reach=C2=A0
the final= device ( camera/watch/etc).

Costin

On Mon, Jan 11, 2016= at 4:33 PM, Herv=C3=A9 Ruellan <herve.ruellan@crf.canon.fr&g= t; wrote:
The PR brings a good sol= ution for our use case of a client acting as a proxy. I've got no objec= tions merging it, on the contrary.

Herv=C3=A9


On 09/01/16 02:05, Brian Raymor wrote:

Is there any further feedback on Martin's pull request?

https://github.com/webpush-wg/webpush-protocol= /pull/67

If there are no objections, I'd like to merge into the webpush draft ea= rly next week.

...Brian


-----Original Message-----
From: Herv=C3=A9 Ruellan [mailto:herve.ruellan@crf.canon.fr]
Sent: Tuesday, November 24, 2015 10:22 AM
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Benjamin Bangert <bbangert@mozilla.com>; webpush@ietf.org; Brian Raymor <Brian.Raymor@microsoft.com= >
Subject: Re: [Webpush] Use Case related to subscription sets

Thanks for the pull request.

I find it a good compromise: it covers our use-case while still encouraging= UA to reuse subscription sets.

Herv=C3=A9

On 24/11/15 00:19, Martin Thomson wrote:
> On 23 November 2015 at 13:46, Brian Raymor <Brian.Raymor@microsoft.com>= wrote:
>> Perhaps the combination of "user agent decides" with &qu= ot;push service *encourages*"
>> by limiting concurrent HTTP/2 streams is the potential compromise.=
>
> That's where I'm headed.=C2=A0 Though I'm also adding &quo= t;spec *encourages*"
> by using the word MUST.=C2=A0 I don't think that we get any gains = for the
> important scenarios if we don't provide at least some encouragemen= t to
> aggregate into a set.
>
> I've added text to the PR that explains what the push service migh= t do
> to punish user agents that don't allow for aggregation.=C2=A0 It&#= 39;s relying
> on the same magical anti-DoS stuff again, which is hardly ever
> perfect, but often adequate in practice.
>
> Here I expect that looking at the connection will work to catch
> genuine but innocent mistakes.=C2=A0 The bad guys are always going to = be
> harder to pin down.
>


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

--001a1137b11299403b0529121a21-- From nobody Mon Jan 11 15:57:25 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74B61A888B for ; Mon, 11 Jan 2016 15:57:23 -0800 (PST) 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 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 w0ou84MlWdSx for ; Mon, 11 Jan 2016 15:57:22 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::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 2FA3B1A877A for ; Mon, 11 Jan 2016 15:57:22 -0800 (PST) Received: by mail-ig0-x232.google.com with SMTP id t15so108005026igr.0 for ; Mon, 11 Jan 2016 15:57:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JxbshI8DtDb6uXlvrcmbMKLLPmL6aSu4OXDf+jUIpAU=; b=K6oglMrqq6I+EJE6lbJDkGIYodid1nyhYB63Z2UO1/vj7SPo7qR4hSpIwdBVPTSzSJ CHFOgyMGSexvSmI6d+5mTn7tRVPIp7nbICAmje7Oljsh8InrYrtaKcL/it8F+nLvTJE7 acwDa0NShgNCjlA76vkigkTi/vKT56BXBphxCtBIjDEmsaEN7SIDhFLzojNXcAOlBRvp cabsbb/ypUyjX4kIgDFCaF0aeAJ4VJsdRfQZlKCgaSC8zKeJK61gXZKMy0q/wJJ6Ut/o 1S7Yik1kw8lnOw5F6sfyHqTuVhqLC8A1fOkkBavObGRGrcUsQ1hNALKzkrdruQjvZmxw w3og== MIME-Version: 1.0 X-Received: by 10.50.60.6 with SMTP id d6mr15621667igr.94.1452556641566; Mon, 11 Jan 2016 15:57:21 -0800 (PST) Received: by 10.36.149.130 with HTTP; Mon, 11 Jan 2016 15:57:21 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Jan 2016 10:57:21 +1100 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Brian Raymor , "webpush@ietf.org" Subject: Re: [Webpush] Message update PR X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2016 23:57:24 -0000 On 12 January 2016 at 04:00, Costin Manolache wrote: > - +1 in general > > - Doubts about the name "Topic" - many pubsub users will be confused, it is > not really a topic, > just a key I'm happy to take suggestions on the name, it's just a name :) >From my perspective however, the pubsub use fits almost perfectly with this use, so I think that the name is a bit of an advantage. > - We may relax the '4 collapse keys' limit for GCM, shouldn't be a problem > for webpush. That would be awesome (I hear that collapse keys are very heavily used by some big sites, I wonder if you aren't already feeling the pressure there). > Can we change a bit the wording to allow some optimizations we do: a message > with topic (collapse > key) may be optimized for 'sync usage' - i.e. even if the device is online, > if push service detects > frequent messages in a topic (for example user receives lots of email) it > may delay and collapse > messages. I.e. not only " If the user agent is offline". That should always be possible. If the text implies otherwise, then we should correct that. > Also I would prefer (for implementation purpose) a simpler ID syntax instead > of quoted string. > It's going to be a database key, short an unambiguous seems better. URI path > component would > be nice. Would the base64(url) alphabet suit you well enough? I didn't add that restriction. What about a length restriction? I think that Ben and I discussed just rejecting push messages with ridiculously long topic names. > Finally, a more generic approach would be to allow the sender to specify a > MessageID - than > multiple messages with the same ID could override each other ( identical > with topic ), but the main > benefit is that senders will avoid a lookup and mapping push-service IDs to > their internal IDs in > acks. Push service can internally combine the subscription ID with the > sender-provided message ID. Maybe I'm not understanding you here, but isn't that exactly what this change does? From nobody Mon Jan 11 17:04:35 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23BC1ACCEA for ; Mon, 11 Jan 2016 17:04:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.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, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 MoboAgEnWNAO for ; Mon, 11 Jan 2016 17:04:32 -0800 (PST) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 A51BF1ACCE8 for ; Mon, 11 Jan 2016 17:04:32 -0800 (PST) Received: by mail-oi0-x233.google.com with SMTP id p187so45356695oia.2 for ; Mon, 11 Jan 2016 17:04:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g/Xgl54Jfifzzgm5qnd6Q0gXkh2m7RSfMfuDFPMj40M=; b=a9UD62vYB76yDhTELkQlIB3AE8SrkmVMlUhIL19qunftmsLPzaclU6DpOxRy6RLjpq y3J9WCvNtEOmJ7oeX1y/ruqe/Erjs+2RfeN5ggzxD+RV6mbO+eCKfzSKLuV7Q0zAyq7/ DNl8PqH4m/3ja6ASED7ymTPlCmtQPkQf58TFLBgGYdNPHE+aMrArPHK3b/bJzekuRrBs Vzb12Rg7zhIX8PznIaLFwrFHIik5Jhhs6d6bkKGlhGLs5OBoK5Vkgs52MmtrpGQ80BCV gzV4KGQ64/oIDqVlIx1z28BkUfrfvCkEq3Z6oYcvw9p6BL6H1ZJvl4vUh7OHmMiw/nQx f2vQ== MIME-Version: 1.0 X-Received: by 10.202.204.136 with SMTP id c130mr93699163oig.93.1452560671986; Mon, 11 Jan 2016 17:04:31 -0800 (PST) Received: by 10.76.8.74 with HTTP; Mon, 11 Jan 2016 17:04:31 -0800 (PST) In-Reply-To: References: Date: Mon, 11 Jan 2016 17:04:31 -0800 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1137b112de5b97052918a2da Archived-At: Cc: Brian Raymor , "webpush@ietf.org" Subject: Re: [Webpush] Message update PR X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2016 01:04:35 -0000 --001a1137b112de5b97052918a2da Content-Type: text/plain; charset=UTF-8 On Mon, Jan 11, 2016 at 3:57 PM, Martin Thomson wrote: > On 12 January 2016 at 04:00, Costin Manolache wrote: > > - +1 in general > > > > - Doubts about the name "Topic" - many pubsub users will be confused, it > is > > not really a topic, > > just a key > > I'm happy to take suggestions on the name, it's just a name :) > 'collapse_key' is what is used in GCM, I think having 'collapse' or 'override' or 'replace' or 'update' in the name would describe what happens. > > From my perspective however, the pubsub use fits almost perfectly with > this use, so I think that the name is a bit of an advantage. > I don't think it fits so well. If you publish 3 messages on a pubsub topic, you expect subscribers to get 3 messages, not to have them all collapsed. And the topic is mapped to a list of receivers, etc. I know broadcast is not in scope for this release - but if/when we add it, it will make things more confusing with topic. > > - We may relax the '4 collapse keys' limit for GCM, shouldn't be a > problem > > for webpush. > > That would be awesome (I hear that collapse keys are very heavily used > by some big sites, I wonder if you aren't already feeling the pressure > there). > The intent of having just 4 keys was to encourage senders to use 'collapse' just for sync, and not attempt too much granularity. You tell the device to sync, with some info (10 mails and 7 spams), this gets updated while device is offline - and results in one sync that fetches everything. A single collapse key may have been better, to avoid confusion :-). At that time it was not yet clear how well things will work, and sync was the main use case. Most senders with collapse seem to be using a single key. > > > Can we change a bit the wording to allow some optimizations we do: a > message > > with topic (collapse > > key) may be optimized for 'sync usage' - i.e. even if the device is > online, > > if push service detects > > frequent messages in a topic (for example user receives lots of email) it > > may delay and collapse > > messages. I.e. not only " If the user agent is offline". > > That should always be possible. If the text implies otherwise, then > we should correct that. > > > Also I would prefer (for implementation purpose) a simpler ID syntax > instead > > of quoted string. > > It's going to be a database key, short an unambiguous seems better. URI > path > > component would > > be nice. > > Would the base64(url) alphabet suit you well enough? I didn't add > that restriction. > > What about a length restriction? I think that Ben and I discussed > just rejecting push messages with ridiculously long topic names. > > Agreed, base64(url) with a reasonable size is good. A 64-bit long or UUID would be great too. AFAIK most collapse keys are 2..4 letters ( mail, cl, all, sync ...) > > Finally, a more generic approach would be to allow the sender to specify > a > > MessageID - than > > multiple messages with the same ID could override each other ( identical > > with topic ), but the main > > benefit is that senders will avoid a lookup and mapping push-service IDs > to > > their internal IDs in > > acks. Push service can internally combine the subscription ID with the > > sender-provided message ID. > > Maybe I'm not understanding you here, but isn't that exactly what this > change does? > Not sure :-) Current patch requires the messages to include the topic header, and it still generates 3 message IDs ( "creates a new push message resource") Alternative would be to just allow updating the original resource, if it was not sent. BTW - there is one important change in the patch, allowing push senders to DELETE the resource. Allowing update would be consistent with that. Costin --001a1137b112de5b97052918a2da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 11, 2016 at 3:57 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 12 January 2016 at 04:00, Costin Manolache <costin@gmail.com> wrote:
> - +1 in general
>
> - Doubts about the name "Topic" - many pubsub users will be = confused, it is
> not really a topic,
> just a key

I'm happy to take suggestions on the name, it's just a name = :)

'collapse_key' is what is us= ed in GCM, I think having 'collapse' or 'override' or=C2=A0=
'replace' or 'update' in the name would describe= what happens.=C2=A0
=C2=A0

>From my perspective however, the pubsub use fits almost perfectly with
this use, so I think that the name is a bit of an advantage.

I don't think it fits so well.=C2=A0
If= you publish 3 messages on a pubsub topic, you expect subscribers to get 3 = messages,=C2=A0
not to have them all collapsed. And the topic= is mapped to a list of receivers, etc.
=C2=A0
I know b= roadcast is not in scope for this release - but if/when we add it, it will = make things
more confusing with topic.=C2=A0

=

> -=C2=A0 We may relax the '4 collapse keys' limit for GCM, shou= ldn't be a problem
> for webpush.

That would be awesome (I hear that collapse keys are very heavily us= ed
by some big sites, I wonder if you aren't already feeling the pressure<= br> there).

The intent of having just 4 key= s was to encourage senders to use 'collapse' just for sync,
and not attempt too much granularity. You tell the device to sync, with = some info (10 mails and 7 spams),
this gets updated while device = is offline - and results in one sync that fetches everything.
A single collapse key may have been better, to avoid confusion = :-). At that time it was not yet=C2=A0
clear how well things will= work, and sync was the main use case. Most senders with collapse
seem to be using a single key.=C2=A0

=C2=A0
=

> Can we change a bit the wording to allow some optimizations we do: a m= essage
> with topic (collapse
> key) may be optimized for 'sync usage' - i.e. even if the devi= ce is online,
> if push service detects
> frequent messages in a topic (for example user receives lots of email)= it
> may delay and collapse
> messages. I.e. not only " If the user agent is offline".

That should always be possible.=C2=A0 If the text implies otherwise,= then
we should correct that.

> Also I would prefer (for implementation purpose) a simpler ID syntax i= nstead
> of quoted string.
> It's going to be a database key, short an unambiguous seems better= . URI path
> component would
> be nice.

Would the base64(url) alphabet suit you well enough?=C2=A0 I didn= 9;t add
that restriction.

What about a length restriction?=C2=A0 I think that Ben and I discussed
just rejecting push messages with ridiculously long topic names.


Agreed, base64= (url) with a reasonable size is good.

A 64-bit lon= g or UUID would be great too. AFAIK most collapse keys are 2..4 letters ( m= ail, cl,
all, sync ...)

=C2=A0
> Finally, a more generic approach would be to allow the sender to speci= fy a
> MessageID - than
> multiple messages with the same ID could override each other ( identic= al
> with topic ), but the main
> benefit is that senders will avoid a lookup and mapping push-service I= Ds to
> their internal IDs in
> acks. Push service can internally combine the subscription ID with the=
> sender-provided message ID.

Maybe I'm not understanding you here, but isn't that exactly= what this
change does?

Not sure :-)
<= div class=3D"gmail_extra">
Current patc= h requires the messages to include the topic header, and it still
generates 3 message IDs ( "creates a new push m= essage resource")

Alternative would be to just allow updating the original r= esource, if it was
not sent.=C2=A0

BTW - there is= one important change in the patch, allowing push senders to DELETE
the resource. Allowing update would be consistent = with that.


Costin
--001a1137b112de5b97052918a2da-- From nobody Sun Jan 24 18:08:11 2016 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 B24DC1A8988; Sun, 17 Jan 2016 13:05:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160117210542.10409.26319.idtracker@ietfa.amsl.com> Date: Sun, 17 Jan 2016 13:05:42 -0800 Archived-At: X-Mailman-Approved-At: Sun, 24 Jan 2016 18:08:10 -0800 Cc: shida@ntt-at.com, webpush-chairs@ietf.org, alissa@cooperw.in, webpush@ietf.org Subject: [Webpush] webpush - New Meeting Session Request for IETF 95 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 17 Jan 2016 21:05:42 -0000 A new meeting session request has just been submitted by Shida Schubert, a Chair of the webpush working group. --------------------------------------------------------- Working Group Name: Web-Based Push Notifications Area Name: Applications and Real-Time Area Session Requester: Shida Schubert Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: dispatch httpbis mmusic tram rtcweb appsawg modern Second Priority: netvc perc stir sipcore Third Priority: clue Special Requests: --------------------------------------------------------- From nobody Wed Jan 27 20:32:53 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A4C1B32D5 for ; Wed, 27 Jan 2016 20:32:51 -0800 (PST) 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 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 oYcJioFIzVCB for ; Wed, 27 Jan 2016 20:32:50 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::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 090CA1B32D1 for ; Wed, 27 Jan 2016 20:32:50 -0800 (PST) Received: by mail-ig0-x22f.google.com with SMTP id mw1so4771580igb.1 for ; Wed, 27 Jan 2016 20:32:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NyNPOGb+j3T5ehUPmLwTNQ0/5BmNL9IwINUfsgbvbro=; b=rJt7l1mcbgRyArZCIhZ/BxjInN/vDjE2LayGhmasN/d9jEZ3ilomY+Vmqk1Y/zjuM3 5FLAw8NMfXLDjiLA5FRVMnrIcpQDoWU6MJf6dqMsKp10yHBDfywvjBYV7zSOZArPxVuk zDKsNZGDJKZNVfwS2SIFS960N+0eLFqcYnCFEpq/825TIxs5CgI4kewBv4rFcBiGGIuY kI5VV6EsLO1dsG/SYPohlAGdJMuVFtNyNvahJtQLKag7l23MUstzc1LyC7gWDBZmmQhm lrO7MU+gDI1vzx4+jqncbQDdMBrz5R88b35bOUFeYLCNOfOmfvI5Z4CsrVhHFz4bDOAY Y5rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NyNPOGb+j3T5ehUPmLwTNQ0/5BmNL9IwINUfsgbvbro=; b=gSJSgEwgmnzMdYOTpTNtGS1Iq7cBqg8H7JEDKxG3HvOk2D4bNJhuSn0JNgiLuUG4bz BZmwuuWRfWdgp4/fIgM2P8U+Y8UKZ7JsmznvEKlA7/W7/jnOwhBbCusW5ZsN2VkopCQ8 Z0vbppimEz2fWTK2WT3WsqXL/eQC8A0TlJk7T5pAjXhyMrgMB2WppoIHe4BRZDqrvkm0 lj5FZq8qJ0G+dZumjRVWWteh4/h0nWqBcfgFLy2DBXm5HtpJKQ4BHupFe65axVWOBjOX Flc9YoL358xkpBkhIMeIwD5FhzjXDVS2PGxIXT30BVokT2yqKvPbc2CTmnxH7Vo/Onj5 7UrQ== X-Gm-Message-State: AG10YORfLL7A2RzkZsukzemFoKTqmpmVcjz4fREr/dJkKCQwwcUhZUjU0LdPs7jFyFQUIXiPbeJwNaygoEJs3Q== MIME-Version: 1.0 X-Received: by 10.50.13.102 with SMTP id g6mr1015822igc.77.1453955569340; Wed, 27 Jan 2016 20:32:49 -0800 (PST) Received: by 10.36.149.130 with HTTP; Wed, 27 Jan 2016 20:32:49 -0800 (PST) In-Reply-To: References: Date: Thu, 28 Jan 2016 15:32:49 +1100 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Brian Raymor , "webpush@ietf.org" Subject: Re: [Webpush] Message update PR X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jan 2016 04:32:51 -0000 Sorry about the much-belated response. I'm updating the PR with a length restriction. Still not sure about the On 12 January 2016 at 12:04, Costin Manolache wrote: > I know broadcast is not in scope for this release - but if/when we add it, > it will make things > more confusing with topic. Hmm, that may be right. But a short name that isn't already taken is hard to find. Collapse-Key is highly application-specific and I know that HTTP have a problem with single-purpose header fields. I was tempted to suggest "Subject" actually as being similar, but not the same. >> Would the base64(url) alphabet suit you well enough? I didn't add >> that restriction. >> >> What about a length restriction? I think that Ben and I discussed >> just rejecting push messages with ridiculously long topic names. >> > > Agreed, base64(url) with a reasonable size is good. UUID runs to quite a few characters, so how about 32 characters from the base64 URL-safe alphabet. I'll put that in the PR. > Current patch requires the messages to include the topic header, and it > still > generates 3 message IDs ( "creates a new push message resource") Yes, you are right. Though I think that you only need a single message ID here. > Alternative would be to just allow updating the original resource, if it was > not sent. Yes, but that requires knowing the identity of the original resource, something that requires additional state at the application server. The discussion at the last meeting revealed that many application servers don't like this as it imposes restrictions on how they operate and a bunch of extra state. > BTW - there is one important change in the patch, allowing push senders to > DELETE > the resource. Allowing update would be consistent with that. Yes, DELETE is very useful, though it does require some state. This isn't really new though. Note that you can also push with the same topic and a very short TTL to in-effect reduce the TTL of an existing message. I struggled to explain that clearly in the PR as Brian will tell you, but it's an option for those who don't like maintaining the extra state. From nobody Sun Jan 31 17:56:24 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B051A87E6 for ; Sun, 31 Jan 2016 17:56:23 -0800 (PST) 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 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 SpUVUAWTRPMd for ; Sun, 31 Jan 2016 17:56:22 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 CE3441A87E4 for ; Sun, 31 Jan 2016 17:56:21 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id 9so62842499iom.1 for ; Sun, 31 Jan 2016 17:56:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=6MoUj72d71t+Aa2cZ/ZznE2eQZv4efNm6DvPRpSA37U=; b=mEMrRXnoyQ4CVMuDBH6AaPE37H96SDsniqQwxSv870wj08ncTrwTDRidO5XRdWx8b5 bkhfQEJqIfSzThGCDSIIBJykBNR/DrAA3yethHHRk2lOjdgfxMZVr7+fQUWwoj7PvnAF nAKbMjwvHNZFx7azbqZq17LucJCJYzeKSYdAj6q/JnFQ3dAG7K7j3s/yu/7DsW8cWqQ6 QbPWpDQ/1RJUY3uCrcJ9IaHlBcM/g0Dr4KbxziexfbbOebuX4mdU6AeU0e4Mi4BzyOTI S5d5M7/sQrIPBxqhik0ZanJS35G3aszhMAdFCmQNdTxEeOshSTpngeDMTrbIZhgF9/Un sUdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=6MoUj72d71t+Aa2cZ/ZznE2eQZv4efNm6DvPRpSA37U=; b=XhzgiOM9z91F7q4iEvIQKYwDyeg9WIxus/Bi79+AAknrD3Dvg5Vjd8hWWiDFSg6eOe GXw6EZRTS/Vsj0rdZJ2RkSmuaIDOxXiabEOVCwQPsY6Iw8o4t5UaHtEr6gXXjLM9ow/T fqOrFezXJT+mScg42JkaQWEeCUO/ZW5Y96CDViqP0i9/t5diPKxmUC1VBEGIC6EwjTO9 hSrhT4/bUnKS27IoLuuK/7EDvbTK0h+wrIMwBIJlAM2cyxdoP7bXhc9Bh4PDPeJqy8A4 K6vw322sHTJP4mHnK5lj5bzUjFkFsKCABa2E5dwIpznrL6WAap7D7rw2Slc5JVR3ZeU1 cWVw== X-Gm-Message-State: AG10YOQZ/uYX7VAhvWWqQeUHjKpfSKdAvYNWY1OOw9gM49oGlR2/f5XjzVAVhdm1siHwu/8rQPKN01XQk14n9g== MIME-Version: 1.0 X-Received: by 10.107.33.14 with SMTP id h14mr18995528ioh.108.1454291781169; Sun, 31 Jan 2016 17:56:21 -0800 (PST) Received: by 10.36.149.130 with HTTP; Sun, 31 Jan 2016 17:56:21 -0800 (PST) Date: Mon, 1 Feb 2016 12:56:21 +1100 Message-ID: From: Martin Thomson To: "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Webpush] Voluntary Application Server Identification -02 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 01 Feb 2016 01:56:23 -0000 I have just posted a new version of the draft, taking the recent feedback from discussions into account. https://tools.ietf.org/html/draft-thomson-webpush-vapid-02 This includes only the JWT option, with a lot more of the details fleshed out. I've implemented it in order to create the example, and that is dead simple to do. I think that this is the answer we want for issue 44 [44]. Does the group agree? Is this worth adopting? [44] https://github.com/webpush-wg/webpush-protocol/issues/44 From nobody Sun Jan 31 22:42:36 2016 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 C65361ADBFB; Sun, 31 Jan 2016 22:42:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160201064234.18702.94255.idtracker@ietfa.amsl.com> Date: Sun, 31 Jan 2016 22:42:34 -0800 Archived-At: Cc: shida@ntt-at.com, webpush-chairs@ietf.org, alissa@cooperw.in, webpush@ietf.org Subject: [Webpush] webpush - Update to a Meeting Session Request for IETF 95 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 01 Feb 2016 06:42:34 -0000 An update to a meeting session request has just been submitted by Shida Schubert, a Chair of the webpush working group. --------------------------------------------------------- Working Group Name: Web-Based Push Notifications Area Name: Applications and Real-Time Area Session Requester: Shida Schubert Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: dispatch httpbis mmusic tram rtcweb appsawg modern core Second Priority: netvc perc stir sipcore Third Priority: clue Special Requests: --------------------------------------------------------- From nobody Sun Jan 31 23:38:15 2016 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04C71B2EDB for ; Sun, 31 Jan 2016 23:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham 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 Z-An4MUNLXlX for ; Sun, 31 Jan 2016 23:38:09 -0800 (PST) Received: from gateway33.websitewelcome.com (gateway33.websitewelcome.com [192.185.145.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AB3E1B2EDA for ; Sun, 31 Jan 2016 23:38:09 -0800 (PST) Received: from cm1.websitewelcome.com (cm.websitewelcome.com [192.185.0.102]) by gateway33.websitewelcome.com (Postfix) with ESMTP id B1199F15606EF for ; Mon, 1 Feb 2016 01:38:08 -0600 (CST) Received: from gator4135.hostgator.com ([192.185.4.147]) by cm1.websitewelcome.com with id Cve71s01G3AKFgo01ve8zd; Mon, 01 Feb 2016 01:38:08 -0600 Received: from c-71-202-231-23.hsd1.ca.comcast.net ([71.202.231.23]:37521 helo=[10.0.96.16]) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aQ93n-000XZs-AB; Mon, 01 Feb 2016 01:38:07 -0600 Content-Type: multipart/alternative; boundary="Apple-Mail=_35AD1EB6-32AE-4E87-9C7A-0AA86F7E55CF" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Shida Schubert In-Reply-To: Date: Sun, 31 Jan 2016 23:38:05 -0800 Message-Id: References: To: Brian Raymor X-Mailer: Apple Mail (2.2104) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source-IP: 71.202.231.23 X-Exim-ID: 1aQ93n-000XZs-AB X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: c-71-202-231-23.hsd1.ca.comcast.net ([10.0.96.16]) [71.202.231.23]:37521 X-Source-Auth: shida@agnada.com X-Email-Count: 2 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Niceness or urgency of messages X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 01 Feb 2016 07:38:13 -0000 --Apple-Mail=_35AD1EB6-32AE-4E87-9C7A-0AA86F7E55CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Brian; I am not brave enough to say, let=E2=80=99s follow HTTPbis footsteps = quite yet. First of all, I don=E2=80=99t think we face the same problem = as HTTPbis is facing which is driving them to experiment with the new = work mode. HTTPbis is working on many different extensions resulting in filling up = people=E2=80=99s mailbox with discussions that are likely irrelevant to = those unrelated. This is especially true for implementors who may be = focused on a specific entity (browser, SDK, proxy, server etc.) in the = HTTP. On the contrary, in webpush, we are working on the core protocol, = although we have 3 drafts that are actively discussed, they are all for = the single milestone (core protocol), so most if not all that are = discussed on the mailing list should be relevant to those interested in = webpush (probably an over simplification, but I hope you get my = point..).=20 I do think github is a fantastic tool to track issues, progresses and = enhance collaboration (through commit/pull-request etc.) and as a result = improve the overall speed of development.=20 After reading your comment, I looked into the difference in number of = participants for the ML / number of watchers on github (Which were quite = significant), I also looked into whether names of the contributors in = both github and ML matches, as we all know the contributors are the real = movers but quite a few names didn=E2=80=99t exist on github. I think for now we need to strike a balance of contributors not having = have to waste their energy keeping the WG in loop but making sure some = of the critical changes discussed on github is distributed on the ML. =20= I do want to encourage the WG participants who are contributing on the = list that are not yet =E2=80=9Cwatch=E2=80=9Ding the issues on github to = do so.=20 Thanks & Regards Shida as co-chair > On Jan 8, 2016, at 5:37 PM, Brian Raymor = wrote: >=20 > =20 > There=E2=80=99s an active conversation occurring today in the = =E2=80=9CNiceness or urgency of messages=E2=80=9D github issue: > =20 > https://github.com/webpush-wg/webpush-protocol/issues/28 = > =20 > I appreciate all the comments and encourage the WebPush WG to review = ... but let=E2=80=99s also bring substantive discussions to the mailing = list. > =20 > Shida and Joe =E2=80=93 would it make sense for the WebPush WG to = adopt the HTTPbis experiment = -http://lists.w3.org/Archives/Public/ietf-http-wg/2015OctDec/0027.html = = - discussion and resolution of issues in the issue tracker itself? > =20 > Thanks, > =E2=80=A6Brian > =20 > =20 > =20 > =20 > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush = --Apple-Mail=_35AD1EB6-32AE-4E87-9C7A-0AA86F7E55CF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hi = Brian;

I am not = brave enough to say, let=E2=80=99s follow HTTPbis footsteps quite yet. = First of all, I don=E2=80=99t think we face the same problem as HTTPbis = is facing which is driving them to experiment with the new work = mode.

HTTPbis = is working on many different extensions resulting in filling up = people=E2=80=99s mailbox with discussions that are likely irrelevant to = those unrelated. This is especially true for implementors who may be = focused on a specific entity (browser, SDK, proxy, server etc.) in the = HTTP. On the contrary, in webpush, we are working on the core protocol, = although we have 3 drafts that are actively discussed, they are all for = the single milestone (core protocol), so most if not all that are = discussed on the mailing list should be relevant to those interested in = webpush (probably an over simplification, but I hope you get my = point..). 

I do think github is a fantastic tool to track issues, = progresses and enhance collaboration (through commit/pull-request etc.) = and as a result improve the overall speed of = development. 

After reading your comment, I looked into the difference in = number of participants for the ML / number of watchers on github (Which = were quite significant), I also looked into whether names of the = contributors in both github and ML matches, as we all know the = contributors are the real movers but quite a few names didn=E2=80=99t = exist on github.

I think for now we need to strike a balance of contributors = not having have to waste their energy keeping the WG in loop but making = sure some of the critical changes discussed on github is distributed on = the ML.  

I= do want to encourage the WG participants who are contributing on the = list that are not yet =E2=80=9Cwatch=E2=80=9Ding the issues on github to = do so. 

Thanks & Regards
Shida as = co-chair

On Jan 8, 2016, at 5:37 PM, Brian Raymor = <Brian.Raymor@microsoft.com> wrote:

 
There=E2=80= =99s an active conversation occurring today in the =E2=80=9CNiceness or = urgency of messages=E2=80=9D github issue:
 
  https://github.com/webpush-wg/webpush-protocol/issues/28
 
I = appreciate all the comments and encourage the WebPush WG to review ... = but let=E2=80=99s also bring substantive discussions to the mailing = list.
 
Shida and = Joe =E2=80=93 would it make sense for the WebPush WG to adopt the = HTTPbis experiment -http://lists.w3.org/Archives/Public/ietf-http-wg/2015OctDec/002= 7.html - = discussion and resolution of issues in the issue tracker itself?
 
Thanks,
=E2=80=A6Brian
 
 
 
 
_______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush

= --Apple-Mail=_35AD1EB6-32AE-4E87-9C7A-0AA86F7E55CF--