Re: ORIGIN - suggested changes

On Wed, Feb 01, 2017 at 09:11:57PM +1100, Martin Thomson wrote:
> These seem like good changes in principle.  I've left a few comments
> on the PR that say much the same as below...
> 
> On 1 February 2017 at 17:50, Mark Nottingham <mnot@mnot.net> wrote:
> >   - Removes the requirement for a supporting client to check DNS
> to determine if the server is authoritative, when ORIGIN is received
> 
> 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. 

> >   - Redefines the initial Origin Set as whatever SNI included (if anything).
> 
> If you do support this feature, the second change leads to having no
> valid origins initially if you don't use SNI.  It also could be read
> to prohibit coalescing as we do today.  Presumably the set is whatever
> we have today until you see an ORIGIN frame.  You should probably say
> something about that.

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

> > Some people have also been talking about simplifying ORIGIN, e.g.,
> > by removing some of the set operations. I think we should talk about
> > that on list first.
> 
> Let me put my stake in the ground.
> 
> The current design is just a little too complicated.  The ability to
> clear the set and remove from the set is where a lot of that
> complexity comes from.

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.
 
> 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 just leaves the frame being able to add origins to the set that a
> client might consider using.  That's pretty easy to manage.  Anything
> you have ever seen in an ORIGIN frame is a candidate.  Servers can add
> to the set any time they like (likely in response to serving content
> that references other origins), and clients can choose to forget
> origins if the list ever gets too long for them to manage.



[1] The use of those, in contexts where this is hazardous might increase
in te future, thanks to Chrome planning to require Certificate Transparency
and having no explicit redaction mechanism. Which leaves wildcard
certificates as the only option to redact anything.


-Ilari

Received on Wednesday, 1 February 2017 16:43:06 UTC