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

Martin Thomson <> Thu, 06 October 2016 00:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8024F1294FB for <>; Wed, 5 Oct 2016 17:40:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.517
X-Spam-Status: No, score=-9.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WhYctiFvb5iW for <>; Wed, 5 Oct 2016 17:40:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A0FBB1294F1 for <>; Wed, 5 Oct 2016 17:40:05 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1brwf2-0001Qb-8g for; Thu, 06 Oct 2016 00:35:44 +0000
Resent-Date: Thu, 06 Oct 2016 00:35:44 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1brwex-0001P3-34 for; Thu, 06 Oct 2016 00:35:39 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1brweu-0006VP-0q for; Thu, 06 Oct 2016 00:35:38 +0000
Received: by with SMTP id n189so3645774qke.0 for <>; Wed, 05 Oct 2016 17:35:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=T8R1fYUCVD7CVXenUHLthx/sGzvmY0BauVC9icb8cSs=; b=khzKFaTz+5cGeWkqtDhX6iZmlswP88ytU9Kq8L6W8TRM0VaHP46j55i0Sxmh9oTnS6 PMVNtOhQN/tylWwv6XTFnsJ85IfGcnr1mbyRRW8yHH3QdW70NIt+yGWhXTpWREeWXMVV B5aO0fbob+mhjwdWkxtOfcdmb6YPOupe9f8GSrdCZrI5S5aewyjW/Kh9wcx52auT8HVe +chpi0X0CA1ndQrqkvj0Exd2ZSBYWkclkSLOVSxOscEdi8Zo7jaOeekbxun8A/5bZEFn MHWXP3scIVh6elKBGm31qi6wSBZieCsfUDTvmWieD/PjBjJC1F3X85WWW8LwrRzQ2/pc ohxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=T8R1fYUCVD7CVXenUHLthx/sGzvmY0BauVC9icb8cSs=; b=N1jrSmof34SRaMk502ZNPC8G5Ora/ucs/kCguURYXrCwyRFflq5EpO3Hggf4WKj7V2 pNbJjWQOdoQ/vd5IYnT44ap44eP2iciRq3cz+lXyEVE8srtU/hfW2uXP/mFRUTqKTuet IbuCol5cFIA0tPffGngLFC249K443GBJ80bO8SYNqn01o9PbBf4HuG2XefKUcak5uPZ3 7IZejb4NRY0sJLskUW+K4uvl5GSbAFAsPK7QjYAsHpJsC99TCPCtpbdLmEfijmoQ5z1E t+2tbLQ75JzBF4tDdEJbpiA+wFabkB4z9tk8QOI7S5oWM63do30zQ61uglGdbaX46tQq JqTA==
X-Gm-Message-State: AA6/9Rk7R1YEkLm/nIa0DlBKnBCTUb+5VXDnj/wxYIn2c3ob6/OvpJafMqouw1CuUlBJ7ZLb+NuqwxMGDbq16w==
X-Received: by with SMTP id n21mr10783765qka.137.1475714109936; Wed, 05 Oct 2016 17:35:09 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 5 Oct 2016 17:35:09 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Martin Thomson <>
Date: Thu, 06 Oct 2016 11:35:09 +1100
Message-ID: <>
To: Mike Bishop <>
Cc: Kari Hurtta <>, Patrick McManus <>, HTTP working group mailing list <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.1
X-W3C-Hub-Spam-Report: AWL=0.082, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1brweu-0006VP-0q 27d26c2fe1190b4a0334e1c27a5068f0
Subject: Re: SETTINGS_MIXED_SCHEME_PERMITTED | Re: I-D Action: draft-ietf-httpbis-http2-encryption-07.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/32497
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

I'll try, but it might be ELI15...

On 6 October 2016 at 04:28, Mike Bishop <> wrote:
> Basically, we've simplified this greatly, and I like that.  But we've simplified it so much that I'm no longer clear what problem we have left to solve. Can someone ELI5?

A client learns that a server has a "secure" alternative.  This
implies that clients can send "not-secure" requests to a "secure"

The client wants to know that this alternative understands what it
means when it sends a "not-secure" request to that server.  This is
because some "secure" servers can be confused by a "not-secure"
request. They might think that it is "secure" and do the wrong thing.

We need to find a way to ask the "secure" server if it is OK with
getting "not-secure" requests.

>   - This host is authorized to serve the content for  That's RFC 7838 -- we're done.

I wish.

>   - This host can serve the content for and is smart enough not to get confused when scheme and port don't match?  Again, that's RFC 7838 ("mitigate ... by refraining from advertising alternative services for insecure schemes.").  But if you want to enable clients to double-check the origin administrators, let the alternative declare that it's scheme-aware, whether by existence of a .w-k resource or a connection setting.

It's hard to know whether a server is confused just by making regular requests.

>   - This host can serve content for both *and* *and* on the same connection without confusing them all?  That seems to be implied by the previous one.

I think that Kari was hinting at a problem where a load balancer
terminates TLS and then routes based on the Host header alone.  The
back-end servers aren't all equally capable of distinguishing between
"secure" and "not-secure".

That suggests to me that you probably want proof positive for all
origins separately, as we discussed.

>   - This host *consents* to serve  Seems implicit in responding to requests.  What does anyone gain by checking before sending requests versus trying the requests and maybe getting 421s?

See above regarding confusion.  Just providing a response isn't enough.


Here's my concrete proposal (as I made earlier):

Before using a secure alternative for an http:// origin, a client MUST
first request /.well-known/http-opportunistic at that origin.  If this
resource exists and a not-stale 2xx response is obtained, then
requests for the origin MAY be directed toward the secure alternative.
The contents of this resource do not matter.  If multiple http://
origins are coalesced onto the same connection to a secure
alternative, a client MUST obtain an http-opportunistic resource from
each origin separately.

You might insist on greater proof here (a Content-Location header
field would be stronger proof, or you could mandate some format for
the response body), but I don't believe that to be necessary.  Once
the http-opportunistic resource exists, then we have proof that the
server has opted in.

This does mean that in co-hosted situations an audit is recommended to
ensure that there are no resources for which there are a) necessary
variations between https:// and http:// resources on the same path and
b) confusion might be possible.  The server operator then needs to
choose whether to disable http-opportunistic just on the affected
origins or to disable the feature entirely.