Re: ORIGIN - suggested changes

[Nick Sullivan <[e-mail]>]

I think this is a good change.

I agree with Martin that care has to be taken with respect to the scheme
(http vs https). I don't see any particular reason why this mechanism
shouldn't be restricted to https connections.

I also support the idea that for simplicity the origin list should be
additive only. Reducing the starting set to just the SNI (rather than all
the SANs on the cert, which is problematic due to wildcards) is a sensible
way to eliminate the need for pruning operations.

Nick



On Wed, Feb 1, 2017 at 2:32 PM Martin Thomson <[e-mail]>
wrote:

> Inline.
>
> On 2 February 2017 at 03:42, Ilari Liusvaara <[e-mail]>
> wrote:
> >> You should do something about http:// resources.  This means that this
> >> is a perfect http:// hijacking mechanism.  I don't think that was the
> >> intent.  I would prefer if this were limited to HTTPS, which at least
> >> leaves certificate validation.
> >
> > I thought this mechanism is strictly limited by the normal HTTP/2
> > authoritativeness. Which impiles that it is only usable with
> > certificate validation.
>
> HTTP/2 defines authoritative for HTTP as well as HTTPS (leaning
> heavily on the definitions in HTTP/1.1).  We often fall into the habit
> of thinking that HTTP/2 implies HTTPS, but that's not how the
> specification is written.
>
> > I think server should start with resetting the list with whatever
> > origins it is authoritative for. Especially in case client has some
> > funny ideas about that (e.g. due to wildcard certificates[1]).
>
> My hope is that there should be no need for a reset now that the
> initial set only includes the SNI host.  The server merely has to make
> claims about additional origins.  Once it does so, those funny ideas
> go away.  Especially if ORIGIN can't express wildcards.
>
> > You mean assuming that server can lose authoritativeness over an
> > origin? Because once you assume that, the reset/remove operations
> > folow with relatively little complexity.
>
> The reason that I expect a server would want to disavow an origin
> isn't anything to do with losing authoritativeness, but more with
> operational constraints.  If the server is a gateway to multiple
> back-ends and one of those back-ends wants to shift things around,
> killing all affected connections is feasible, but a blunt instrument.
>
> In any case, I think that this is rare enough not to warrant special
> complexity in the specification to handle. And I mean any complexity
> at all.
>
> If the client determines that the server is no longer authoritative,
> then the client stops sending requests over that connection.  That
> doesn't need any extra signaling.
>
> >> Let's say that if you want to start over, then you really start over:
> >> make a new connection in that case.  The need to remove is greatly
> >> diminished by starting with a very small set.  If you do need to
> >> cleave off an origin after previously advertising it, then ALTSVC is
> >> available and much more graceful than anything this provides.  Removal
> >> - as specified - is still subject to races and therefore violence,
> >> since there is no acknowledgment.
> >
> > The operation is just fundamentially racy, due to finite speed of
> > light. And if you really wanted to (and I this is a bad idea), you
> > could request ACK from client, even if ORIGIN didn't explicitly support
> > ACKs.
>
> That's my point, I don't think that we need to.  Any situation that
> needs to happen immediately can be handled with a 421 (Not
> Authoritative) status code.  For everything else, use ALTSVC.
>
>