Subject: Re: [Webpush] Voluntary Application Server Identification -02

From: Peter Beverloo <[email-masked]>
Date: Mon, 1 Feb 2016 18:43:08 +0000

Thank you for publishing the draft, Martin!

While I'm not sure how much significance it carries since I'm listed as an
editor, I do of course support the draft as the resolve to Issue 44.

Server authentication and subscription association are important problems
to us, and, pending any further feedback from the working group, we plan to
adopt the proposed solution in our implementations.

Thanks,
Peter

On Mon, Feb 1, 2016 at 1:56 AM, Martin Thomson <[email-masked]>
wrote:

> 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
>
> _______________________________________________
> Webpush mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webpush
>

---

From: Costin Manolache <[email-masked]>
Date: Mon, 1 Feb 2016 12:33:45 -0800

+1

Costin

---

From: JR Conlin <[email-masked]>
Date: Wed, 10 Feb 2016 14:30:04 -0800

While talking with Kit, I'd like to present a set of rules (I was going
to call them best practices, but really, that's like saying "Do not lick
high voltage lines" is a best practice.)

1) If a site registers a public key as part of a subscription request,
that key is used to validate the JWT. Invalid JWTs result in a 401.

2) If a site registers a public key, it should NOT include the public
key as part of the Crypto-Key header in the Push request (since this
increases the chance that the key is inadvertently disclosed.)
I'm not sure how or if we should signal that back to the App Servers.

3) If the Crypto-Key:p256ecdsa == Crypto-Key:p256dh, that will return a
401. (it's just math kids, you can pick different coordinate sets, for
free.)

Seem reasonable?

On 2/1/2016 12:33 PM, Costin Manolache wrote:
> +1
>
> Costin
>
> On Mon, Feb 1, 2016 at 10:43 AM, Peter Beverloo <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     While I'm not sure how much significance it carries since I'm
>     listed as an editor, I do of course support the draft as the
>     resolve to Issue 44.
>
>     Server authentication and subscription association are important
>     problems to us, and, pending any further feedback from the working
>     group, we plan to adopt the proposed solution in our implementations.
>
>     Thanks,
>     Peter
>
>     On Mon, Feb 1, 2016 at 1:56 AM, Martin Thomson
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Costin Manolache <[email-masked]>
Date: Wed, 10 Feb 2016 22:25:56 -0800

On Wed, Feb 10, 2016 at 2:30 PM, JR Conlin <[email-masked]> wrote:

> While talking with Kit, I'd like to present a set of rules (I was going to
> call them best practices, but really, that's like saying "Do not lick high
> voltage lines" is a best practice.)
>

Not sure I understand - the register() call takes a public key, and the
push service needs to verify that the send request
includes a JWT token with the same key - is that what you mean ?

>
> 2) If a site registers a public key, it should NOT include the public key
> as part of the Crypto-Key header in the Push request (since this increases
> the chance that the key is inadvertently disclosed.)

The key used in register() needs to be included in the push request -
technically we can work around this, by having the
push service store the key - but by having it in the push header it can
reduce the storage ( the push service can
only store a hash of the key, or can include a hash of the key in the
registration token, so no storage - assuming the registration is
encrypted/signed).

It's a public key - why would it be a problem in disclosing it ? Anyone who
cares can get it from the browser making
the subscribe request, it's more or less as secure as the public key in the
TLS cert.

Costin

>> While I'm not sure how much significance it carries since I'm listed as
>> an editor, I do of course support the draft as the resolve to Issue 44.
>>
>> On Mon, Feb 1, 2016 at 1:56 AM, Martin Thomson <
>> <[email-masked]>[email-masked]> wrote:
>>
> Webpush mailing [email-masked]://www.ietf.org/mailman/listinfo/webpush
>
>
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 11 Feb 2016 21:41:36 +1100

> registration token, so no storage - assuming the registration is

Yes, I have this in the draft actually: (see the editor's note here:
https://martinthomson.github.io/webpush-vapid/#using-restricted-subscriptions)

I am absolutely OK with rejecting idiot attempts to use the same EC
key for key exchange and signing.  That I am happy to put in the draft
with a MUST on it.

Like Costin, I'm confused about the need to restate the first point.
The whole purpose of including a key in the subscription is to limit
pushes to application servers that have the corresponding private key.
See https://martinthomson.github.io/webpush-vapid/#using-restricted-subscriptions
and https://github.com/w3c/push-api/pull/182

---

From: Martin Thomson <[email-masked]>
Date: Thu, 11 Feb 2016 21:49:04 +1100

> key for key exchange and signing.  That I am happy to put in the draft

And lo, I have created a request to pull thus:
https://github.com/martinthomson/webpush-vapid/pull/6

(OK, it's late)

---

From: jr conlin <[email-masked]>
Date: Thu, 11 Feb 2016 08:52:23 -0800

> and https://github.com/w3c/push-api/pull/182

I tend to prefer limiting the amount of data exchange required. Since
the Crypto-Key component would match the previously provided register()
key, it seemed redundant to provided it on every subsequent call. Having
discussed things with Ben and Kit offline, I'm fine with the public key
being included in both, in order to make things easier for the
Application server creators.