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

Yaron Sheffer <yaronf.ietf@gmail.com> Sat, 04 June 2016 16:46 UTC

Return-Path: <yaronf.ietf@gmail.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 0673E12D522 for <tls@ietfa.amsl.com>; Sat, 4 Jun 2016 09:46:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 zz-zAmiMrvHX for <tls@ietfa.amsl.com>; Sat, 4 Jun 2016 09:46:14 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 D176E12D1A3 for <tls@ietf.org>; Sat, 4 Jun 2016 09:46:13 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id s131so14678415wme.0 for <tls@ietf.org>; Sat, 04 Jun 2016 09:46:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=MCR5rl5jrWAP93qvmm6174r2Ewz9/INQ9S0Mxm7jdtQ=; b=sICc26eUFUtAVVAryn5kHARlvz8MOBc3Lid2Uwr1URvp4jrOcour6HXmia+NY/rTei 6uE3I/4iqRYlobwmMGmO+9pHA34xNZ0yAHCmkk8I5wnxkHeavQEeOvgl1pU3hWURrBAh SNlbX6WURCg06dpv8VyiI29RSIwPLB0R30mnpENFYzyucrpyy1bJcp7oTS1icPHCvuF2 bqncAJ6ovzmWEFNLeLYDgg4Q7ignZ6ML+qoijwjrsWlIKPWTQ/DY63SmzCKexSJlllf/ EMvw2jhn2PaWN11bpVPEjMeQzmiqYohYfiB37DTnLPNV0kr2TDoUYNkQO5dKQnwGnYHT i05Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=MCR5rl5jrWAP93qvmm6174r2Ewz9/INQ9S0Mxm7jdtQ=; b=d4nkkHPZaQTIgVGNHJ4btOOAfQDU7Ji3qtzSUVubVLc+09tUYnxWbz2pALOEsrtSjn sBPfCX65af/szhvmL3zyGI4UB3MQGHzcXnZ/PMQPklypNnc6SBCeKY8JHqh61zKX+rBp ZuDz0icVU8gGVYm+ZvbV5dUbmDdF9APazvIWGVjLdvORuaU8sjZPG4pNx5qPDRgGeItl H0BzXxg9f+VXo8ol9If8SG7kGi3DP81FQ+sBFELjguyeNG0Ch/MU4ETIMC0/tPST5SLW 6LS5cz5BGd/FxvV/sfuzfXv+M/fn0GfouMx4cJidD5XptTdyT7HZNDiOWJzypes6c+9Q xTPg==
X-Gm-Message-State: ALyK8tILJAif89TkzhICThj5L6Z7OqI1nSPu2GVdQXo4pB8H5tafZAs+IWMC6gCZfLo52w==
X-Received: by 10.194.3.51 with SMTP id 19mr9003711wjz.57.1465058772325; Sat, 04 Jun 2016 09:46:12 -0700 (PDT)
Received: from [10.0.0.9] (bzq-109-67-2-59.red.bezeqint.net. [109.67.2.59]) by smtp.gmail.com with ESMTPSA id lr9sm11367574wjb.39.2016.06.04.09.46.10 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 04 Jun 2016 09:46:11 -0700 (PDT)
To: David Benjamin <davidben@chromium.org>, tls@ietf.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> <A6E19341-DF55-478E-8776-082461477F62@dukhovni.org> <CAF8qwaDQ5a7yOV+iwMB-Du0h3y9kz5RjKhzVaaf_CWeHFnXmHg@mail.gmail.com>
From: Yaron Sheffer <yaronf.ietf@gmail.com>
Message-ID: <575305D1.3030709@gmail.com>
Date: Sat, 4 Jun 2016 19:46:09 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <CAF8qwaDQ5a7yOV+iwMB-Du0h3y9kz5RjKhzVaaf_CWeHFnXmHg@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ltn_fCcwIBghMwiQ0mv581D0quo>
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: Sat, 04 Jun 2016 16:46:16 -0000


On 02/06/16 18:16, David Benjamin wrote:
> On Thu, Jun 2, 2016 at 10:59 AM Viktor Dukhovni <ietf-dane@dukhovni.org
> <mailto:ietf-dane@dukhovni.org>> wrote:
>
>
>      > On Jun 2, 2016, at 10:49 AM, David Benjamin
>     <davidben@chromium.org <mailto: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
>

Taking Viktor's proposal in a different direction, you could gradually 
increase the probability of version intolerance on the client side while 
still remaining deterministic from the user's point of view. You could 
do it by choosing a random distribution over server names (e.g., a hash 
of the SNI value). This means every month a few new servers would break. 
And you would want the client's beta channel to run several steps ahead 
of the production version.

Thanks,
	Yaron