Re: [Webpush] Application server authentication new years edition

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 <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.
>
> 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 <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:  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
>
>