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

[Brian Raymor <[e-mail]>]

> (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", can you explain its relevance

in this case? Martin and I reviewed but did not understand

the comment.



> (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/>.



> 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



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



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



----------------------------------------------------------------------

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.