Re: Empty but existing resource | Re: SETTINGS_MIXED_SCHEME_PERMITTED | Re: I-D Action: draft-ietf-httpbis-http2-encryption-07.txt

Fair enough that the Alt-Svc could have been inserted by an attacker that knows that particular server is scheme-insensitive and wants to provoke whatever the misbehavior is.  Validating the agreement over TLS for that reason makes more sense to me.  I still would argue that client SHOULD check for this (not MUST) simply because a client could follow the Alt-Svc header without checking .w-k and be perfectly compliant with RFC 7838.  The client isn't requesting additional functionality via Opp-Sec, but gaining a way to double-check the alternative's intent/ability to play along when the initial reference was vulnerable to meddling.  (Unless we're proposing to update RFC 7838 by adding that MUST?)

While I certainly grant that it's possible for apps above the server layer to handle this incorrectly as well, I think a lot of that gets mitigated if the server layer properly tells the app that the requested URL was http://example.com.  (I believe ours actually overrides the scheme as presented, so an app basically never has the chance to get it right.)  While apps are endlessly creative in ways to get things wrong, your odds are at least much better if the server is capable of delivering the correct requested URL to the application.
________________________________
From: Martin Thomson <martin.thomson@gmail.com>
Sent: Thursday, October 6, 2016 10:11:37 PM
To: Kari Hurtta
Cc: Mike Bishop; Patrick McManus; HTTP working group mailing list
Subject: Re: Empty but existing resource | Re: SETTINGS_MIXED_SCHEME_PERMITTED | Re: I-D Action: draft-ietf-httpbis-http2-encryption-07.txt

On 7 October 2016 at 15:21, Kari Hurtta <hurtta-ietf@elmme-mailer.org> wrote:
> I do not not like existing but empty resource test.
>
> I have seen some instructions (for load balancer)
> that how to convert http 404 to http 200 with empty page
> (or response).

Then insist on it being text that includes the origin.