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

From: Brian Raymor <[email-masked]>
Date: Fri, 14 Oct 2016 01:54:55 +0000

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 14 Oct 2016 16:02:57 +0100

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:
> If SOP == "Same Origin Policy", 

Yep.

> can you explain its relevance
> 

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?

>               <http://www.w3.org/TR/capability-urls/>.

Ah, thanks I missed that.

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

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

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

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.

---

From: Brian Raymor <[email-masked]>
Date: Fri, 14 Oct 2016 20:00:39 +0000

Hi Stephen,

> push service is or is not using port 1001?

Alternative services have not been a source of confusion in the working group.
There have been no related questions on the mailing list that I can recall or find.

The SOP question feels more relevant to RFC7838 than WebPush (hence our confusion
yesterday).

Perhaps excerpting a few references will help clarify that perception:

   https://tools.ietf.org/html/rfc7838

   An alternative service can be used to interact with the resources on
   an origin server at a separate location on the network, possibly
   using a different protocol configuration.  Alternative services are
   considered authoritative for an origin's resources, in the sense of
   [RFC7230], Section 9.1 ...

   Alternative services do not replace or change the origin for any
   given resource; in general, they are not visible to the software
   "above" the access mechanism.  The alternative service is essentially
   alternative routing information that can also be used to reach the
   origin in the same way that DNS CNAME or SRV records define routing
   information at the name resolution level ...

   This means that clients using an alternative service can change the
   host, port, and protocol that they are using to fetch resources, but
   these changes MUST NOT be propagated to the application that is using
   HTTP; from that standpoint, the URI being accessed and all
   information derived from it (scheme, host, and port) are the same as
   before.

   Importantly, this includes its security context; in particular, when
   TLS [RFC5246] is used to authenticate, the alternative service will
   need to present a certificate for the origin's host name, not that of
   the alternative.  Likewise, the Host header field ([RFC7230],
   Section 5.4) is still derived from the origin, not the alternative
   service (just as it would if a CNAME were being used).

Also see mnot's blog for a quick introduction:

https://www.mnot.net/blog/2016/03/09/alt-svc

    So, to use an alternative, a client needs to have what we call “reasonable assurances”
    that it has the authority to do so. In this specification, we define one way to do that;
    the alternative needs to present a TLS certificate that’s valid for the origin
    – not the alternative! – hostname.

Hope that helps,

...Brian

---

From: Brian Raymor <[email-masked]>
Date: Mon, 17 Oct 2016 07:03:19 +0000

Correcting a mail bounce. Apologies for duplicates.

Take two.

> push service is or is not using port 1001?

I've added a clarification to Section 1.1 regarding the examples in the
document - outlining the minor changes required if Alt-Svc was in play:

https://github.com/webpush-wg/webpush-protocol/pull/141/files

The small difference is the inclusion of the Alt-Used header field in the user agent 
requests to the push service. No other changes (such as URLs) are required which 
matches the description in RFC7838: '...  in general, they are not visible to
the software "above" the access mechanism. ' The "routing" is transparently
managed in the HTTP stack based on my understanding. 

Similarly, the application server is NOT required to know that the push service and
user agent are using port 1001. 

...Brian

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Oct 2016 08:13:32 +0100

> user agent are using port 1001. 

Thanks. I think I've tracked down the source of my confusion
which isn't quite the above (though that does seem like an
improvement).

In section 3 it says:

  "The push service shares the same
   default port number (443/TCP) with HTTPS, but MAY also advertise the
   IANA allocated TCP System Port 1001 using HTTP alternative services
   [RFC7838]."

I think the MAY there is what got me into a confused state.
Say if a UA knows to use port 1001 on example.net and just
goes there, then the UA will treat the content as having the
origin example.net:1001. If however the UA goes to example.net
on port 443 first and then sees an alt-svc, then when it goes
to port 1001 it'll treat the content as having origin just
example.net. I guess that'll make a difference in how the UA
handles pushed content.

And I think what's different here, compared to a generic
use of alt-svc, is that port 1001 is being registered so
it's more likely a UA goes directly there the very first
time and never hits 443.

Seems to me that may mean there's a missing bit of text
warning of that, and perhaps a missing bit of text that
push services would be wise to advertise the port 443 URLs
to which a UA can subscribe and then use alt-svc to schlep
UAs over to port 1001. (And maybe that means that the
text about "advertising the alternate port (1001)"
could also do with a change?)

Does the above sound right? Or am I still confused? :-)

Cheers,
S.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 17 Oct 2016 21:04:40 +1100

On 17 October 2016 at 18:13, Stephen Farrell <[email-masked]> wrote:
> example.net.

Correct.  That is a good summary of how Alt-Svc interacts here.

> I guess that'll make a difference in how the UA
> handles pushed content.

