[dane] Fwd: Comments about draft-ietf-httpbis-http2-16 : Connection reuse
Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 01 January 2015 12:08 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B431A1B49 for <dane@ietfa.amsl.com>; Thu, 1 Jan 2015 04:08:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 r0hUU7KzWYWa for <dane@ietfa.amsl.com>; Thu, 1 Jan 2015 04:08:42 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C0341A1B2F for <dane@ietf.org>; Thu, 1 Jan 2015 04:08:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CAE2DBF15 for <dane@ietf.org>; Thu, 1 Jan 2015 12:08:40 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmOpIhApdFU1 for <dane@ietf.org>; Thu, 1 Jan 2015 12:08:38 +0000 (GMT)
Received: from [10.87.48.73] (unknown [86.42.21.122]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CE852BF11 for <dane@ietf.org>; Thu, 1 Jan 2015 12:08:38 +0000 (GMT)
Message-ID: <54A538C7.8060701@cs.tcd.ie>
Date: Thu, 01 Jan 2015 12:08:39 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: dane <dane@ietf.org>
References: <1968865.8edv0lVl2c@home>
In-Reply-To: <1968865.8edv0lVl2c@home>
X-Forwarded-Message-Id: <1968865.8edv0lVl2c@home>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/t8JujsDwHqnfT4vmEURt_i_UESo
Subject: [dane] Fwd: Comments about draft-ietf-httpbis-http2-16 : Connection reuse
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Jan 2015 12:08:44 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI. If you're interested in this, the discussion needs to be on the httpbis WG list and/or on ietf@ietf.org as HTTP/2.0 is in IETF LC now, until Jan 14th. Cheers, S. - -------- Forwarded Message -------- Subject: Comments about draft-ietf-httpbis-http2-16 : Connection reuse Resent-Date: Thu, 01 Jan 2015 00:04:36 +0000 Resent-From: ietf-http-wg@w3.org Date: Thu, 01 Jan 2015 01:04 +0100 From: Aeris <aeris@imirhil.fr> To: ietf-http-wg@w3.org 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/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUpTjDAAoJEC88hzaAX42irDgH/0KGVmkfujatx9YGehagzk+K GBrc9jH2wrd3kxbkKjsorh0yC4W66U2gHy4921IlQ1PSdBgvkiRP8V/z13d4ML39 ydnUvs/rVdaq1bstvbiTo5foj4ISK5K9qkzS/xWKrSez4vDtIINpnoBPe/eIVzYY Y439nQn1wlmDxLqXZv8GcvD3SrxOQ2pjNLnK9U5JsYdbhR8JIqBok+iwQEZ79AYZ KrSKbUjILn/pZieAysSj4vMSp7ksaF6pblh0n/tvPnVBtiwqbjDwwEgYBFMIZteG gEJ1awKeenol1lXFAZuXvGPRsVtkiksS2qpMHcjiKqZ5ypBb28izzItOu7tLvRA= =35mj -----END PGP SIGNATURE-----
- [dane] Fwd: Comments about draft-ietf-httpbis-htt… Stephen Farrell
- Re: [dane] Comments about draft-ietf-httpbis-http… Viktor Dukhovni