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

David Benjamin <davidben@chromium.org> Thu, 02 June 2016 15:17 UTC

Return-Path: <davidben@google.com>
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 BDFBB12D766 for <tls@ietfa.amsl.com>; Thu, 2 Jun 2016 08:17:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.425
X-Spam-Level:
X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 MrnhjtOwmAFJ for <tls@ietfa.amsl.com>; Thu, 2 Jun 2016 08:17:17 -0700 (PDT)
Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80FDD12D765 for <tls@ietf.org>; Thu, 2 Jun 2016 08:17:07 -0700 (PDT)
Received: by mail-io0-x229.google.com with SMTP id k19so35553802ioi.3 for <tls@ietf.org>; Thu, 02 Jun 2016 08:17:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=P40dklr8M2mcjVrnBoT/1ySW8kKQbqS2UKOgPka5NvU=; b=hIbbsU8bieB+AjkpQD4RmLVKUuDPiA5sfijrgg+Vf6LCyscyUt7CY/ddx9GvBenAId Wf22cjWHFE9/Z0RYJCbdY7y8KkqFPRIbbDX3PWaJpfluerCpEaNeDd7hQ7VF20+70qBM YHZSUraU25HLd1gbJkbn5rIdct9CvHuUj65sY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=P40dklr8M2mcjVrnBoT/1ySW8kKQbqS2UKOgPka5NvU=; b=RXLMESRF3TQjWLkfLPSs5ijszgQ4+XDaX9vkzyCgZoqm3YpZ8pMNL8WMEvlcBneLmT zNT+DEy5jDogHy9Jn9ZuSKMiN1+qAxl9Pild6BB8eHgPqwlFxAG86RgqrOiw7xRJjyxa 3mU/HAN87wGzfFwmXJFfRZ0EyxyNFhy/w4dkb7Mrki75c2n0Z5g5O29NvJaWryMCBdMD wL5+RqzNQVAg1Um3R6npZxmkz6OaSXswecmII+6a8Vi6CwAXq8C9KahkKYSGOD07oDAI 3XeT2Cph3HF5pK7XHRvpRRGF1L2cI5SzsLKJx6Mmirgx2+XVpp1sQd4tgmmb6802CsDo Hw3w==
X-Gm-Message-State: ALyK8tIsKxNF6W5wNnsWeLzx/zgaIKfpXcQlJpdef2AoKiGSkeDwHqIJ3MhS6sMncM7xX54LJeZRKylwkK207iFk
X-Received: by 10.107.9.10 with SMTP id j10mr4263180ioi.97.1464880626441; Thu, 02 Jun 2016 08:17:06 -0700 (PDT)
MIME-Version: 1.0
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> <A6E19341-DF55-478E-8776-082461477F62@dukhovni.org>
In-Reply-To: <A6E19341-DF55-478E-8776-082461477F62@dukhovni.org>
From: David Benjamin <davidben@chromium.org>
Date: Thu, 02 Jun 2016 15:16:56 +0000
Message-ID: <CAF8qwaDQ5a7yOV+iwMB-Du0h3y9kz5RjKhzVaaf_CWeHFnXmHg@mail.gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="001a113f9b6a610b3605344d1965"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/NLrPesagOG9aeYtIAqdrvRQL7kc>
Subject: Re: [TLS] Downgrade protection, fallbacks, and server time
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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 15:17:19 -0000

On Thu, Jun 2, 2016 at 10:59 AM Viktor Dukhovni <ietf-dane@dukhovni.org>
wrote:

>
> > 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.


I've mused on something like that (I was the main driver behind
painstakingly removing the existing version fallback in Chrome), but I
don't think non-determinism is a good idea. Site owners need to be able to
reproduce the failures their users see.

But, yes, I will of course be monitoring the true metrics (my probing a
list of sites is only an approximation) and seeing what can be done here,
as I did previously.

David