Actually it won't because it doesn't treat the content it retrieves as
belonging to a particular origin.  The information that is received is
handled by the UA (not any application that resides in it, in the case
of a browser).

As a browser, with origins and all that business, we don't actually
treat content as subject to SOP until we've received the push message,
decrypted it, and actually handed it to the origin.  Because the
content we receive from a push service rightfully belongs to many
origins, we have to treat it specially.

The push service is aware of its role in this, so we don't need to ask
special permission to share either.  It did implement the protocol
after all.  Thus, the data we source there isn't treated as
cross-origin.

We do exactly the same for the geolocation API when we get a location
from a server.

(I could also explain how you can follow the crypto and see that the
data isn't cross-origin at all, but that would be just sophistry.)

Either way, I believe that what you are asking for rightfully belongs
in the API part, since we're trying to make the protocol pieces
ignorant of all that disgusting browser gunk.  Happy to add something
as editor of the API pieces, but not entirely sure what.  It's strange
because it's entirely too obvious to me to the point that I didn't
really know what you were on about, but then you are right that we
never actually write this stuff down.  Opened
https://github.com/w3c/push-api/issues/211

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Oct 2016 15:40:21 +0100

Hiya,

> origins, we have to treat it specially.

Saying that would've definitely helped me understand
what's going on. Does something need to be stated in
this draft? Or is it safe enough to assume that the
reader will also look at the API and encryption drafts,
and that people won't come up with other ways to handle
pushed messages that don't support good ways to
enforce the SOP?

Cheers,
S.

---

From: Brian Raymor <[email-masked]>
Date: Tue, 18 Oct 2016 04:14:18 +0000

Hi Stephen,

> Saying that would've definitely helped me understand what's going on.

Sorry about that. It required a few iterations for us to understand, but we got there.

> Does something need to be stated in this draft? 

Martin and I have reviewed and are in agreement that
further clarifications would not be helpful in the protocol draft.

> Or is it safe enough to assume that the

Exactly. This is more relevant to the Push API / W3C which Martin
is now tracking in https://github.com/w3c/push-api/issues/211. 

And our experience is that developers are consuming all the related
drafts. We had some new members during WGLC who demonstrated
this point with their contributions.

This was definitely a subtle discussion. We appreciate that your review
called this out for consideration. 

...Brian

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Oct 2016 09:43:45 +0100

Hiya,

We're nearly there...

> this point with their contributions.

So doesn't that argue to make the relevant drafts normative
references? That's not meant to be a blocking comment btw,
I'm ok with the RFC having those as informative (modulo my
last question below) but think it'd be better if they were
normative.

> called this out for consideration. 

I've just one last thing to ask before we're done:

Do we envisage anyone ever using this push service mechanism
without the content of the message being as defined in the
webpush encryption draft and without following the W3C API?

If we do, and if that content ends up in a browser or other
application that needs the SOP or similar, then I'm still not
sure it's ok to say nothing in this draft.

If we do not, then it'd seem sensible to add a statement to
the effect that all these things are really a package and
it's not necessarily safe to just use this piece alone.

Cheers,
S.

---

From: Brian Raymor <[email-masked]>
Date: Tue, 18 Oct 2016 23:21:33 +0000

Hi Stephen,

>> last question below) but think it'd be better if they were

Not at all - and frankly that would subvert consensus in the working group.
We created vapid and message encryption as separate drafts because they’re optional.
The normative references occur in the W3C Push API. For WebPush,
the other drafts demonstrate one approach that might not be appropriate
for other scenarios but are included for awareness.

As I wrote in an earlier response:

> webpush encryption draft and without following the W3C API?

Absolutely. As I wrote in an earlier response:

For example, one co-author (Elio) has scenarios in the IoT space. No browser involved.

> sure it's ok to say nothing in this draft.

I'm not suggesting that there will be multiple API(s) in the browser-case.
The expectation is the web developers will use the W3C Push API or
a framework based on the Push API. SOP is very browser-specific and
there’s already a solution in this case. 

Cheers,
...Brian

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Oct 2016 12:54:03 +0100

Hiya,

On 19/10/16 00:21, Brian Raymor wrote:
>  SOP is very browser-specific and

That's a fair point.

While I don't agree that being silent here is right,
that's not a good enough reason to continue to block
this. (*)

So I'll clear now.

Thanks for the discussion,
Cheers,
S.

(*) I assume you do not want to add something, but
if you did, then my suggestion would be along the
lines of "Applications using this push mechanism
are likely to need additional security mechanisms
to produce an overall useful system, e.g. when the
UA is a browser, then the SOP needs to be enforced,
which can be achieved via [refs]. Other applications
using this mechanism may require similar kinds of
higher level security mechanism over and above
what is defined here."