Re: 2.2. Interaction with "https" URIs | Re: Op-sec simplification

Martin Thomson <> Wed, 02 November 2016 00:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE8F5129438 for <>; Tue, 1 Nov 2016 17:57:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.998
X-Spam-Status: No, score=-7.998 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_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-1.497, 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 puM9jrsMGepL for <>; Tue, 1 Nov 2016 17:57:24 -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 418E2127078 for <>; Tue, 1 Nov 2016 17:57:24 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c1jnm-0000Rg-CN for; Wed, 02 Nov 2016 00:53:14 +0000
Resent-Date: Wed, 02 Nov 2016 00:53:14 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c1jnh-0000Qf-5C for; Wed, 02 Nov 2016 00:53:09 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1c1jna-0007Bz-CQ for; Wed, 02 Nov 2016 00:53:03 +0000
Received: by with SMTP id z190so824227qkc.2 for <>; Tue, 01 Nov 2016 17:52:42 -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=5YAKExEh6jdsQDv6s8ApgKsuIyRrRfvhMQv2zMUvh6w=; b=TRiuJ4Oc7ZnNaccfxADvox3j3f9I04i8DiM6cI5GEETI4O2bxC3PB0IBwQV7ttznJP Va9HqHwBXSXfJIMBKQilmV9RoAZyeq/TOPY0hFNeBtpUmeq0tmSjvAZrWIuJQQzsvpqO 4+BHbO1YOpfTipbLEwUH5fqXy/bnnxAdzs2llTBljR7BxZDaa1SAjyY+g/Uwn/wXwX/3 ROKvtyqf+425hGe4vfSwOCFEAOeXw/AjcRznu3NRrvQB0of53S64l1Abt0fHfv38jDKe LDV3izrcoguY3eMZCaM7gNtwD+WN9YIHDY3DtznNfg15p31/v5J90qZg3wJbgBq9eObi O41Q==
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=5YAKExEh6jdsQDv6s8ApgKsuIyRrRfvhMQv2zMUvh6w=; b=bbe6O1ooQU4kZ5B7CK9WzWvs9X86XZtVog8GDfdq3mesyFgC2AH277A/BXdGFE8Vwf PbQ8LSLnPQCGRh3lZXu4CmP76jT5zgOj3sL1aBL58iuVuQ7k0z71Vmd7brQr955TJP/0 Yw7HB9A6z8KBqZ0mVKtSwIa9kEjtQ1CltilyyrkqpYiWpfHxLSDqWwq7PWY4LwI58TWg CjaV4aeRJOTn1VlJJcoDfxOQhdyUV8Rpdf5H+7M+G2/emxywnb0QbQSRVYpQ0iQ6KIqr 7quuB5aa6a8NMEX9jPcStg5+rm+6NSJpxILRLHoMDjb49pKvnnlhdaTGjjMgxt4xQ5d3 dhpA==
X-Gm-Message-State: ABUngvfV+NgaR/ptNoZnhTF6XqyNyQ317s74P55+mmVHzCFgpp0ZT2A0Cxz4wLZCetTWRHH7wAlWaGMq6aiiKA==
X-Received: by with SMTP id b69mr983340qkg.144.1478047956384; Tue, 01 Nov 2016 17:52:36 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 1 Nov 2016 17:52:35 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Martin Thomson <>
Date: Wed, 2 Nov 2016 11:52:35 +1100
Message-ID: <>
To: Kari Hurtta <>
Cc: 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.097, 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_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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: 1c1jna-0007Bz-CQ f1e6430dfb0261fc5c55aa7c09ca8d3b
Subject: Re: 2.2. Interaction with "https" URIs | Re: Op-sec simplification
Archived-At: <>
X-Mailing-List: <> archive/latest/32798
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 2 November 2016 at 04:22, Kari Hurtta <> wrote:
>         • No concern; that check that http://{...}/.well-known/http-opportunistic
>           succeed tells enough that there is no confusion

I think that this is sufficient.

The reason that I think this is OK, and the reason for removing a
mixed-scheme flag was that the risk comes from confusion.  That
confusion exists as soon as an http:// request is made over a TLS

It's not that much worse when things are mixed.  The bad examples of
routing based on the first request are bad for many reasons.  They are
simply cause to NOT provide the .well-known resource.

>         • Forbid using same connection for "http" requests
>           which would ordinarily be used for "https" requests.

We've already established that this is difficult to define properly.
And it's unnecessarily limiting.

>         • Forbid using same connection for "http" requests
>           which would ordinarily be used for "https" requests
>           but allow it if there is "mixed-scheme" -member (or
>           some other flag).

As above.

>         • Forbid using same connection for "http" requests
>           which would ordinarily be used for "https" requests
>           unless same connection which was tested
>           for http://{...}/.well-known/http-opportunistic
>           are also after that tested:
>                 ∘ That https requests for /.well-known/http-opportunistic
>                   on same host {...} does not return same object
>                 ∘ Note that if that test fails, then that connection
>                   is no longer be good for http requests either.

As above, just more complicated :)