W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

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

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 7 Oct 2016 11:38:53 +1100
Message-ID: <CABkgnnW1apAyVqxPMi+_i-WH07Pe13JZ+eNNbUpGvFOyHpq7HQ@mail.gmail.com>
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Patrick McManus <mcmanus@ducksong.com>, HTTP working group mailing list <ietf-http-wg@w3.org>
On 7 October 2016 at 05:12, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
> Okay, so we are basically trying to backfill a possible administrative mistake by verifying that the server processes scheme as part of origin.  So an administrator MUST BUT WE KNOW YOU WON'T only put this resource in place if their server is properly configured to handle a scheme inconsistent with the port.  After they already have to opt in by sending the Alt-Svc header on the origin in the first place.  I'm lacking confidence that this check actually assures anything except that the administrator wants it to work, and we already know that from the Alt-Svc header.

There's one very important difference: the .well-known response is
authenticated.  An attacker can forge an Alt-Svc header.

And in any case, if the administrator lies, they are at least taking
responsibility for the error, that's important too.

The MUST NOT exist for the https:// variant is a neat trick, and it
would increase confidence, but I don't think that it proves anything
other than the fact that THAT specific resource is handled correctly
(as you know, much of this can hinge not on the generic code in the
server, but on code specific to a resource).
Received on Friday, 7 October 2016 00:39:25 UTC

This archive was generated by hypermail 2.3.1 : Friday, 7 October 2016 00:39:28 UTC