RE: I-D Action: draft-ietf-httpbis-http2-encryption-07.txt

Mike Bishop <> Tue, 04 October 2016 17:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB500129410 for <>; Tue, 4 Oct 2016 10:43:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.017
X-Spam-Status: No, score=-10.017 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, 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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UeIpfOXyn7iY for <>; Tue, 4 Oct 2016 10:43:10 -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 2C70D12940D for <>; Tue, 4 Oct 2016 10:43:10 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1brTgd-0006Ws-U9 for; Tue, 04 Oct 2016 17:39:27 +0000
Resent-Date: Tue, 04 Oct 2016 17:39:27 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1brTgX-0006VZ-Oy for; Tue, 04 Oct 2016 17:39:21 +0000
Received: from ([] by with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1brTgP-0006Cy-VH for; Tue, 04 Oct 2016 17:39:19 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4jahLlaLqnyE20WBCpwJSl13hp0RaOEO1wH0ES6hiLk=; b=ikbyUENhB4U46xjRn4bll4SwbpD+EKnJ3SX6vhYeyXMFlKPUlBShHd86y4F6UI/N4k7eOxI6usXs9pXyAqXizLvxZhE86r9fLdpNJwbUCKY8bxjtfe56DzkvjFPCyzVgAyZpDG5ze8aXddIoASsKJjLGv+LEDy6+0imaZZun6Qo=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Tue, 4 Oct 2016 17:38:45 +0000
Received: from ([]) by ([]) with mapi id 15.01.0639.015; Tue, 4 Oct 2016 17:38:45 +0000
From: Mike Bishop <>
To: Kari hurtta <>, "HTTP working group mailing list" <>
Thread-Topic: I-D Action: draft-ietf-httpbis-http2-encryption-07.txt
Thread-Index: AQHSHljT6HkhJe/JXU23HQjGh2kOnqCYiSNg
Date: Tue, 4 Oct 2016 17:38:45 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:4898:80e8:4::740]
x-ms-office365-filtering-correlation-id: 29d00fad-72c3-41be-e3ad-08d3ec7d4abd
x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 6:8CLErLj8HsJU0ergOlJIqSLwhx/Vr7/cm8tqById/rfo+E55L9NXejwPiwz2ht2SZ4RQgJfU4kqq+QMoX5KWOR4lg2S919b89NilY+dx41w4hqsHrUEcgPh62FqME/6vzL5bKZMRD8SKuXAHOemh8Cfe5j6ob/ATiy+FQruvkWMERAtZSkoY0EnHo0llaNQTVidAZGwN+bMs0ObG4XRhXpmpG/yF2837Ay1NRy/1m9jocV4ZSRWRu62U+U+6BuEhawjcLxKoMd7VBekBOu0wNZB/J7n508LB7n5eeg97D1OHGPy8J1M0zLCNOiAg+L8QQKz3A21LxNiBLkyTHf0LHA==; 5:7sTzHxCe7pa5ecVEVxL7pEjPI8c7H+XTl/rVRq4o5rjDRr15oU+Ze6yL+Fv4s5gJnVycpzV1g3voLXyGTizAIMRFY0V/toLnacRhOYu6eGpA9OOBFT7XGppisI+U3QnZ6l3D1Q7rFt5tj6m1cvd8eQ==; 24:rGYUo3pXe1Z+UW0Xw9yNVgDX4QDVr1+j9QXsJzvN+vSvP/jmP7PwD0WVzi3NmO7FjnozCuDvD+K/9qsxgF9nRBieOQF9u6dTLxpDM9Bn8/U=; 7:oIGsJk9OtdZmCo2htB61+VA7zYBzTDRkR7LRAytggrRvTLSNkC0bBtFfa+5KCPS+cDrNbgqHHuF4Zm+IMEZSG8Z3km18i36aS+0E49uZnTnbwQEuMRKdGLwm03n7SkesSteKzeRUqTfKRm5lr1YzepBUKaHj94wKiYjC+B6d90V2bb6ArJJqgK1/lfMIjW5w85IlBPsDhmAKAj9PhcQA8+MFmE5pdfZFKKWS6iUZaId77iODSrFPAKm7Ou1gwUbEupOhZ9u+Eimfo37a5QhpPO24SNmkO5BM92OtsyzYQP9tzPmmNyIc/JCX2j2+E04w
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR03MB2708;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708;
x-forefront-prvs: 00851CA28B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(13464003)(199003)(377454003)(189998001)(2900100001)(54356999)(122556002)(87936001)(8936002)(230783001)(76176999)(2950100002)(77096005)(86362001)(5001770100001)(11100500001)(9686002)(107886002)(106356001)(68736007)(5002640100001)(106116001)(33656002)(15975445007)(97736004)(19580395003)(81156014)(81166006)(102836003)(105586002)(5660300001)(3280700002)(86612001)(99286002)(6116002)(101416001)(50986999)(10090500001)(7696004)(8990500004)(7846002)(76576001)(305945005)(5005710100001)(10290500002)(3660700001)(74316002)(92566002)(586003)(10400500002)(2906002)(19580405001)(8676002)(7736002)(3826002)(376185003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2016 17:38:45.4584 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.0
X-W3C-Hub-Spam-Report: AWL=-2.457, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_NW=0.5
X-W3C-Scan-Sig: 1brTgP-0006Cy-VH b7e1c2c8f462b70cb2868b615100c3c6
Subject: RE: I-D Action: draft-ietf-httpbis-http2-encryption-07.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/32468
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Building on Kari's feedback below, advertising an alternative with protocol "h2" (or "http/1.1") isn't really an opt-in for this specification.  Such a server could legitimately be implementing RFC 7838 as-is, which does not forbid offering that response.  (In fact, it's an explicit example given in section 2!)  You opt in to supporting this specification by having a resource at /.well-known/http-opportunistic, unless we wanted to mint a new a new Alt-Svc parameter for the origin and only host the resource on the alternative.

I agree with Kari as well that the text as-written applies to http:// schemed URIs being served over any TLS-based transport.  We might want to generalize that latter section to something like "over a connection consistent with the https:// scheme" or something like that.

More generally, I still disagree with the quoted MUST NOT on the grounds that it's unenforceable and not a hard requirement for interoperability.  Clients that implement only RFC 7838 will inherently violate the MUST NOT, and the server has no way of distinguishing those clients from implementations of this spec.  SHOULD NOT acknowledges that it's undetectable, while still emphasizing that there are risks associated to doing it this way.

Taking a step back, what is the list of ports actually buying us now?  The port can be obtained by the client from the Alt-Svc header.  The fact that the port is legitimate and not hijacked is verified by finding that it has a certificate.  What we're actually confirming is that the origin supports mixed schemes.  The lifetime is already present in the Alt-Svc advertisement, and I haven't heard a compelling reason to have a separate lifetime.  Should we just define SETTINGS_MIXED_SCHEME_PERMITTED and call it a day?

-----Original Message-----
From: [] On Behalf Of Kari hurtta
Sent: Tuesday, October 4, 2016 9:03 AM
To: HTTP working group mailing list <>
Cc: Kari hurtta <>
Subject: Re: I-D Action: draft-ietf-httpbis-http2-encryption-07.txt

> There's also a htmlized version available at:

2.  Using HTTP URIs over TLS

|    An origin server that supports the resolution of "http" URIs can
|    indicate support for this specification by providing an alternative
|    service advertisement [RFC7838] for a protocol identifier that uses
|    TLS, such as "h2" [RFC7540].

This allows also other than "h2" (for example "http/1.1", which is HTTP/1.1 over TLS).

2.1.  Alternative Server Opt-In

|    Clients MUST NOT send "http" requests over a connection with the "h2"
|    protocol identifier, unless they have obtained a valid http-
|    opportunistic response for an origin (as per Section 2.3), and:

But this part is specific to "h2".

What part of this specification is valid when prococol identifier is not "h2" ?

/ Kari Hurtta