Subject: Re: [Webpush] Authenticating senders

From: Paul Em <[email-masked]>
Date: Wed, 10 Jun 2015 21:24:50 +0200

Now that I read more about SMTP techniques I also think we could use parts
of this approach, but in a slightly different way.
By checking SPF records SMTP checks if the sender is allowed to send
messages.
We could do the same, but instead of using DNS records all allowed senders
could be specified in, for example, the manifest.json, similar to CORS.
The push service can, but does not have to, check if the sender is valid
and use the ip or hostname of the sender as
unique sender.

Of course this would only work if the sender uses https and has a valid
signed cert to ensure the right sender.
With this approach a compromised server would not have to fear that someone
else can use the compromised urls to spam.

I am not sure if and how this would work with the example of amazon cloud
though.

Further comments below.

2015-06-09 20:43 GMT+02:00 Costin Manolache <[email-masked]>:

> On Tue, Jun 9, 2015 at 10:18 AM, Martin Thomson <[email-masked]>
> wrote:
>
>> On 8 June 2015 at 23:09, Costin Manolache <[email-masked]> wrote:
>> > I'm talking about the 'application server' - typically the same with the
>> > https origin, where apps running in the UA send their subscription.
>> > I wouldn't call it 'client'.
>>
>> I too was talking about the application server.  And it is absolutely
>> a client in this context.
>>
>
> Then let's avoid using 'client' and 'server'.
>
> How about 'origin' or "machine operated by application developer' (the app
> server can be operated by
> another organization - but it is the decision of the app developer on
> where he will send/share the capability
> URL)
>
> To be clear: if the message is sent by a user - in case of 'device to
> device' for example, which webpush
> doesn't cover - I wouldn't expect any identifiable information about the
> user. We'll still need to
> identify the sender ( so a response can be sent for example ) - and we
> still need this to be verified, to avoid
> abuse. This is a separate issue, no point talking too much about it.
>
> While both regular users and web site developer initiate client http
> connections to webpush service -
> there are still some differences between a company/organization and an end
> user.
>
>
>> > I'm not very familiar with WebRTC - does it now include any part where
>> you
>> > would get rings or messages from unidentified sources ?
>>
>> Yes.  Unless you are able to use the extra authentication piece (which
>> only Firefox currently implements).
>>
>
> I'll read about it - do you have any pointers ? I see they have a section
> on identity - and it
> doesn't seem to require that UA/apps accepts un-identified messages.
>
> I can't find any definition of a new signaling mechanism - which would be
> the equivalent of
> webpush, what I found still references SIP or XMPP - which both identity
> and check the sender.
>
>
>> >> Either way, I wouldn't want the push service having access to origin
>> >> information without the origin choosing to add that information.
>> >
>> >
>> > I don't think it is feasible to run a service where servers generating
>> 1000s
>> > of QPS
>> > of messages are unidentifiable to the network operator.
>>
>> Make no mistake, I have no illusions about that sort of case needing
>> authentication.  And at higher numbers, exceptions have to be made.  I
>> was expecting that to be exceptional though.
>>
>
> I don't know what other webpush operators will do - my strong requirement
> is to have a verifiable identity for the sender - can be a random number.
> I would also like to see a definition of optional contact elements (email
> or domain)
> - but I think we may accept at least low QPS without contact info.
> Current GCM requires an dev account which requires an email - so far in
> the cases
> we had to contact the developers we didn't run into problems finding them.
>
> For very high numbers it's probably less important - there are more
> channels of communication with large developers, and they're more likely
> to contact the webpush service first. Which reminds me that we should also
> define some link to a webpush contact info.
>
>
>
>> > I think inventing a mechanism that provides privacy for servers is very
>> hard
>>
>> I always imagined that pushes could come from anywhere, not just the
>> machine that serves the front-end for a site. The opposite in fact, I
>> would expect that pushes will come from elsewhere, like the back-end
>> that is reacting to the event as it happens. If pushes are originating
>> from (for example) somewhere in Amazon's cloud, that's going to give
>> the server pretty good anonymity. At least without asking Amazon to
>> trace the IP, anyway.
>>
>
> See above - pushes could come from any machine operated or delegated
> by the organization controlling the 'origin', not only the frontend.
>
> Requests 'coming from anywhere' are the root problem I'm trying to solve
> :-),
> if the capability URL gets out of machines operated by the developer, like
> it
> happens to email addresses.
>
>
The approach I described above would solve the problem of having requests
'coming from anywhere',
but of course the origin would be given away to the push service.
Martin wrote before that he wouldn't want the push service having access to
origin information.
I don't fully understand the problem here - doesn't the push service see
the origin
regardless if I want it or not? What do I miss here? And if not, how would
this be a problem?

>
>
>>
>> > Actually - I never heard of any shared cookie jar that would operate
>> well in
>> > a distributed
>> > server environment. How would Set-Cookie be implemented if you have
>> senders
>> > in different continents, with high latency between them ?
>>
>> Like any other piece of shared state.  I wouldn't imagine that it
>> would be any harder than sharing a key, or any other common
>> authentication information.
>>
>
> In many authentication schemes each machine ( or region ) can get or
> generate it's own
> tokens - without requiring consistency or synchronization with other
> regions.
> And since you mentioned we don't want to invent new authentication -
> cookies are not
> typically an authentication mechanism ( they are just used to track
> sessions that are used by
> various auth schemes ).
>
> Costin
>
>
Paul

---

From: Martin Thomson <[email-masked]>
Date: Wed, 10 Jun 2015 12:51:17 -0700

On 10 June 2015 at 12:24, Paul Em <[email-masked]> wrote:
> The push service can, but does not have to, check if the sender is valid and
> use the ip or hostname of the sender as
> unique sender.

It might make a little sense to uplevel the discussion here.  Recall
that we're actually in a situation where an application is talking to
itself.

The analogues with SMTP aren't all applicable in this context if you
consider that the destination address is essentially secret.

> I don't fully understand the problem here - doesn't the push service see the
> origin

The push service doesn't need to know the origin.  It might *want* to
know the origin for all the reasons Costin has articulated, and it
might make sense to provide the origin in some cases for those
reasons.  But fundamentally the push endpoint is all the information
it needs to deliver the message to the right place.

That doesn't mean we can't add extra capabilities.  But I'd prefer to
at least reach the point where we have something that minimally works
first.

---

From: Paul Em <[email-masked]>
Date: Wed, 10 Jun 2015 22:30:59 +0200

> consider that the destination address is essentially secret.

Apologies if I am completely wrong here and i will try to explain it a bit
better, otherwise
I will stop writting nonesense, i promise ;-)

Yes the app is talking with itself in the end, but when putting the
information about valid senders
in the manfiest this information can be sent to the push service when
subscribing and stored there.
So the push service knows all allowed senders for a registration and can
check this if
needed.

The destination address (you mean the endpoint, right?) can be "secret",
but you still talk
to same one from view of UA and from the "machine operated by application
developer'.

> the

---

From: Martin Thomson <[email-masked]>
Date: Wed, 10 Jun 2015 13:51:09 -0700

> I will stop writting nonesense, i promise ;-)

I'm not reading nonsense, but you can rely on me telling you if I do.

> So the push service knows all allowed senders for a registration and can

I'd rather not rely on manifests for this.  If we need this, we can
put it in the API.  We would also need to have the browser tell the
push service about these constraints at the same time.  Any reluctance
there on my behalf is reluctance to do all that work. Not because
specifying it is hard, but because it raises the bar for
implementations.

> The destination address (you mean the endpoint, right?) can be "secret", but
> you still talk

Only the "mobad" sends to the endpoint.