Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Sat, 20 September 2014 16:44 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 2C3261A0104 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 20 Sep 2014 09:44:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.554
X-Spam-Level:
X-Spam-Status: No, score=-8.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 x-aBUGxtAgDa for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 20 Sep 2014 09:44:50 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC181A0009 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 20 Sep 2014 09:44:50 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1XVNjQ-0007HN-HW for ietf-http-wg-dist@listhub.w3.org; Sat, 20 Sep 2014 16:41:56 +0000
Resent-Date: Sat, 20 Sep 2014 16:41:56 +0000
Resent-Message-Id: <E1XVNjQ-0007HN-HW@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <ilari.liusvaara@elisanet.fi>) id 1XVNip-0007GR-R1 for ietf-http-wg@listhub.w3.org; Sat, 20 Sep 2014 16:41:19 +0000
Received: from emh07.mail.saunalahti.fi ([62.142.5.117]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <ilari.liusvaara@elisanet.fi>) id 1XVNio-00039b-Oy for ietf-http-wg@w3.org; Sat, 20 Sep 2014 16:41:19 +0000
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 7F37B3FE5; Sat, 20 Sep 2014 19:40:54 +0300 (EEST)
Date: Sat, 20 Sep 2014 19:40:54 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Roland Zink <roland@zinks.de>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <20140920164054.GA24246@LK-Perkele-VII>
References: <CAH_y2NF+sP9BmYuD4QbeHpwC_uj67itzaAFCnRVC6f--KDYOgg@mail.gmail.com> <CAOdDvNopynmwvwWLXvuC0q7skunFXcfRoVHe9s7BKcoCwaBgWQ@mail.gmail.com> <CAH_y2NGXz7e3ejqy_rD=39=yYp3+cS1Dm6c3yFEYZg6tsUp5VQ@mail.gmail.com> <CABkgnnWAdm1TLP2XCKNU-6RPACLfooQV73R7Gpoemv+9PNULCA@mail.gmail.com> <CAH_y2NFLjok-NRJtOw1vmSy68sf393iSOgA4K599q0BSBqbNgA@mail.gmail.com> <CABkgnnU-CMtv8KvYU9n+QoPBOBshtQv3RfLy2qw=qVNb2O-qGg@mail.gmail.com> <CAH_y2NHrbH5Objwhq9E89QexhQtND4uOdy8q7OEckTCU17WqKg@mail.gmail.com> <CAH_y2NErRd4rxinSzEH3-uTjdWVkZu9o6sSKSf47LxfPFTRONw@mail.gmail.com> <54194A22.5010000@zinks.de> <37b1aa9484a945cab5e979744deb659a@BL2PR03MB419.namprd03.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <37b1aa9484a945cab5e979744deb659a@BL2PR03MB419.namprd03.prod.outlook.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Received-SPF: pass client-ip=62.142.5.117; envelope-from=ilari.liusvaara@elisanet.fi; helo=emh07.mail.saunalahti.fi
X-W3C-Hub-Spam-Status: No, score=-4.2
X-W3C-Hub-Spam-Report: AWL=-2.258, BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1XVNio-00039b-Oy 1874a39daa7ffbbffdfebf7892144c97
X-Original-To: ietf-http-wg@w3.org
Subject: Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem
Archived-At: <http://www.w3.org/mid/20140920164054.GA24246@LK-Perkele-VII>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/27141
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>

On Sat, Sep 20, 2014 at 12:08:07AM +0000, Andrei Popov wrote:
> The HTTP/2 spec’s restrictions on the TLS versions and cipher suites
> creates a number of issues:
> a) TLS code needs to filter ALPN IDs based on the negotiated TLS 
> protocol version and cipher suite, or the HTTP stack needs to filter
> cipher suites and TLS protocol versions based on the enabled HTTP
> versions.

The TLS protocol versions is not a problem, at least in no-MITM
environment: The application knows if it is trying TLS 1.2+ or
not. And I really hope that there is no TLS stack retarded enough
to fallback behind app's back.

Also, the server knows if it supports TLS 1.2+ or not. And if client
and server is TLS 1.2 capable, the negotiated version will be TLS
1.2.

However, things can go badly if there is some TLS MITM (some "security"
products apparently MITM TLS connections) in the middle (but still 
passes ALPN). Then the client and server assumptions turn badly
wrong.

The cipher requirements do have the shortcomings you note.

The PFS requirement is in the middle. It is feasible to just disable
all non-compliant ciphersuites globally (for server). And version
skew is unlikely, because new general-purpose PFS key exchanges are
extremely rare.

> c) HTTP/2 spec needs to be updated when new secure cipher suites/
> TLS protocol versions are added, or currently available ones become
> compromised (and special-purpose ones must be specifically enabled).

The HTTP/2 spec itself only needs update if AES falls, whole ECC
falls, RSA falls, or some new TLS version makes the specified MTI
unusable.

New ciphers (even "XYZ" ones) or TLS 1.3 do not require update
(but TLS 1.3 introduces a new failure mode: If client is TLS 1.2-
capable, and server is TLS 1.3-only, things are going to fail.
But that failure would happen with any protocol).

However, there is significant risk of version skew between the
application and TLS stack. This can lead to app making incorrect
decisions regarding cipher acceptability, with nasty consequences.


-Ilari