Re: [Webpush] AD Review of draft-ietf-webpush-vapid

[Adam Roach <[e-mail]>]

On 6/14/17 02:34, Martin Thomson wrote:
> On 14 June 2017 at 01:21, Adam Roach <[e-mail]> wrote:
>> The first issue I'd like to have clarified regards agility of the crypto
>> suite. This document hard-codes the signing algorithm as ES256. I'm familiar
>> with the fact that documents will frequently do this kind of hardcoding, and
>> then normatively update allowed algorithms in future documents; however, for
>> all such cases I'm familiar with, there is a negotiation involved that
>> allows for bilateral transition from one algorithm to another. For example,
>> RFC7616 was able to include new algorithms because of the challenge/response
>> nature of its authentication scheme. Since VAPID specifically does not
>> include a challenge, application servers have no way of reasonably knowing
>> what the push server might be capable of handling. I think the security
>> section really needs a treatment of how this can be handled, since the
>> obvious solutions with the current design are less than elegant.
> The decision we made here, as with other documents in this series, is
> to define a single profile rather than allow flexibility in the
> scheme.  The rationale for this being that it is better to have fewer
> points of articulation in a protocol and where we already rely on one,
> which is the authentication scheme.  We do have the option to change
> to (for example) Ed25519 by changing the JWT header and tweaking the
> definition of the k= parameter, but I think that the general idea is
> that we would define a new authentication scheme in preference to
> doing that.
>
> As you say, an application server doesn't really have any way of
> determining that the push service supports a given algorithm.  That
> means we need to be very careful about how we signal these things.
> Using the authentication scheme (in this document, "vapid") as the
> extension point means that we can use the existing mechanisms in HTTP
> to signal which scheme is supported if it ever comes to the point
> where we want to or are forced to deploy a new algorithm.

Sure. Can the document say this?

> In this case, that's probably going to depend on the rather ugly 401
> (Unauthorized) status code and a WWW-Authenticate header field.

Yes, that's the "less than elegant" solution I mention above...

> We also have the option of replicating the supportedContentEncodings
> parameter of PushManager in the API
> (https://w3c.github.io/push-api/#pushmanager-interface) so that
> applications might avoid that round trip.

...and that's much better (presuming you intend to *add* something 
rather than shoehorning signature algorithms into a list intended for 
encryption algorithms). Is there anything we can do now to lay the 
groundwork for that?

Basically, what I'm looking to see here is breadcrumbs for whomever 
picks this work up in the future to extend it when ES256 reaches the end 
of its useful life. It sounds like the authors and WG have given some 
thought to the topic, and we can either capture those thoughts or lose them.


>
>> The second issue entails application server key rotation, especially when
>> used without the Subscription Restriction mechanism described in section 4.
>> My reading of the document (and I'll note, as a nit, that this is implied
>> but not particularly explicit) is that the public key used to identify a
>> server is a TOFU token; and that the only means a server has to detect
>> impersonation is verifying that the public key is identical to previous
>> uses. What is the system behavior intended to be when an application server
>> needs to change its VAPID key gracefully; and what is the behavior intended
>> to be when an application server loses its key unexpectedly? For
>> subscription restriction purposes, I can see how servers could just change
>> the key used for the subscription request; but when this mechanism is being
>> used solely for the purposes of continuity of an application server's
>> identity, it seems problematic.
> This isn't TOFU as much as it is a delegated credential.  The server
> designates a sender that can speak for it.  The API ultimately relies
> on server authentication.
>
> The model that the current draft assumes is that an application server
> that wants to roll keys would need to create new subscriptions.  This
> is always possible, though it requires contacting every user agent to
> do so.  See https://github.com/webpush-wg/webpush-vapid/pull/33
>
> We could change the single key to a list of keys, but it would require
> making similar changes to the API.  That would potentially allow
> application servers the option of using updated keys more quickly
> without creating new subscriptions provided that they do sufficient
> preparation (which I suspect is unlikely).  It does change the storage
> models on push services, and I'd be a little cautious about doing so
> given how widely deployed this is already.

For use with Subscription Restrictions, I think it's even easier than 
you propose: if all you're trying to do is ensure that the server is 
authorized to trigger a push, and the way you're doing that is by 
matching the public key from the subscription with the public key in the 
push, then all the application server needs to do is keep track of which 
key is associated with each subscription, and start using a new key for 
new subscriptions. I mean, technically, it could use a different key for 
each subscription and everything would work fine (although the system 
would clearly not scale as well) -- right?. This doesn't bear on the 
protocol, but I agree that it should be described in the security 
section to ensure that both implementors and operators understand what's 
supposed to happen here.

But that's the case I wasn't asking about.

Before I repeat the question, I realize now that perhaps the problem is 
that I'm reading something into the document that wasn't intended. I 
might be able to clear this up with a single yes-or-no question:

Is the application server identification mechanism described in this 
document intended to *ever* be useful WITHOUT using the Subscription 
Restriction mechanism described in section 4?


>
>> Finally, I'm curious about whether there was any discussion regarding the
>> use of "application/json" rather than using the syntax defined by RFC6839
>> (e.g., "application/vapid+json"). My concern is that the use of a
>> semantic-free syntactic designation here makes it more complicated to use
>> push subscription requests for anything *other* than conveying a VAPID key
>> in the future. If the intention is that push subscription bodies generically
>> contain a JSON object with potentially myriad keys for a variety of
>> unrelated purposes, please spell that out clearly (and I would still
>> encourage the use of something less generic than "application/json" even in
>> such a case).
> There was no discussion on this point.  I'm happy to add a new media
> type registration, but I would probably make it a generic push
> subscription options type than restrict it to this narrow use.  My
> initial thought is "application/webpush-options+json", but there's a
> bike shed hidden in there.
>

I don't care about the name, and what you propose is a fine shade for 
this shed. It would be worth noting that future documents may add more 
fields to the schema, and that they will do so by updating this document 
(along with the requisite "ignore fields you don't know" language).

/a