Re: [TLS] Downgrade protection, fallbacks, and server time

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 02 June 2016 14:59 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1CD12D1CD for <tls@ietfa.amsl.com>; Thu, 2 Jun 2016 07:59:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
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 9dyP_2Efhtjh for <tls@ietfa.amsl.com>; Thu, 2 Jun 2016 07:59:47 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A62E12D1B2 for <tls@ietf.org>; Thu, 2 Jun 2016 07:59:47 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 3D415284B14 for <tls@ietf.org>; Thu, 2 Jun 2016 14:59:46 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CAF8qwaCx-AyconwmB+mXMtNFYxhRrt7Kkqw+x5xZUgajXw1ZkQ@mail.gmail.com>
Date: Thu, 2 Jun 2016 10:59:45 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <A6E19341-DF55-478E-8776-082461477F62@dukhovni.org>
References: <CAF8qwaDuGyHOu_4kpWN+c+vJKXyERPJu-2xR+nu=sPzG5vZ+ag@mail.gmail.com> <6238043.DCePXUsCVt@pintsize.usersys.redhat.com> <CAF8qwaCx-AyconwmB+mXMtNFYxhRrt7Kkqw+x5xZUgajXw1ZkQ@mail.gmail.com>
To: tls@ietf.org
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/4qU1C_BiG9GoIi_EPSgUjJnlKCw>
Subject: Re: [TLS] Downgrade protection, fallbacks, and server time
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jun 2016 14:59:49 -0000

> On Jun 2, 2016, at 10:49 AM, David Benjamin <davidben@chromium.org>; wrote:
> 
> I'm not sure I follow. The specification certainly spells out how version negotiation is supposed to work. That hasn't stopped servers from getting it wrong. Fundamentally this is the sort of thing where bugs don't get noticed until we make a new TLS version, and we don't do that often enough to keep rust from gathering.

A better way to keep rust from gathering is to not instutionalize fallback,
force the broken sites to deal with the issue.  While 2% is noticeable, you
can probably drive 1.3 version intolerance out of the ecosystem relatively
quickly if Chrome implements fallback for a limited time (say 6 months after
TLS 1.3 RFC is done) and with a diminishing probability (60% first month, 10%
less each month thereafter), season to taste.

-- 
	Viktor.