Re: [Webpush] Stephen Farrell's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT)

[Stephen Farrell <[e-mail]>]

Hi Brian,

Thanks for that. I think only the first point really needs
further discussion so I'll clear the other points in my
ballot.

On 14/10/16 02:54, Brian Raymor wrote:
> 
> 
>> (1) This might just me being confused (in which case,
> 
>> sorry) but I'm not quite clear on how with works with the
> 
>> SOP.  Given you (reasonably) recommend a different port
> 
>> (which is a different origin than 443) are you saying
> 
>> here that the SOP doesn't apply to the client? (Well,
> 
>> actually you don't say, so I'm not sure:-) If the SOP
> 
>> applies, how is the port change handled? If the SOP does
> 
>> not apply, then what does? (Given that I assume some UAs
> 
>> at least will not change their handling of the SOP no
> 
>> matter what we say here.)
> 
> 
> 
> If SOP == "Same Origin Policy", 

Yep.

> can you explain its relevance
> 
> in this case? Martin and I reviewed but did not understand
> 
> the comment.

So what's not clear to me is how webpush works with the SOP
and whether there's anything more that needs to be said about
that in the document. For example, you sensibly recommend
running the push service on port 1001 but none of the examples
mention that port in the Host or :authority values shown.

This may all be clear to someone who's very familiar with
alt-svc though, (but it wasn't clear to me:-), which might
be fine, but I'm not sure. As an example, is the application
that is pushing the messages required to know that the
push service is or is not using port 1001?

> 
> 
> 
>> (2) So-called "capability URLs" (is that a new term here?
> 
> 
> 
> There's a CAP-URI reference:
> 
> 
> 
>    [CAP-URI]  Tennison, J., "Good Practices for Capability URLs", FPWD
> 
>               capability-urls, February 2014,
> 
>               <http://www.w3.org/TR/capability-urls/>.
> 

Ah, thanks I missed that.

> 
> 
>> seems like it could be the topic for a useful
> 
>> informational rfc) are clearly weak, but also clearly as
> 
>> good as we'll get for some things.  However, those also
> 
>> become known over time, (in which case they are toast;-)
> 
>> so why don't you need to provide a way for a push service
> 
>> to say "hey, instead of <this-URL> in future you'll need
> 
>> to use <that-URL>"? If that could be done as an extension
> 
>> later, then I'd be ok with that in terms of clearing the
> 
>> discuss, but then I think you'd need to mention it, so
> 
>> that applications and UAs don't build in an assumption
> 
>> that these URLs are fixed for all time (while also
> 
>> needing to be kept "secret" as with other bearer tokens).
> 
> 
> 
> These URI(s) are not fixed for all time. The expectation is that
> 
> subscriptions will either be explicitly expired by the push service/user agent
> 
> as necessary or refreshed.
> 
> 
> 
> For example:
> 
> 
> 
> https://tools.ietf.org/html/draft-ietf-webpush-protocol-11#section-7.3
> 
> 
> 
>    In some cases, it may be necessary to terminate subscriptions so that
> 
>    they can be refreshed.  This applies to both push message
> 
>    subscriptions and receipt subscriptions.
> 
> 
> 
>    A push service MAY expire a subscription at any time.  If there are
> 
>    outstanding requests to an expired push message subscription resource
> 
>    (Section 6) from a user agent or to an expired receipt subscription
> 
>    resource (Section 6.3) from an application server, this MUST be
> 
>    signaled by returning a 404 (Not Found) status code.
> 
> 
> 
> To further illustrate, this is how the W3C Push API exposes this feature:
> 
> 
> https://w3c.github.io/push-api/#the-pushsubscriptionchange-event

Ah good. Does that also specify a way for the application to
change the URL to which it pushes? It's the latter that I
think is the bigger potential danger. (In any case, I'll clear
this point.)

> 
> 
>> (3) Why is it not correct to encourage mutual-auth TLS
> 
>> for the application to push-service connections?  I'm not
> 
>> arguing to make that mandatory, but it's not that hard in
> 
>> many cases and is very useful, esp since without some
> 
>> client auth just knowing the URL will often enable a
> 
>> sender to send a crap load of updates to possibly many
> 
>> bandwidth/power-challenged UAs. (This is only a discuss
> 
>> because of that potential DoS vector.)
> 
> 
> 
> Martin presented a range of alternatives in an earlier version of vapid:
> 
> 
> 
> https://tools.ietf.org/html/draft-thomson-webpush-vapid-01#section-2
> 
> 
> 
> which resulted in many discussions on the mailing list, such as:
> 
> 
> 
> https://mailarchive.ietf.org/arch/msg/webpush/oPK2Bk1bsNE8Tb-YLGz4gZAIg7o
> 
> 
> 
> The current version of vapid is the outcome of working group consensus.
> 

Ah, ok I didn't know that the vapid thing had a signature
based HTTP auth scheme. That's good enough. (I'll be
interested in the replay charactistics of vapid auth when
that gets to the IESG though, seems a bit ickky to me if
I can cut'n'paste such signatures for 24 hours worth of
fun. But that's a discussion for another day.)

It's also pretty sad that "cloudy" services can't depend
on visibility of TLS client auth information. But I guess
that's not something that this document can fix.

> 
>> (4) Is it really honest to say that the W3C Push API,
> 
>> webpush encryption and vapid are only informative
> 
>> references? The first seems easy to make normative, the
> 
>> second I think really needs to exist before we ought
> 
>> recommend this all get out into the wild and I'm not
> 
>> clear if one could sensibly make a service for this
> 
>> without the 3rd. Yes that might add some delay to the RFC
> 
>> being issued, but that might be the right thing to do.
> 
>> Why is it right to not wait on those two IDs and the w3c
> 
>> rec? This is mainly a discuss in case the answer is "we
> 
>> know nobody's gonna do webpush-encryption ever" in which
> 
>> case I'd like to be convinced that implementing and
> 
>> deploying based on this draft without reading those
> 
>> references defines a good standard. I'm not saying that
> 
>> it does not, I'm saying I'm not yet convinced.
> 
> 
> 
> WebPush is similar to WebSockets in the sense that there's a related API under
> 
> development at the W3C. I'd note that RFC6455 uses an informative reference
> 
> to the W3C WSAPI. The expectation is that there will be multiple API surfaces for
> 
> WebPush similar to the situation for WebSockets.
> 
> 
> 
> WebPush includes informative references to vapid and message encryption as
> 
> examples. In response to comments from Ben Campbell during the review, Martin
> 
> created a pull request which clarifies this:
> 
> 
> 
> https://github.com/webpush-wg/webpush-protocol/pull/138/files
> 
> 
> 
> The consensus in the working group was that other implementations/scenarios outside
> 
> the browser (such as IoT) would pursue their own approaches to address the requirements.
> 
> 

Ok. Given that I'm assured that the encryption stuff is
really happening, I'm fine with this.

> 
> ----------------------------------------------------------------------
> 
> COMMENT:
> 
> ----------------------------------------------------------------------
> 
> 
> 
>> - Thanks for the MUST use TLS. That's totally necessary
> 
>> here. (Even if maybe not sufficient:-)
> 
> 
> 
>> - I just want to check this is correct: I think it'd be
> 
>> potentially useful to be able to pad the traffic here
> 
>> with NOOP pushed messages.
> 
> 
> 
> <snip>
> 
> 
> 
> Applications could absolutely choose to do this if the
> 
> benefits outweighed the costs.
> 
> 
> 
>> - section 6: (A nit) I think this could be clearer if you
> 
>> better explained how the subscriptions and push messages
> 
>> are correlated. While the current text is fine, since
> 
>> it's clear eventually from the examples, it might be
> 
>> better to not assume so much familiarity with h2.
> 
> 
> 
> The tension is that WebPush is basically an "application" of
> 
> server push which requires some familiarity with HTTP/2.

Sure. And this is just a non-blocking comment, but a bit
more text on that would have helped this reader. But if
you've not also heard the same from others, you should
ignore me:-)

Cheers,
S.


> 
> 
> 
>