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

[Brian Raymor <[e-mail]>]

Hi Stephen,

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

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