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

"Roy T. Fielding" <fielding@gbiv.com> Sat, 20 September 2014 18:57 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 658751A01E0 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 20 Sep 2014 11:57:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.654
X-Spam-Level:
X-Spam-Status: No, score=-8.654 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 h2b8oqRG-S_z for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 20 Sep 2014 11:57:31 -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 0779D1A01DC for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 20 Sep 2014 11:57:30 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1XVPo1-00057G-VG for ietf-http-wg-dist@listhub.w3.org; Sat, 20 Sep 2014 18:54:49 +0000
Resent-Date: Sat, 20 Sep 2014 18:54:49 +0000
Resent-Message-Id: <E1XVPo1-00057G-VG@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <fielding@gbiv.com>) id 1XVPne-00056P-DU for ietf-http-wg@listhub.w3.org; Sat, 20 Sep 2014 18:54:26 +0000
Received: from sub4.mail.dreamhost.com ([69.163.253.135] helo=homiemail-a97.g.dreamhost.com) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <fielding@gbiv.com>) id 1XVPnd-0004oL-MB for ietf-http-wg@w3.org; Sat, 20 Sep 2014 18:54:26 +0000
Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id AA0F6286059 for <ietf-http-wg@w3.org>; Sat, 20 Sep 2014 11:54:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=I0AmdhLuvQX/VAPNwgaoKrWgphY=; b=E/5iSMAv4VKCSydPD7DCoGhYgGSU 4zm/oYTNJIEZ8lr3EyNQvRBuJuxOiTijClcu2E2Gx93eIygRTLkIzXE1Z6JB8kC4 mJSDgydo3X4hrMVhhk+3s4peao/1urLSBquK3rIhe9NZsCtE7b5c3/RWx4caD8YJ J81NiauPGCggkLE=
Received: from [192.168.1.5] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id A0067286058 for <ietf-http-wg@w3.org>; Sat, 20 Sep 2014 11:54:04 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1283)
From: "Roy T. Fielding" <fielding@gbiv.com>
In-Reply-To: <c5d0c3ccb93d497f80326a18784a0af7@BY2PR03MB427.namprd03.prod.outlook.com>
Date: Sat, 20 Sep 2014 11:54:14 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <1C1699D3-4F00-41BE-A7F0-A0907DC35766@gbiv.com>
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> <20140920164054.GA24246@LK-Perkele-VII> <c5d0c3ccb93d497f80326a18784a0af7@BY2PR03MB427.namprd03.prod.outlook.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
X-Mailer: Apple Mail (2.1283)
Received-SPF: none client-ip=69.163.253.135; envelope-from=fielding@gbiv.com; helo=homiemail-a97.g.dreamhost.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-3.450, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001
X-W3C-Scan-Sig: lisa.w3.org 1XVPnd-0004oL-MB e5b78408a7e587bd90517efd5ee8cb71
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/1C1699D3-4F00-41BE-A7F0-A0907DC35766@gbiv.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/27143
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>

As a concrete example, almost all software and firmware updates are delivered
these days using HTTP (preferably over TLS, of course).  These sites are expected
to deliver updates to systems running obsolete software.  In some cases,
software that hasn't been run at all for five or six years.

When such a site receives a request using an older, now less-secure cipher,
but one that is expected for that type of client, what is the site supposed
to do?  Is it supposed to reject the request if the (perhaps updated) h2
specification says so?  Who does that help?  Obviously, the purpose of the
site is more important than the bad assumptions in 9.2.2.  That's why it
is an admin decision, not a protocol requirement.

There is a reason that TLS doesn't forbid the use of old ciphers, even the
ones that are known to be easily breakable.  Not every application is the
same.  We have BCP documents to explain the nuances of various choices.
When a site chooses to do something against BCP, it is usually because
they either have no idea how TLS is configured (in which case TLS should
be the one selecting the better defaults) or they have deliberately
chosen to configure it for the sake of their own, perhaps unique,
interoperability requirements.  We don't know which.  We don't know why.
And we sure as hell don't know when.

....Roy