Origin set definition (and port interaction with Alt-Svc) #331
Comments
|
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:
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. |
|
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? |
|
On Sat, Apr 22, 2017 at 9:42 AM, Erik Nygren ***@***.***> wrote:
This is also an area where #214
<#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.)
|
|
On Wed, Apr 26, 2017 at 12:21 AM, Mark Nottingham ***@***.***> 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.
|
|
@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
WRT the port, I don't see a problem; alt-svc does not change the origin port. |
mnot
changed the title
|
This seems to have turned editorial (as Erik originally suggested). Erik, if you can make specific proposals on what needs to be changed, that would be helpful. |
|
Take a look at #348 for my take on this. |
|
That worked out well - thx mt. |
Some potential (editorial?) issues with the Origin Set definition (Section 2.3):
For Host we may wish to use a better term than "the value sent in Server Name Indication". In particular, this could cause problems in the future for any SNI-masking work. This also has potentially weird interactions with DANE as it specifies that the SNI should be the terminal CNAME or SRV record target.
For Port, there is a weird interaction with Alt-Svc. In particular, the server's port may be different than the port of Origin. For example, an Alt-Svc for https://www.example.com to alt.example.com:8443 still has the origin of https://www.example.com:443 but given the current wording would have the incorrect initial origins set of https://www.example.com:8443
Would it be better to have the implicit initial Origin Set from a client's perspective (when an ORIGIN frame is first received) be "the origin (as per [RFC6454]) that resulted in the successful establishment of the connection" ?
This is ambiguous from the servers' perspective but perhaps much cleaner and simpler from the client's perspective.
Another ambiguity: if a 421 is received for the last origin in the Origin Set, does it become empty or return to uninitialized? (Should we clarify the former, and that clients may wish to soon close out the connection if no new origin additions are received soon?)
The text was updated successfully, but these errors were encountered: