Re: [Webpush] Application server authentication new years edition

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
>