Comments about draft-ietf-httpbis-http2-16 : Connection reuse

Aeris <aeris@imirhil.fr> Thu, 01 January 2015 00:07 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152611A1A93 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 31 Dec 2014 16:07:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.752
X-Spam-Level:
X-Spam-Status: No, score=-3.752 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Lsk_9iWeQsm for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 31 Dec 2014 16:07:45 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5514C1A1A90 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 31 Dec 2014 16:07:45 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Y6TFk-0002Ij-RB for ietf-http-wg-dist@listhub.w3.org; Thu, 01 Jan 2015 00:04:36 +0000
Resent-Date: Thu, 01 Jan 2015 00:04:36 +0000
Resent-Message-Id: <E1Y6TFk-0002Ij-RB@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.80) (envelope-from <aeris@imirhil.fr>) id 1Y6TFh-0002I2-1D for ietf-http-wg@listhub.w3.org; Thu, 01 Jan 2015 00:04:33 +0000
Received: from server.imirhil.fr ([5.135.187.37] helo=mail.imirhil.fr) by lisa.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <aeris@imirhil.fr>) id 1Y6TFf-00047f-Lx for ietf-http-wg@w3.org; Thu, 01 Jan 2015 00:04:32 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.imirhil.fr (Postfix) with ESMTPSA id 328E2203B0 for <ietf-http-wg@w3.org>; Thu, 1 Jan 2015 01:04:04 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=imirhil.fr; s=mail; t=1420070644; bh=TahJPv2HQzXUzhdIBmyg3nXFJ93eMIjzGNjTqUAtG8Q=; h=From:To:Subject:Date:In-Reply-To:References:From; b=xQdtYQViNuyCycDms0CA4OrI8MvaZPpxtsABTpuZ0KAGH4jqaEROh1JQPaqYoRwiT HeZPSGB07+9RZE+qNXGsY6yStO4JCpJJSvJe/o+K9L/LdUbR1JMdNEmrW23biNfT5f J9NOMuv5VsnKLe457eA7ntR4ib9C3sgOGskPx+zE=
From: Aeris <aeris@imirhil.fr>
To: ietf-http-wg@w3.org
Date: Thu, 01 Jan 2015 01:04:00 +0100
Message-ID: <1968865.8edv0lVl2c@home>
In-Reply-To: <20141231153045.2584.87794.idtracker@ietfa.amsl.com>
References: <20141231153045.2584.87794.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2265105.DujzTrpO0y"; micalg="pgp-sha512"; protocol="application/pgp-signature"
Received-SPF: pass client-ip=5.135.187.37; envelope-from=aeris@imirhil.fr; helo=mail.imirhil.fr
X-W3C-Hub-Spam-Status: No, score=-1.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001
X-W3C-Scan-Sig: lisa.w3.org 1Y6TFf-00047f-Lx 1bda044c5f1798a145f5faccef8d72bf
X-Original-To: ietf-http-wg@w3.org
Subject: Comments about draft-ietf-httpbis-http2-16 : Connection reuse
Archived-At: <http://www.w3.org/mid/1968865.8edv0lVl2c@home>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/28371
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Sorry to speak about this only now, but I notice the following problem only 
few days ago when I activate SPDY on a TLSA protected domain.

§9.1.1 about connection reusage on HTTP/2 say

	Connections that are made to an origin servers MAY
	be reused for requests with multiple different URI authority
	components.  A connection can be reused as long as the origin server
	is authoritative (Section 10.1).
	For "https" resources, connection reuse additionally depends on
	having a certificate that is valid for the host in the URI. 

In my opinion, this behaviour leads to 2 huge problems in term of security and 
1 in term of usability/maintenability of HTTP/2.

1- X.509 certificate is not trustable by itself and need real content for 
validation

There are some extensions completing the certificate validation, as DANE/TLSA 
(RFC6698) or websec-key-pinning (currently IETF draft).
For both, guessing A certificate validity for B domain can’t be done just with 
the A certificate fetched from the A domain.
In case of TLSA, you need the real B certificate to check if this is the one 
declared in the DNS. For PKP, you need the real B content to check the 
HTTP header.

So current specification of HTTP/2 can break TLSA and PKP, by badly guessing 
that A certificate can be reuse on B domain, instead of using the real B 
certificate.

This is actually the case with current SPDY implementation (Firefox or 
Chrome). Having a A content including B content on the same IP with a A 
certificate valid for B domain but not for B TLSA, SPDY reuse the A channel for 
B content, and Firefox/Chrome display warning or block the content because 
TLSA error.

2- TLS is not only X.509 certificate. It’s also a lot of other things.

The current HTTP/2 specification restrict TLS to only the certificate it use.
If A domain use RSA 1024 bits key but B domain use ECC 571 bits key, reusing 
the A channel for B content reduce a lot the security compared to the case 
with 2 differents channels. Same problem if you enable different ciphers (saying 
NULL cipher for static content and AES256-GCM for critical content), or 
perfect forward secrecy ciphers for one and not for the other.
Can be the case if you use weak but fast config for your static content and 
strong but slow one for the critical content.
Same trouble in case of some downgrade attack on static content.
If HTTP/2 use the weakest channel for both, there is a big security problem. 

421 error code is not usable in this case to reject a channel reusage, because 
the required checks can’t be done application-side (TLS client context and 
server config not available) and even server-side, is extremly complicated (if 
even doable)…

3- Channel reuse leads to « systemd-for-the-web » if done cleanly.

Given the 2 points above, doing channel reuse cleanly require for HTTP/2 to 
become a systemd-like monster.
« cleanly » means « no difference compare to 2 channels usage », so take into 
account real B TLS context : certificat, key type and size, TLSA entry and 
corresponding DNSSec validation, TLS version, selected cipher, PKP HTTP 
header, key pinning (hardcoded in browser, pinned by user, pinned by plugin 
(HTTPS Everywhere / Certificate Patrol)) and virtually any others things a 
overall TLS ecosystem can have to manage, including not built-in or 
custom/non-standard.
TLSA is a good example for this point because not browser built-in but 
available through plugin, PKP because not currently a standard, and 
HTTPSEverywhere/CertificatePatrol because interfering with browser built-in 
config.

To choose if you can reuse or not a A channel for a B domain, HTTP/2 must be 
aware of many things, perhaps neither built-in nor even standardized.
Changing or adding a new step of verification on TLS will require rebuild of 
HTTP/2 client, hooks on plugins for not-built-in features, plugins need to be 
notified if HTTP/2 is in use or not…
Everything will be aware of HTTP/2 and HTTP/2 will be aware of everything. New 
SystemD on the road…

And even if done cleanly, channel reusing choice will be more expensive than 
just open a new channel (and worse, require a new channel in all cases for 
protocol/cipher/key/certificate/PKP/TLSA verification…).

So, HTTP/2 must reject connection reusage, and respect real wills of system 
administrator if they declare 2 differents TLS contexts for 2 domains, but 
behind the same IP. This kind of config decision must no be done or worse 
changed client-side.
On a post-Snowden era, don’t sacrifice security for speed… :'(

Regards (and happy new year :)),
-- 
Aeris

Protect your privacy, encrypt your communications
GPG : EFB74277 ECE4E222
OTR : 5769616D 2D3DAC72
https://café-vie-privée.fr/