Re: ORIGIN - suggested changes

[Mark Nottingham <[e-mail]>]

> On 1 Feb 2017, at 9:11 pm, Martin Thomson <[e-mail]> 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 <[e-mail]> 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.

Yes. IIRC our final position on this with oppsec was that http can't be coalesced; this doc should reinforce that. We should also point out that this only works on h2, not h2c.


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

Ah, you fell into my carefully laid trap...

I'll adjust the text.


>> 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.
> 
> 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 big use case for this is wildcard certs; origins that use them need a way to say "everything except *those*", which means removal. It also means we need either a wildcard mechanism, or some way to say "everything covered by the cert."

I don't buy the argument that removal itself adds complexity. Implementations already need to remember what origins they received a 421 for, so they already have the concept of origin set removal.


Cheers,


--
Mark Nottingham   https://www.mnot.net/