Subject: Re: [httpwg/http-extensions] Origin set definition (and port interaction with Alt-Svc) [origin-frame] (#331)

From: HTTP issue updates <[email-masked]>
Date: Sat, 22 Apr 2017 06:42:35 -0700

Thinking about Host more, leaving it as the SNI value may make the most sense, especially as some load balancers may be using the SNI to route to the proper backend server or connection handling context.  (Although this is still "the origin (as per [RFC6454]) that resulted in the successful establishment of the connection".)

This is also an area where #214 could still use some clarifications.  For example, take the case of:

* origin1 returns "Alt-Svc: h2=origin2:443"
* origin1 and origin2 are both covered by the cert at the IP address of origin2
* The server at origin2 receives a connection with SNI=origin1 so the default Origin Set would be "origin1"
* If a client intended to coalesce requests directly to origin2 onto the connection with SNI=origin1, these (origin2) would not be covered by the default Origin Set.

It's not clear that the text from #214 is enough to clarify this case.

That also still leaves the Port issue as a little odd with the Alt-Svc interactions in the current text.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/331#issuecomment-296374150

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 25 Apr 2017 21:21:23 -0700

I'm starting to think it might be best to have the initial origin set be empty, so that all origins added need to be explicit; making the first member "what I think you think it is" is needlessly ambiguous.

The only downside AFAICT is that the common use case "limit it just to the initial origin" now can't be served by sending an empty set; it needs to be explicitly sent.

@mcmanus thoughts?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/331#issuecomment-297233895

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 26 Apr 2017 06:00:19 -0700

On Sat, Apr 22, 2017 at 9:42 AM, Erik Nygren <[email-masked]>
wrote:

> This is also an area where #214
> <https://github.com/httpwg/http-extensions/issues/214> could still use
> some clarifications. For example, take the case of:
>
>    - origin1 returns "Alt-Svc: h2=origin2:443"
>    - origin1 and origin2 are both covered by the cert at the IP address
>    of origin2
>    - The server at origin2 receives a connection with SNI=origin1 so the
>    default Origin Set would be "origin1"
>    - If a client intended to coalesce requests directly to origin2 onto
>    the connection with SNI=origin1, these (origin2) would not be covered by
>    the default Origin Set.
>
>
This is not confusing to me at all, other than for clarity I would not use
the word "origin2" in the Alt-Svc response. Alt-Svc never advertises
origins, just routes (i.e. hostnames) to the transaction's existing origin.
The fact that this hostname might be some other origin's default route is
not relevant (but it is distracting and confusing!)

So I would rephrase the example equivalently as

1] origin1 returns "Alt-Svc: h2=somehost2:443"
2]origin1 and origin2 are both covered by the cert at the IP address of
somehost
3]somehost receives a connection with SNI=origin1 so the default origin set
would be origin1
4] If a client intended to coalesce for origin2 onto the connection with
sni=origin1 from step 3 then these origin2 requests would not be covered by
the default origin set.

That all seems fine and logical to me with the current text. I'm not seeing
the problem. (perhaps the problem is with port? Which is harder.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/331#issuecomment-297399317

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 26 Apr 2017 06:12:11 -0700

On Wed, Apr 26, 2017 at 12:21 AM, Mark Nottingham <[email-masked]>
wrote:

> The only downside AFAICT is that the common use case "limit it just to the
> initial origin" now can't be served by sending an empty set; it needs to be
> explicitly sent.

That is definitely a serious downside - we know from the way servers rolled
out h2 that this kind of TLS/HTTP separation of concerns actually makes it
hard on some of them to know what SNI even was, so they may not be able to
issue that "limit it to SNI" very well if they need to enumerate SNI
explicitly.

But I think the much bigger downside is that you would now have a
psuedo-security property that says a connection can't be used for its
default purpose beyond coalescing - and now ORIGIN is having a much bigger
impact than just coalescing rules which I think is its appropriate scope. I
know in my codebase that would be a significant problem - the coalescing
rules are all centralized but not all dispatch is about coalescing.

Imagine a case where you're connected to the default host for the origin
and receive an empty ORIGIN frame (and we change the rule to be default is
the null set). There is nothing you can do but 1] wait, 2] callback and
race against the ORIGIN Frame, or 3] pretend you didn't read it. All of
those are bad. I think if you handshake for SNI you need to accept requests
for it and its outside the scope of coalescing to change that.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/331#issuecomment-297402730

---

From: HTTP issue updates <[email-masked]>
Date: Sun, 30 Apr 2017 17:53:01 -0700

@enygren any further thoughts? 

I see what you're saying about future SNI masking potentially being an issue; not so sure about DANE, since it's effectively dead in the water. Still, it'd be nice not to have a layer violation here. How about something like 

> the hostname that the connection was established for, converted to lower case; typically the value sent in Server Name Indication ([RFC6066] Section 3)

WRT the port, I don't see a problem; alt-svc does **not** change the origin port.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/331#issuecomment-298268796